Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)

Hi Jonas, hi Alec,

I think all of this is great stuff that helps a ton – thanks! Let's definitely put them onto a wiki somewhere.

Charles: Where would be the right place to put that list? I'm imagining a big table with columns for the proposal and then each of the AppCache 2.0 proposals validated against it in the others.

Thanks,
Paul

From: Alec Flett <alecflett@chromium.org<mailto:alecflett@chromium.org>>
Date: Wed, 1 May 2013 08:50:33 -0700
To: Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>>
Cc: Paul Bakaus <pbakaus@zynga.com<mailto:pbakaus@zynga.com>>, Webapps WG <public-webapps@w3.org<mailto:public-webapps@w3.org>>
Subject: Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)

I think there are some good use cases for not-quite-offline as well. Sort of a combination of your twitter and wikipedia use cases:

Community-content site: Logged-out users have content cached aggressively offline - meaning every page visited should be cached until told otherwise. Intermediate caches / proxies should be able to cache the latest version of a URL. As soon as a user logs in, the same urls they just used should now have editing controls. (note that actual page contents *may* not have not changed, just the UI) Pages now need to be "fresh" meaning that users should never edit stale content. In an ideal world, once a logged in user has edited a page, that page is "pushed" to users or proxies who have previously cached that page and will likely visit it again soon.

I know this example in particular seems like it could be accomplished with a series of If-Modified-Since / 304's, but connection latency is the killer here, especially for mobile - the fact that you have a white screen while you wait to see if the page has changed. The idea that you could visit a cached page, (i.e. avoid hitting the network) and then a few seconds later be told "there is a newer version of this page available" after the fact, (or even just silently update the page so the next visit delivers a fresh but network-free page) would be pretty huge. Especially if you could then proactively fetch a select set of pages - i.e. imagine an in-browser process that says "for each link on this page, if I have a stale copy of the url, go fetch it in the background so it is ready in the cache"

(On this note it would probably be worth reaching out to the wiki foundation to learn about the hassle they've gone through over the years trying to distribute the load of wikipedia traffic given the constraints of HTTP caching, broken proxies, CDNs, ISPs, etc)

Alec

On Tue, Apr 30, 2013 at 9:06 PM, Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>> wrote:
On Apr 18, 2013 6:19 PM, "Paul Bakaus" <pbakaus@zynga.com<mailto:pbakaus@zynga.com>> wrote:
>
> Hi Jonas,
>
> Thanks for this ­ I feel this is heading somewhere, finally! I still need
> to work on submitting my full feedback, but I'd like to mention this: Why
> did nobody so far in this thread include real world use cases?
>
> For a highly complex topic like this in particular, I would think that
> collecting a large number of user use cases, not only requirements, and
> furthermore finding the lowest common denominator based on them, would
> prove very helpful, even if it's just about validation and making people
> understand your lengthy proposal. I.e. "a news reader that needs to sync
> content, but has an offline UI".
>
> Do you have a list collected somewhere?

Sorry for not including the list in the initial email. It was long
enough as it was so I decided to stop.

Some of the use cases we discussed were:

Small simple game
The game consists of a set of static resources. A few HTML pages, like
high score page, start page, in-game page, etc. A larger number of
media resources. A few "data resources" which contain level metadata.
Small amount of dynamic data being generated, such as progress on each
level, high score, user info.
In-game performance is critical, all resources must be guaranteed to
be available locally once the game starts.
Little need for network connectivity other than to update game
resources whenever an update is available.

Advanced game
Same as simple game, but also downloads additional levels dynamically.
Also wants to store game progress on servers so that it can be synced
across devices.

Wikipedia
Top level page and its resources are made available offline.
Application logic can enable additional pages to be made available
offline. When such a page is made available offline both the page and
any media resources that it uses needs to be cached.
Doesn't need to be updated very aggressively, maybe only upon user request.

Twitter
A set of HTML templates that are used to create a UI for a database of
tweets. The same data is visualized in several different ways, for
example in the user's default tweet stream, in the page for an
individual tweet, and in the conversation thread view.
Downloading the actual tweet contents and metadata shouldn't need to
happen multiple times in order to support the separate views.
The URLs for watching individual tweets needs to be the same whether
the user is using appcache or not so that linking to a tweet always
works.
It is very important that users are upgraded to the latest version of
scripts and templates very quickly after they become available. The
website likely will want to be able to check for updates on demand
rather than relying on implementation logic.
If the user is online but has appcached the website it should be able
to use the cached version. This should be the case even if the user
navigates to a tweet page for a tweet for which the user hasn't yet
cached the tweet content or metadata. In this case only the tweet
content and metadata should need to be downloaded and the cached
templates should be used.
If the user does not have twitter in the appcache and navigates to the
URL for an individual tweet the website needs to be able to send a
page which inlines resources such as CSS and JS files. This is
important in order to avoid additional round trips.

Webmail
A lot of simularities with the twitter use case. The website is
basically a UI for the database of emails.
However its additionally important that the user can compose emails,
including attach attachments, which are saved and synchronized once
the user goes online.
There are also other actions that the user might have taken while
offline. This means that complicated conflict resolution might need to
be done in order to synchronize with changes that has happened on the
server.

Blog reading
Store the last X days of blog posts locally. Each blog post consists
of the blog text as well as a few images. Other websites can link to
individual posts.
Each post contains a list of comments for the post.
Adding comments should be possible even while offline. Once the user
goes online it should be possible to submit these comments.

Blog authoring
Same as blog reading, but probably want to cache a larger set of
posts. Repository of unpublished posts should be available for editing
offline. Once the user goes online these edits are synced to server,
and any posts that were published while offline are automatically
published.
Both adding and removing comments should be possible while offline.
These changes too are published once user goes online.

News website
Front page with links to various articles. Each article as well as
front page contains both text and images/media. Both front page and
articles contains ads. A set of "top" articles are automatically
cached and kept up-to-date. Potentially users can configure additional
areas of interest which would cause additional articles from those
areas to get cached.


We should definitely put all of these on a wiki so that we can work
together on adding more use cases and documenting the various
requirements better. Once we have that we can document how well, if at
all, the the various proposals (including both the mozilla one, as
well as the NavigationController) solve the various use cases.

/ Jonas