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...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BA: Branch Approximate
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
On 21-05-2013, at 6:49 PM, David T. Lewis lewis@mail.msen.com 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.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Only playing with 51 cards.
On Tue, May 21, 2013 at 09:43:59PM -0700, tim Rowledge wrote:
On 21-05-2013, at 6:49 PM, David T. Lewis lewis@mail.msen.com 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.
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?
;-)
Dave
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Only playing with 51 cards.
On 22-05-2013, at 5:03 AM, David T. Lewis lewis@mail.msen.com 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
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Ignorant, and proud of it.
On Wed, May 22, 2013 at 10:15:19AM -0700, tim Rowledge wrote:
On 22-05-2013, at 5:03 AM, David T. Lewis lewis@mail.msen.com 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
Ah, but I see an interesting submission in the inbox now :)
Name: Morphic-kb.652 Author: kb Time: 22 May 2013, 4:50:12.27 pm UUID: 73334963-ccc3-4f41-8fec-fc64d40db333 Ancestors: Morphic-fbs.651
Implementation of pre selection highlight in PluggableListMorph. See the discussion here: +http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-May/171143.html
Hi!
Morphic-kb.652 is a first stab at implementing two-stage highlighting of list selections. It changes PluggableListMorph behaviour, which is the superclass of MorphicToolBuilder list classes. That means all ToolBuilder built lists should be affected. Monticello already uses ToolBuilder if it's present (see MCTool>>buildWindow), so the repository inspector responsiveness is fixed to some extent.
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
On 22-05-2013, at 11:46 PM, Balázs Kósi rebmekop@gmail.com wrote:
Morphic-kb.652 is a first stab at implementing two-stage highlighting of list selections. It changes PluggableListMorph behaviour, which is the superclass of MorphicToolBuilder list classes. That means all ToolBuilder built lists should be affected. Monticello already uses ToolBuilder if it's present (see MCTool>>buildWindow), so the repository inspector responsiveness is fixed to some extent.
Thank you for taking a shot at this.
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).
Actually I'd prefer not to use the cursor; I'll admit that it can be an easy way to indicate activity but it's also too easy to lose track of the state it ought to be in. Imagine clicking on a button for a long-running action, moving out of the Squeak window, doing something else, going back to Squeak - what state is the cursor? What if the action finished in the meantime? Much nicer to have the button or list item do some happy-dance to indicate progress. It keeps the information exactly where it belongs.
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).
I can't argue with that point. I would say that having the progress from such a download tool reported back to the original list item to update the highlighting as if it were a progress bar would be even nicer.
Let's try adding some (crappy) images to show - starting -
selected - partway complete action
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim No single raindrop believes it is to blame for the flood
On Thu, May 23, 2013 at 08:46:38AM +0200, Bal?zs K?si wrote:
Hi!
Morphic-kb.652 is a first stab at implementing two-stage highlighting of list selections. It changes PluggableListMorph behaviour, which is the superclass of MorphicToolBuilder list classes. That means all ToolBuilder built lists should be affected. Monticello already uses ToolBuilder if it's present (see MCTool>>buildWindow), so the repository inspector responsiveness is fixed to some extent.
Thanks for doing this, I like it a lot. I used to have to push really hard on the mouse button to get a selection, and now I will not need to do that ;-)
I vote to move it to trunk.
Dave
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.
Cheers, Balázs
On 24 May 2013 20:49, Balázs Kósi kosi.balazs@ezomer.hu wrote:
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.
Hey, that's cool!
frank
Cheers, Balázs
On 2013-05-24, at 21:49, Balázs Kósi kosi.balazs@ezomer.hu wrote:
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 a lot of difference. Well done!
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.
Cheers, Balázs
On my machine I hardly see an effect of the preselection. Perhaps it is too fast? Maybe if it already showed on mouse-down and not only on mouse-up?
- Bert -
On 26-05-2013, at 9:32 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On my machine I hardly see an effect of the preselection. Perhaps it is too fast? Maybe if it already showed on mouse-down and not only on mouse-up?
I think not seeing the split highlighting is a good indication that your machine is performing adequately for the task.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Multitasking: Screwing up several things at once...
Hi Folks,
I've just published some updates for Cuis related to this at www.github.com/jvuletich/Cuis. I added two stage highlighting both to regular and hierarchical lists, and both when clicking and navigating with the keyboard. I also made Cuis to automatically show the busy cursor when "busy", and this allowed removing some 80 calls to 'Cursor wait showWhile: []', cleaning a lot of evil references from model to view...
Quoting Balázs Kósi rebmekop@gmail.com:
Hi!
Morphic-kb.652 is a first stab at implementing two-stage highlighting of list selections. It changes PluggableListMorph behaviour, which is the superclass of MorphicToolBuilder list classes. That means all ToolBuilder built lists should be affected. Monticello already uses ToolBuilder if it's present (see MCTool>>buildWindow), so the repository inspector responsiveness is fixed to some extent.
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
Cheers, Juan Vuletich
On 27-05-2013, at 7:20 PM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
I've just published some updates for Cuis related to this at www.github.com/jvuletich/Cuis. I added two stage highlighting both to regular and hierarchical lists, and both when clicking and navigating with the keyboard. I also made Cuis to automatically show the busy cursor when "busy", and this allowed removing some 80 calls to 'Cursor wait showWhile: []', cleaning a lot of evil references from model to view…
Nice; better UI and simpler code FTW.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- All foam, no beer.
On 22 May 2013 02:49, David T. Lewis lewis@mail.msen.com 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.
frank
Dave
On Wed, May 22, 2013 at 08:48:03AM +0100, Frank Shearar wrote:
On 22 May 2013 02:49, David T. Lewis lewis@mail.msen.com 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.
This sounds right to me.
Dave
frank
Dave
On Tue, May 21, 2013 at 6:37 PM, tim Rowledge tim@rowledge.org wrote:
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.
As a student and practitioner of Ward Cunningham's approach to UI design (and XP development), I wholeheardtedly agree with Tim. I was fortunate to meet Ward in 1994 and to have one of his colleagues as my mentor. In his paper, "The CHECKS Pattern Language of Information Integrity" Ward advocates a non-intrusive, non-modal UI style. I highly recommend reading it if you're interested in making user-interfaces that interact appropriately with people.
Above, Tim is proposing we "Echo Back" confirmation of user-input:
http://c2.com/ppr/checks.html#4
I'd bet it wouldn't be difficult to do -- we know we can draw a 1-pixel border around any rectangle, and whatever action is performed on mouseClick (or on mouseDown vs. mouseUp) said border could be drawn, then the action, THEN the highlight. Sounds good!
squeak-dev@lists.squeakfoundation.org
-
Balázs Kósi -
Balázs Kósi -
Bert Freudenberg -
Chris Muller -
David T. Lewis -
Frank Shearar -
Juan Vuletich (mail lists) -
tim Rowledge