[Design] Re: [Cosmo] 'Bare minimum' proposal for
Casual Collaborator Cosmo UI - Preview
br at osafoundation.org
Wed Nov 15 09:48:15 PST 2006
That would be doable (having a middle layer that the ui talks to
instead of the server directly) but I'm still a little leery of it.
What if someone makes a change and closes the page before the
minutely update thread saves?
Are onpageUnload hooks reliable enough for that, mde?
Btw I had the exact same reaction Priss and Matthew did w/r/t the
cancel button - I expect cancel to take me back to the page where I
was before, which is not applicable in our case. I say ditch it
altogether or call it revert or undo or something.
On Nov 14, 2006, at 1:24 PM, Jeremy Epstein wrote:
> What about simply changing the local cache (to update the page)
> indicate in the UI data may be stale (not yet persisted) then let
> the local cache sync at a predetermined time?
> i.e. every minute do a stale data check and update changes if any
> 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).
>> 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.
>>> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design