[Design] Edits and saving in the Web UI

[Jeremy Epstein]

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
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070508/8cd6229e/attachment.htm