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> wrote:

> On Apr 18, 2013 6:19 PM, "Paul Bakaus" <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
>
>