I'm not Matthew, but I'll offer up a reply based on my experience. On
certain browsers, processing an ajax request (depending on what you are
doing) may tie up the browser until the payload is processed. As you
might expect this depends greatly on what you are doing. By making a
set of asynchronous requests that deliver what most folks might consider
a pitifully small amount of data, you can effectively implement a DoS
attack, freezing the browser. I've done it making "heartbeat" requests
5 seconds apart for data that require significant amounts of redrawing
and repositioning of screen elements for a network monitoring
prototype. The system isn't technically broken, its tied up because the
browser won't accept user input. (incidentally the prototype in question
had redraw issues because of the handling of bitmap scaling and
transparency in an SVG implementation) This can make for some tricky
situations especially in a collaborative system.
An interaction model based on implicit save requires a reasonable,
reliable, (dare I say fast) connection with a data store/source.
A good desktop app should update simple values and refresh "instantly"
(within 90ms). For a similar edit on a web application the latency
alone might be twice that.
As for sluggish and slow, from my days with desktop apps I remember the
following rule of thumb:
1) if you can manage it make it happen within 90ms ( fast enough to
percieve its instant)
2) if it takes between that and about 10 seconds, use an hourglass --
tells the user it may take a minute
3) if it takes more than that use a progress bar and update it
frequently so the user doesn't think your app froze.
As you probably know, there is no way a browser-based app can do this
while communicating with the server constantly. (Bad for the server,
bad for latency) So the trick is to cache a set of changes together
until it makes sense (performance wise) to sync. So now we have a
payload of multiple edits the user thinks they saved, but have not
actually been transmitted from our dumb terminal the browser up to the
server. If a sync fails, server down, piece of bad data, badly
implemented action class, etc... the browser may end up losing all of
those changes and redrawing the screen abruptly. Matthew would prefer
the user KNOW what they have and have not saved by explicitly telling
the system via a button. This is not just Matthew, in the web world its
a convention that goes hand in hand with the desire to keep web apps
stateless. Its also a convention in most desktop apps when you make a
significant change: You must explicitly save emails you create. You
explicitly save edits to spreadsheets. Even quicken requires a commit to
enter a register item. Enterprise client-server apps are the big
exceptions: they may do an implicit commit to keep transaction time
small in respect to db locks.
There are always exceptions to this, and I think iCal is at the top of
the list.
Mikeal Rogers wrote:
2. Some changes to data require a subsequent data-fetch. For
example, when the user makes a change to a recurring event, we need
the new recurrence expansion back from the server to repaint the UI.
Could we display a 'Processing...' message the way we do when we
d-click to create new events on the calendar?
mde, could you clarify a bit. Do you mean that the UI will become
totally un-functional in this state, or just "sluggish" and "slow"
when in this state.
I think a "Processing.." message is a great idea, but whether it
should be at the bottom left corner out of sight, or in the middle of
the UI blocking any interaction depends on how "sluggish" the UI becomes.
-Mikeal
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
