UI feedback badness in 4.4-12550-ish image

> 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...
>

> 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.

> On 22 May 2013 02:49, David T. Lewis <[hidden email]> wrote:
> > 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.
>
> It sounds like ToolBuilder would be the appropriate lever to use here.
> Not in the sense of implementing the functionality directly, but in
> the sense that ToolBuilder-Morphic (etc) makes sure the various
> widgets behave in this manner. Tools that construct their UIs using
> ToolBuilder would then Just Work.
>
> MC browsers need to be rewritten to use ToolBuilder. However, that
> work is decoupled from making ToolBuilder-Morphic do this UI feedback
> thing right.

>
> On 21-05-2013, at 6:49 PM, David T. Lewis <[hidden email]> wrote:
> >
> > There are some good ideas here, and I'll add one more - whatever is done needs
> > to be done consistently throughout the interface.
>
> Absolutely; inconsistency can ruin a user experience (except in rare cases where it is the core of the experience).
>
> > 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.
>
>
> Certainly. We just need someone with appropriate knowledge to decide to tackle it.
>

>
> On 22-05-2013, at 5:03 AM, David T. Lewis <[hidden email]> wrote:
> >>
> >> Certainly. We just need someone with appropriate knowledge to decide to tackle it.
> >>
> >
> > You mean someone with a strong background in Squeak coupled with expertise in
> > UI design fundamentals and a personal interest in improving the user experience?
> > Where might we find such a person?
>
> You forgot a really, really, important pair of requirements;
> a) working knowledge of current morphic
> b) time
>

>
> A next step could be to show a wait cursor while the model is performing
> its actions for the selection, iff the action takes some noticeable time
> (else the cursor flickers annoyingly).
>
> For the http repository it would be even better to have some kind of
> download manager, which wouldn't block the ui while downloading. (But it
> could have the side effect users downloading unneeded versions in excess).
>
> Cheers, Bal?zs

> Hi!
>
> I copied it to trunk along with a new version of Monticello, which makes the
> progress bar show right before the http request gets sent. The old behaviour
> displayed it after the first chunk of the response arrived.
>
> This makes the ui even more responsive. I would wait for a better time with
> Tim's idea of progress showing list items, when progress is more steady. Now
> it would be a burl in the implementation, not giving enough advantage for
> its size imo.