[Design] Edits and saving in the Web UI

[Matthew Eernisse]

Mimi,

Thanks for the comments on this. I think it's doing a good job of 
pulling out and making explicit a lot of the context we're using when we 
think about the design.

Comments below.

Mimi Yin wrote:
> + In particular wrt Chandler Hub UI, the 3 pane layout is 
> unconventional. (Google/Yahoo calendars takes you a new screen to edit 
> the details of an event.) It's more like a desktop app and less like web 
> apps. But we believe it makes for a better user experience, so here we are. 

That's a very good point. A lot of Web app sidestep some of the issues 
we have by layering the details in such a way that it forces users to 
take explicit actions. We have to be smarter I guess, and I'm sure our 
collective fu is more than good enough to come up with something that 
works well both for the people coming from the desktop, and the people 
who live in their browsers.

> + I don't think users think along 'technology lines'. Oh this is a 
> browser, so there should be explicit Save. 

I agree. I don't think users sit around cogitating about what type of 
app they're using, saying "Hmm, looks like this has a Save button, must 
be a browser-based app."

But using an explicit Save button comes from an actual, practical need 
-- it's a result of the fact that the user is very far away from the 
data, so updates and access are expensive and take a long time. That 
doesn't change just because you introduce Ajax into the mix.

> - iCal has an auto-save model because it has a 3-pane layout.

And, I would add, because as a desktop app, it has none of the annoying 
network-latency issues that we have to deal with in the Web UI.

  + I think there are primarily 2 factors that contribute to the Auto-save
> versus Explicit-save:
> - *What is the object that you are saving?* Are you clearly saving a 
> discrete file? Is the thing you're saving in it's own window? Or is the 
> thing you're saving embedded in / integrated in the app as a whole?
> - *Probability of data loss.* Are you writing a long tome? Or darting in 
> and out with quick edits?

I would add a third factor that's really critical for us -- perceived 
performance speed of the app. If backgrounding the save makes the app 
feel like molasses, it doesn't matter how well the design of the UI 
lends itself to the autosave feature.

Having said that though, I think it behooves us to have a look at what 
the actual impact would be. It just that it's hard enough to make a Web 
app feel snappy, and thus far we have done a pretty good job -- so I 
don't want to compromise what we have now.

> That being said, I don't think we need to resolve this issue for 
> Preview. The explicit save workflow we have today is fine, especially 
> with Priscilla's improvement of 'anchoring it' to the bottom of the 
> screen so it never scrolls out of view. I just wanted to understand what 
> the technical challenges were to implementing the 'Auto-save when users 
> would explicitly save anyway' heuristic described above.

Agreed.

Even if we were to go this route, we would still obviously need the 
explicit buttons in place for people doing incremental saves, and we'd 
need to implement "Hey, you have unsaved changes" dialogs anyway for 
people who just forget and try to shut down the browser -- or people who 
*want* to discard their changes.

Thanks for all the hard work and thought on this.


Matthew