[squeak-dev] UI feedback badness in 4.4-12550-ish image

David T. Lewis lewis at mail.msen.com
Wed May 22 01:49:44 UTC 2013


On Tue, May 21, 2013 at 04:37:08PM -0700, tim Rowledge wrote:
> An important idea in UI design to support effective use and avoid customer irritation is to provide very rapid response to UI actions *especially* if the requested action is going to take a while. It's amazing how often writers of tools forget this and even more amazing how often the writers of UI widgets ignore any thought of providing a way to support the needed instant feedback.
> 
> My rantette today particularly refers to what happens in the MC repository browsers but is generally applicable; even the plain old code browser ought to be getting it right but doesn't - it's just that on a fast machine you don't often notice that. On slower machines it can be so damn annoying people simply give up. I'd prefer that didn't happen.
> 
> So, when you click on a package version the very first thing that should happen is the list item ought to be highlighted *right now*, before any start is made on the downloading of the package. You may be thinking "but we should wait until the package is there before highlighting and telling the user that that version is loaded" and I would have a little sympathy with that point. Only a little, though. Yes, the indication that the package is loaded should not be turned on until that package is indeed loaded BUT leaving the user staring at the screen thinking "so did it take note of that click or not?" is criminal. At least, it should be. 
> 
> There are a variety of ways one could indicate to the user that work is in progress. To an extent the correct one depends a little upon just how long the actions is likely to take and that really needs a decent way to calculate that time, not always easy. At the very least we need two levels of highlighting for widgets that trigger actions; the first for right now, the second for job-done. If we can work out a likely duration or have some other way to mark progress then a third stage might be to indicate the partial progress, a bit like the progress bars we already have. A long, long, time ago, the ICL Perq Workstation had a nice way of handling the 'unknown work' case by using a random varying pattern in its progress bars. 
> 
> As a simple first stage I'd like to suggest that buttony/list-item-ish widgets ought to do two-stage highlighting by perhaps drawing an outline highlight immediately the click/press is detected and then doing the full highlight when the action is complete. Just that, hopefully simple, change would improve the user experience a great deal.
> 
> An interesting possibility for a progress indicator might be to show the progress bar within the button/list-item icon; particulalry in a fairly typical MC browser list there is a decent amount of room so that the progress bar could be drawn within the initially outlined (that first indicator, remember) area. That makes a really direct connection between the chosen item and the progress, much better than a floating progress bar somewhere else on the screen. Given the exception based progress bars we already have, it ought to be a change that could be made without affecting the client code, which seems nice.
> 
> For unknown-time actions, a ticker based random pattern progress bar could be provided, using the same mechanism within the widget but a spawned task to do the ticker updating. RISC OS does a simple little trick for such actions where the cursor is swapped to an updating hourglass is the action takes more than some very short time; basically one has a delay for that short time followed by the cursor changing and eventually the code declaring the action complete. If the action completes very quickly then the cursor never gets changed. I'm sure we can do at least as well...
>

There are some good ideas here, and I'll add one more - whatever is done needs
to be done consistently throughout the interface. With that in mind, I'd be
inclined to focus on just one of these ideas and bring it to completion before
taking on the next. IMO, the two-stage highlighting idea seems like something
that would be a real benefit in terms of perceived responsiveness, so I'd vote
for that one.

Dave
 


More information about the Squeak-dev mailing list