Ah! This is very helpful Jeremy. So can we isolate the scenarios
where auto-save needs to fetch a lot of data from the server?
Edits to the recurrence rule are one of them.
+ Changing the rule
+ Changing the end-date
What are some others? Will any of these be especially slow?
+ Stamping and Unstamping
+ Editing text fields seems equivalent to Pieter's gmail scenario and
probably won't take a long time?
- Addressing fields
- Title
- Location
- Notes
+ Editing date/time fields
+ Editing time zones
+ Editing event status
Also, we've talked about app-response times in general, but what's a
reasonable amount of time for users to wait, when waiting for a
'Saving operation' in particular?
Mimi
On May 8, 2007, at 4:36 PM, Jeremy Epstein wrote:
The activity you are talking about is sometimes called
checkpointing. Its a little different than the auto-save Mimi and
Priscilla are referring to, because their auto-save could
dramatically affect the data presented in the calendar and dash
views. GMail does not need to re-render very much to do its "auto
save". But the OSAF Web UI does, especially if the user edits the
time,changes the triage, or removes (un applies?) a stamp.
GMails auto-save is intended to prevent data loss during a long
editing session. GMail doesn't do anything with the data beyond
sending it to the server in case of a disconnect. The confluence
wiki I use at one of my client sites does the same thing, for the
same reason.
One reason for the delay in the Web UI case is to fetch new events
which may now show because your edit changed where an item appears
in a display.
Pieter Hartsook wrote:
One of the nice things that Google added to Gmail a while back was an
autosave feature. You still have the Save Now and Discard buttons
when
creating a message, but about every minute, the message you are
typing
(like this one) is autosaved. There is a status message next to the
Save Now/Discard buttons that updates to "Draft autosaved at 4:02
pm."
or whenever the last save was. The autosave is almost instantaneous
and doesn't seem to interfere with my typing. I can't really notice
any lag in my typing for example during the save.
If I try to navigate away from the message with unsaved changes I get
an error popup asking if I want to abandon the changes.
Pieter
On 5/8/07, Matthew Eernisse <[EMAIL PROTECTED]> 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 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
