[Design] Edits and saving in the Web UI

[Mimi Yin]

Hi Matthew,

I'm going to step back a bit and address some higher-level issues. I  
think there are some unstated assumptions (certainly on my part) that  
are directing the details of this discussion and it might help to  
elucidate them and address them directly...

+ I'm not proposing we flout web conventions without good reason, so  
I'm going to attempt to enumerate them below :o)

+ Ajax web apps are new and innovative. I think it's sometimes  
incongruous to talk about web conventions in this new paradigm.

+ 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.

Now that we've broken the 'edit in a separate view' convention, what  
other 'web conventions' should we reconsider so that the experience  
is consistent?

+ For example, users may have expectations around things like auto- 
save that they wouldn't have with a more traditional "web-UI".

+ I don't think users think along 'technology lines'. Oh this is a  
browser, so there should be explicit Save. I think workflow has much  
more to do with it. Because the detail pane is available  
concomitantly with the calendar canvas and summary table, auto-save  
feels more natural. I think this is why we don't require explicit  
save when creating new events on the calendar either.

This is true on desktop apps as well.
- iCal has an auto-save model because it has a 3-pane layout.
- Outlook and Entourage have an explicit-save model because when you  
edit event details, you pop-up a new window.

+ 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?

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.

Mimi

1 more detailed comment in-line below...

On May 8, 2007, at 12:41 PM, Matthew Eernisse wrote:

> Mimi,
>
> Good questions, all. Responses below.
>
> Mimi Yin wrote:
>> Just to clarify, I'm suggesting we only 'auto-save' in cases where  
>> the user would need to explicitly click 'Save' anyway, aka when  
>> they "click away from the item and the DV changes what it displays".
>
> Ah, good. I'm glad we're not talking about some kind of background- 
> save process.
>
> But in trying to imagine how the auto-save described above would  
> work, it seems to me that we are trying to gloss over something in  
> the process that has huge significance -- the time it takes to save  
> the data. In trying to hide it, we're going to create an app that  
> feels horribly pokey.

The heuristic I'm proposing is: "Auto-save when users would need to  
explicitly save anyway". So wouldn't the app 'slow down to save  
edits' anyway? Even if we had an explicit Save button? Or are you  
saying the save will be faster if it's done explicitly?

>
> The best way to make a Web UI feel snappy is to give the user  
> immediate feedback when they take some kind of action. In the case  
> of clicking on an event lozenge, the user's intent is to *select a  
> new event.* They click on the lozenge, and boom, it's there. Right  
> now all that is instantaneous, and the app feels nice and snappy.
>
> If we were to implement that kind of auto-save, then sometimes  
> clicking on a new event would give you selection of the new event  
> instantaneously, and sometimes (if there have been changes) there  
> would be a really ponderous waiting process while the *previously  
> selected event* goes into a processing state, and the app does it's  
> chug-chug-chug talking to the server, before the new event is  
> finally selected. That's not going to feel snappy, it's going to  
> feel really slow.
>
>> Well, I think the problem we're facing right now is that we fear  
>> users won't remember to save at all.
>
> I can see that being a genuine concern. There is a very simple step  
> we can take to avoid that -- prompting users about unsaved changes  
> when needed. That's standard practice in Web UIs.
>
> Anyone who has worked with a Web app for any amount of time  
> generally understands fairly quickly that they need to send their  
> changes to the server for them to be saved. It's a really relevant  
> fact of the end-user experience with a Web app, and I don't think  
> it's something we really can, or should try, to hide from them.
>
>> Now, if someone were composing a long message or writing up  
>> meeting notes in the Notes field, then yes I agree with your  
>> analysis. But I don't think we're expecting that for Preview.
>
> That makes good sense. I understand there are different targeted  
> use-cases for Preview.
>
> However, whether it's just for Preview, or for the longer-term when  
> we anticipate there being people doing the majority of their work  
> in the Web UI, I feel very strongly that we should let the Web app  
> be a Web app, and leverage existing Web conventions unless there's  
> some big value in throwing them out.
>
>
> Matthew
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070508/e3bb8f9c/attachment.htm