Priscilla will be summarizing this thread. I just wanted to take this
opportunity to acknowledge the risks that Matthew and others have
raised and explain how they might play into how we ultimately decide
these design issues.
That being said, we both agreed that this is not an issue we need to
resolve for Preview. Perhaps our goal for Preview should be to simply
come away with a better understanding of the issue and solid summary
of the issues.
:) Mimi
On May 8, 2007, at 7:50 PM, Matthew Eernisse wrote:
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.
Agreed. I understand this as a technical risk. What I'm not sure
about is whether users understand that risk. As a result, I wonder if
a 3-pane-layout may be a stronger factor than network-latency issues
in influencing *user expectations* around Save.
I'm trying to isolate user expectations around behavior from
technical reality (the 2 don't always align).
+ 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.
Yes. Again, I really do appreciate the performance and data loss
risks you and others have brought up. This discussion has been very
helpful to me in teasing out what the actual risks are versus the
'general case risks'.
I'd like for us to re-evaluate or re-calculate auto-save performance
risks in the context of the specific use cases that are likely to be
common for Hub UI users in the Preview timeframe. I think post-
Preview, that will allow us to do a better job of weighing the
performances risks against the user-expectation and workflow concerns.
Thx again for talking through this with me.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
