[Ayatana] "Unsaved state" and the Cloud

[Diego Moya <turingt@xxxxxxxxx>]

Mark commented on the Windicators presentation post about the
convenience of an "unsaved" indicator for transient changes in a
document.

With the recent emphasis in Ubuntu ONE and data storage in the Cloud,
I think a simple unsaved warning is not enough. The Windicators design
gives us an opportunity to rethink how persistence status is conveyed
to the user.

I've identified how online storage affects feedback about files state.
I've commented about it extensively in my blog:
(see http://mindnotsoul.blogspot.com/2010/01/taxonomy-for-data-in-cloud.html
). The crux of my analysis is addressed below.

There are three axis that directly affect user experience of data
stored in the cloud, and thus should be included in the user model for
cloud storage:
- Location: Connected vs Disconnected.
- Speed: Fast vs Slow.
- Persistence: Saved vs Unsaved

Location is not primarily about the physical position of the stored
data (which is mostly independent to the problem of data storage,
thanks to the Internet) but one of logical access: devices can be a
part of the Net sometimes, but sometimes not. Connected/disconnected
is the relevant fact to know about a device when thinking of
retrieving the same data later.

"Saving" should be handled automatically. If instant saving is not
supported, at least every application should have autosaving every few
minutes.

Leaving apart the saved/unsaved status, there are these four classifications:

* Connected data located in a fast medium. This is the ideal situation.

* Disconnected data located in a fast medium. If I move to a different
device, my new data or recent edits will not be available, but at
least I can have a secure saved local copy.

* Connected data located in a slow medium. Slow data that takes time
to stabilize and get "imported" into the cloud; it's data I must wait
for after I've finished my work.

* Disconnected data located in a slow medium. User data is at the
highest risk of being lost. Any system problem may cause open data to
be destroyed.

This status must be clearly shown to the user at all times so that she
can make sense of persistence in the cloud. But it shouldn't need
explicit user actions to change between states: files should be saved
and synchronized as soon as possible. So the system should support
these automatic actions:

- If the storage system is slow (big files on hard disk, all files on
net storage), launch automatic savings as a background process.
- if there's no connection to the device, create a persistent copy in
a local cache.
- as soon as connection is reestablished, synchronize the local cache
with the online cloud storage in the background.

These actions guarantee that file modifications will be safe at every
step, and that the user will be aware of the persistence process with
respect to:
- knowing if the changes are saved,
- knowing if they can be used in other systems.

I ask you, how would the best way to convey these status evolutions to
the user? I think we can have two windicators in each application, one
for "saved" and the other for "shared".

The opposite states (unsaved, unshared) would always be transient
states that should be corrected automatically as soon as the system is
able to transfer the changes. What do you think?