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

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

Received on Wednesday, 1 May 2013 04:07:32 UTC