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

[Bobby Rullo]

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.

Bobby
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  
> happened.
>
>
>
>
>
> 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