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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
