Re: [Design] Re: [Cosmo] 'Bare minimum' proposal for Casual Collaborator Cosmo UI - Preview

[Mimi Yin]

I think I'm having trouble with this because there isn't a clearly established precedent for our particular circumstance. Are there any good examples of web apps that have persistent-multi-pane, editable views? Thinking about it more, a way to frame what we're discussion is: What does 'Cancel' mean? 1. Does it mean 'Cancel changes'? 2. Does it mean 'Cancel coming to this view and go back to where I was before'? If you've made changes already, 'Cancel' definitely means #1 and possibly #2 (most apps assume both #1 and 2, although I can imagine that that's not always true for the user). If you haven't made any changes yet, then 'Cancel' definitely means ONLY  #2. The question is, if we use 'Cancel'  or it's moral equivalent in Cosmo UI to mean just #1, will it be totally confusing? (e.g. what if 'Cancel' was greyed out until the user made edits.) Similarly, 'Save' should be greyed out until the user has actually made changes. Also, I don't think it's unreasonable to say that 'Cancel' or something like it should be available whenever an explicit 'Save' is necessary, even if the user hasn't gone anywhere new to make the edits.  A sort of backwards way of making this point is: Why do dialogs generally have both a Cancel and Save/Okay button when users could just close the dialog to get rid of it? I think it's because without a 'Cancel' button, people get stuck: Why is there an explicit Save/Okay option, but no explicit Cancel/No option? What's going to actually happen when I close the dialog? For Cosmo UI, the analogous question is: What's going to actually happen when I click off the item. Again, I don't feel particularly strongly about this issue and I'm definitely a believer in first trying a design that has fewer buttons before deciding that you need more buttons. But I also don't feel like the issue is so clear cut. My impression is that there aren't clear precedents for many of the design issues we're facing, precisely because we are on the cutting edge of web app interfaces. :o) ===== As for save versus auto-save...I think I'm just repeating what Jeremy suggested, but could we auto-save at fixed time intervals and when users click away from the item? On Nov 14, 2006, at 11:43 AM, Matthew Eernisse wrote: Regarding saving changes to single properties individually -- while it might not be impossible to do, I think there are a couple of questions to ask: 1. How desirable is it to do that? Cosmo is a Web application, and even though using Ajaxey development techniques can make the UI behave in a more responsive way, the UI is still remote from the data it's working with. Network latency could mean that one of those individual changes (say, just to the title) could take awhile. That would mean multiple changes would have to queue up, and it would be significantly slower than it is now. 2. What would be the impact on server performance to have the Web client making a hit to the server for each single change to an event? You'd want to ask one of the server guys, but my guess is that it would be significant. Until we enter the world of HTTP streaming ('comet'), there's a reason we have that explicit Save. Regarding the Cancel button -- as you pointed out Priscilla, all three of those other calendars use Cancel just the way I described: you have actually gone *somewhere else,* and clicking Cancel *takes you back where you were.* The Cosmo UI doesn't work that way. I think the danger of a user thinking their changes have been saved when they have not clicked the big button *prominently labeled 'Save'* is pretty low. It's a Web app, and Web apps have their own set of conventions -- like an explicit Save button. (The 'autosave' feature does exist, but it's pretty rare because it's not very practical on anything other than a single-field form.) I really don't think any Cancel/Revert button is necessary (and calling it Cancel is even more confusing because it wouldn't be behaving like a standard Cancel button). Matthew Priscilla Chung wrote: Ideally I am speaking for the Preview time frame, but I would double check with Matthew on how difficult it would be to implement first. Then weigh in how important it is to do either for preview. -Priscilla On Nov 14, 2006, at 8:52 AM, Mimi Yin wrote: Is automatically saving changes and updated the event lozenge in the calendar canvas something we can realistically do for Preview? Or are you speaking mostly of post-preview. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design