- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 22 May 2009 07:19:53 +0000 (UTC)
The remaining use cases I collected from the e-mails sent in over the past
few months were the following:
USE CASE: Web browsers should be able to help users find information
related to the items discussed by the page that they are looking at.
SCENARIOS:
* Finding more information about a movie when looking at a page about
the movie, when the page contains detailed data about the movie.
* For example, where the movie is playing locally.
* For example, what your friends thought of it.
* Exposing music samples on a page so that a user can listen to all the
samples.
* Students and teachers should be able to discover each other -- both
within an institution and across institutions -- via their blogging.
* David can use the data in a web page to generate a custom browser UI
for calling a phone number using our cellphone without using brittle
screen-scraping.
REQUIREMENTS:
* Should be discoverable, because otherwise users will not use it, and
thus users won't be helped.
* Should be consistently available, because if it only works on some
pages, users will not use it (see, for instance, the rel=next story).
* Should be bootstrapable (rel=next failed because UAs didn't expose it
because authors didn't use it because UAs didn't expose it).
* Parsing rules should be unambiguous.
* Should not require changes to HTML5 parsing rules.
USE CASE: Finding distributed comments on audio and video media.
SCENARIOS:
* Sam has posted a video tutorial on how to grow tomatoes on his video
blog. Jane uses the tutorial and would like to leave feedback to
others that view the video regarding certain parts of the video she
found most helpful. Since Sam has comments disabled on his blog, his
users cannot comment on the particular sections of the video other
than linking to it from their blog and entering the information there.
Jane uses a video player that aggregates all the comments about the
video found on the Web, and displays them as subtitles while she
watches the video.
REQUIREMENTS:
* It shouldn't be possible for Jane to be exposed to spam comments.
* The comment-aggregating video player shouldn't need to crawl the
entire Web for each user independently.
* Parsing rules should be unambiguous.
* Should not require changes to HTML5 parsing rules.
USE CASE: Search engines and other site categorisation and aggregation
engines should be able to determine the contents of pages with more
accuracy than today.
SCENARIOS:
* Students and teachers should be able to discover each other -- both
within an institution and across institutions -- via their blogging.
* A blogger wishes to categorise his posts such that he can see them in
the context of other posts on the same topic, including posts by
unrelated authors (i.e. not via a pre-agreed tag or identifier, nor
via a single dedicated and preconfigured aggregator).
* A user whose grandfather is called "Napoleon" wishes to ask Google the
question "Who is Napoleon", and get as his answer a page describing
his grandfather.
* A user wants to ask about "Napoleon" but, instead of getting an
answer, wants the search engine to ask him which Napoleon he wants to
know about.
REQUIREMENTS:
* Should not disadvantage pages that are more useful to the user but
that have not made any effort to help the search engine.
* Should not be more susceptible to spamming than today's markup.
* Parsing rules should be unambiguous.
* Should not require changes to HTML5 parsing rules.
USE CASE: Allow users to price-check digital media (music, TV shows, etc)
and purchase such content without having to go through a special website
or application to acquire it, and without particular retailers being
selected by the content's producer or publisher.
SCENARIOS:
* Joe wants to sell his music, but he doesn't want to sell it through a
specific retailer, he wants to allow the user to pick a retailer. So
he forgoes the chance of an affiliate fee, negotiates to have his
music available in all retail stores that his users might prefer, and
then puts a generic link on his page that identifies the product but
doesn't identifier a retailer. Kyle, a fan, visits his page, clicks
the link, and Amazon charges his credit card and puts the music into
his Amazon album downloader. Leo instead clicks on the link and is
automatically charged by Apple, and finds later that the music is in
his iTunes library.
* Manu wants to go to Joe's website but check the price of the offered
music against the various retailers that sell it, without going to
those retailers' sites, so that he can pick the cheapest retailer.
* David can use the data in a web page to generate a custom browser UI
for buying a song from our favorite online music store without using
brittle screen-scraping.
REQUIREMENTS:
* Should not be easily prone to clickjacking (sites shouldn't be able to
charge the user without the user's consent).
* Should not make transactions harder when the user hasn't yet picked a
favourite retailer.
* Parsing rules should be unambiguous.
* Should not require changes to HTML5 parsing rules.
USE CASE: Allow the user to perform vertical searches across multiple
sites even when the sites don't include the information the user wants.
SCENARIOS:
* Kjetil is searching for new hardware for his desktop and most of the
specs he does not care about too much, but he's decided that he wants
a 45 nm CPU with at least a 1333 MHz FSB and at least 2800 MHz clock
frequency, and a thermal energy of at most 65 W. The motherboard needs
to have at least 2 PCI ports, unless it has an onboard Wifi card, and
it needs to accommodate for at least 12 GB of DDR3 RAM, which needs to
match the FSB frequency. Furthermore, all components should be well
supported by Linux and the RAID controller should have at least RAID
acceleration. None of the manufacturer sites have information about
the RAID controllers, that information is only available form various
forums.
* Fred is going to buy a property. The property needs to be close to the
forest, yet close to a train station that will take him to town in
less than half an hour. It needs to have a stable snow-fall in the
winter, and access to tracks that are regularly prepared for XC
skating. The property should be of a certain size, and proximity to
kindergarten and schools. It needs to have been regulated for
residential use and have roads and the usual infrastructure.
Furthermore, it needs to be on soil that is suitable for geothermal
heating yet have a low abundance of uranium. It should have a good
view of the fjord to the southeast.
REQUIREMENTS:
* Performing search searches should be feasible and cheap.
* It should be possible to perform such searches without relying on a
third-party to seek out the information.
* The tool that collects information must not require the information to
be marked up in some special way, since manufacturers don't include
all the information, and users on forums (where the information can
sometimes be found) are unlikely to mark it up in some particularly
machine-readable way.
* Parsing rules should be unambiguous.
* Should not require changes to HTML5 parsing rules.
USE CASE: Allow users to compare subjects of blog entries when the
subjects are hard to tersely identify relative to other subjects in the
same general area.
SCENARIOS:
* Paul blogs about proteins and genes. His colleagues also blog about
proteins and genes. Proteins and genes are identified by long
hard-to-compare strings, but Paul and his colleagues can determine if
they are talking about the same things by having their user agent
compare some sort of flags embedded in the blogs.
* Rob wants to publish a large vocabulary in RDFS and/or OWL. Rob also
wants to provide a clear, human readable description of the same
vocabulary, that mixes the terms with descriptive text in HTML.
REQUIREMENTS:
* Parsing rules should be unambiguous.
* Should not require changes to HTML5 parsing rules.
USE CASE: Allow blogs to be aggregated along subject lines.
SCENARIOS:
* At University of Mary Washington, many faculty encourage students to
blog about their studies to encourage more discussion using an
instance of WordPress MultiUser. A student with have a blog might be
writing posts relevant to more than one class. Professors would like
to then aggregate relevant posts into one blog.
I haven't been able to find any solutions to the above problems that
involve changes to HTML5 that would actually solve the problems.
Here is some discussion of some of these scenarios:
* Finding more information about a movie when looking at a page about
the movie, when the page contains detailed data about the movie.
* For example, where the movie is playing locally.
* For example, what your friends thought of it.
Doing this is possible today and doesn't really require any particular
features in HTML5. For example, say I'm viewing the Star Trek IMDB page:
http://www.imdb.com/title/tt0796366/
There are several ways I can find where the movie is showing locally: e.g.
I could click the "showtimes" link in the left sidebar (and type in my ZIP
and press enter -- though IMDB could easily use GeoIP information or even
the Geolocation API to automate this), or I could type the movie's title
into my browser's search box along with my ZIP code and Google would give
me local showtimes, as well as (in this instance) a trailer.
To find out what my friends thought of it I would just ask them, but I
suppose if for some reason I wanted to avoid talking to my friends I could
simply go to my social network and search for the movie title in my
friends' recent comments, and that would give me their opinions too.
It's not clear to me what more is needed here.
* Exposing music samples on a page so that a user can listen to all the
samples.
<audio> seems to do this adequately.
* Students and teachers should be able to discover each other -- both
within an institution and across institutions -- via their blogging.
This use case was discussed in the context of students and teachers that
are not cooperating with each other:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019595.html
In the case where they _are_ cooperating, the solution seems to be a
straight forward directory. It's not clear HTML needs any features to help
with this.
* David can use the data in a web page to generate a custom browser UI
for calling a phone number using our cellphone without using brittle
screen-scraping.
The 'tel:' URI scheme seems like a straight-forward solution to this.
* Sam has posted a video tutorial on how to grow tomatoes on his video
blog. Jane uses the tutorial and would like to leave feedback to
others that view the video regarding certain parts of the video she
found most helpful. Since Sam has comments disabled on his blog, his
users cannot comment on the particular sections of the video other
than linking to it from their blog and entering the information there.
Jane uses a video player that aggregates all the comments about the
video found on the Web, and displays them as subtitles while she
watches the video.
Systems like FriendFeed and BackType already demonstrate that collecting
comments is a tractable problem; displaying them as subtitles would
require a site to take a comment feed and render them as subtitles
somehow, but whether that makes sense or not I'm not sure.
I don't really see what HTML5 can do to materially help here, though.
* A blogger wishes to categorise his posts such that he can see them in
the context of other posts on the same topic, including posts by
unrelated authors (i.e. not via a pre-agreed tag or identifier, nor
via a single dedicated and preconfigured aggregator).
Anything that is between unrelated authors (and thus doesn't involve
pre-agreed conventions) is going to need the kind of statistical natural
language processing we see in technologies such as topic clustering in
search engines or statistical machine translation. I don't see anything we
can do at the markup level to help systems cluster blog posts by unrelated
authors together by topic beyond the new blogging markup in HTML5 like the
<article> element.
* A user whose grandfather is called "Napoleon" wishes to ask Google the
question "Who is Napoleon", and get as his answer a page describing
his grandfather.
This seems unrelated to HTML5 -- the page in question might not even be
written in HTML, and the question still holds. So this seems like a
problem for Google to solve, not us.
* A user wants to ask about "Napoleon" but, instead of getting an
answer, wants the search engine to ask him which Napoleon he wants to
know about.
This is already possible, as shown by DuckDuckGo.com:
http://duckduckgo.com/?q=Napoleon
Wolfram Alpha (not a search engine but a knowledge computation system)
also supports this kind of modality:
http://www.wolframalpha.com/input/?i=Napoleon
I don't see how changes to HTML can aid with this; it seems to be a
problem for information aggregators, not information producers.
* Joe wants to sell his music, but he doesn't want to sell it through a
specific retailer, he wants to allow the user to pick a retailer. So
he forgoes the chance of an affiliate fee, negotiates to have his
music available in all retail stores that his users might prefer, and
then puts a generic link on his page that identifies the product but
doesn't identifier a retailer. Kyle, a fan, visits his page, clicks
the link, and Amazon charges his credit card and puts the music into
his Amazon album downloader. Leo instead clicks on the link and is
automatically charged by Apple, and finds later that the music is in
his iTunes library.
This seems a rather esoteric use case, but it would be possible to do it
today just by having a site that retailers can register with which can be
used as a "pseudo-retailer", so that instead of linking straight to Amazon
or iTunes, a site just links to this site, and the site just redirects the
user straight to his preferred retailer.
* Manu wants to go to Joe's website but check the price of the offered
music against the various retailers that sell it, without going to
those retailers' sites, so that he can pick the cheapest retailer.
The same system could work for this also; the site would just need to
know how to fetch price information from each retailer to present it to
the user. Whether the retailers would consider that a breach of their
terms of service or not is another issue.
* David can use the data in a web page to generate a custom browser UI
for buying a song from our favorite online music store without using
brittle screen-scraping.
Microdata could be used for this, but I'm skeptical that such a solution
would gain enough traction to be useful (users would have to limit
themselves to cooperating sites to get much success). Better might be to
have the extension just do a search based on the user's text selection
using the "pseudo-retailer" idea mentioned above. Such a system could even
search for titles on the page to show "smart tags" for the songs, though
in practice such ideas have met substantial resistance from site authors.
* Kjetil is searching for new hardware for his desktop and most of the
specs he does not care about too much, but he's decided that he wants
a 45 nm CPU with at least a 1333 MHz FSB and at least 2800 MHz clock
frequency, and a thermal energy of at most 65 W. The motherboard needs
to have at least 2 PCI ports, unless it has an onboard Wifi card, and
it needs to accommodate for at least 12 GB of DDR3 RAM, which needs to
match the FSB frequency. Furthermore, all components should be well
supported by Linux and the RAID controller should have at least RAID
acceleration. None of the manufacturer sites have information about
the RAID controllers, that information is only available form various
forums.
* Fred is going to buy a property. The property needs to be close to the
forest, yet close to a train station that will take him to town in
less than half an hour. It needs to have a stable snow-fall in the
winter, and access to tracks that are regularly prepared for XC
skating. The property should be of a certain size, and proximity to
kindergarten and schools. It needs to have been regulated for
residential use and have roads and the usual infrastructure.
Furthermore, it needs to be on soil that is suitable for geothermal
heating yet have a low abundance of uranium. It should have a good
view of the fjord to the southeast.
The only pratical solution to these that I can see would be technology
along the lines of the recently-announced Google Squared, which uses
statistical analysis across large corpuses to automatically fill
spreadsheets regarding particular topics. One could imagine that a more
mature version of such a technology would allow searches like the above.
* Paul blogs about proteins and genes. His colleagues also blog about
proteins and genes. Proteins and genes are identified by long
hard-to-compare strings, but Paul and his colleagues can determine if
they are talking about the same things by having their user agent
compare some sort of flags embedded in the blogs.
I guess a <meta> tag in the <head> could be used to annotate what the
particular sequences discussed are, or alternatively this could use
microdata blobs or rel=tag or some such. An extension could then
presumably be used to compare the strings.
* Rob wants to publish a large vocabulary in RDFS and/or OWL. Rob also
wants to provide a clear, human readable description of the same
vocabulary, that mixes the terms with descriptive text in HTML.
If the RDFS/OWL requirements and the HTML descriptions are to be the same
page, then microdata might be able to do this (I'm not clear on exactly
what parts of RDF are needed by RDFS/OWL). However, in general this kind
of thing would be best done using straight XHTML and namespaces, just like
how you would annotate an XML Schema.
* At University of Mary Washington, many faculty encourage students to
blog about their studies to encourage more discussion using an
instance of WordPress MultiUser. A student with have a blog might be
writing posts relevant to more than one class. Professors would like
to then aggregate relevant posts into one blog.
This seems to be an already-solved problem using tags and software like
the "planet" blog aggregator.
This concludes the use cases that I collected over the past few months. If
you have use cases that have not been covered, please don't hesitate to
bring them up. If possible, using the format I have used in the past few
e-mails (with a scenario that describes user behaviour and optionally the
intended interface, but doesn't describe the underlying technologies at
all) would be a great help, as it removes any ambiguity about what exactly
the problem is that we're trying to solve.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 22 May 2009 00:19:53 UTC