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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
