Differences between revisions 2 and 3
Revision 2 as of 2010-12-02 00:41:56
Size: 578
Editor: shoobe01
Comment:
Revision 3 as of 2011-01-23 19:01:25
Size: 2002
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
 * '''Adjacent''' -

 * '''Superimposed''' -
Line 13: Line 17:
click to act...

For either version, only allow access to buttons that can take effect in the current state. If a web page has completed loading, do not allow a "Stop" function to work.

Do not accept

For either case, it is best to assume that the request will take a brief time to take effect, and to account for accidental double-taps, and other mistaken inputs. Do not allow conflicting actions, such as "Stop" immediately followed by "Reload" within about 1/2 second.
Line 16: Line 27:
For either version, only allow access to functions that are available in the current state. Suppress or "gray-out" buttons that do not apply. For functions already submitted, a more subtle state change may take effect to imply the button has converted to an indicator. For example, when a "Synch" button has been pressed, the icon should animate to indicate the synch operation is occurring. Remember that many remote operations, even just stopping a request, will take some coordination to take effect; the in-progress state will take a significant amount of time so must be represented.

When a status area is present, such as those described in '''[[Notifications]]''', the any current behavior should also be indicated there. This should be true for actions that will result shortly in the process becoming idle. A command to cancel loading should display "Stopping..." or similar.

As one thing, since sometimes you use a single location. Must offer refresh for more than web browser URLs, so a single idea... I think. NOT just for browsers, because you might have to synch any number of services (see Infinite List); make note they should all be there if ANY are. If you can press a synch button, and it loads, it better have a stop button if it's failing or using too much system resources.

Problem

Solution

Variations

  • Adjacent -

  • Superimposed -

Interaction Details

click to act...

For either version, only allow access to buttons that can take effect in the current state. If a web page has completed loading, do not allow a "Stop" function to work.

Do not accept

For either case, it is best to assume that the request will take a brief time to take effect, and to account for accidental double-taps, and other mistaken inputs. Do not allow conflicting actions, such as "Stop" immediately followed by "Reload" within about 1/2 second.

Presentation Details

For either version, only allow access to functions that are available in the current state. Suppress or "gray-out" buttons that do not apply. For functions already submitted, a more subtle state change may take effect to imply the button has converted to an indicator. For example, when a "Synch" button has been pressed, the icon should animate to indicate the synch operation is occurring. Remember that many remote operations, even just stopping a request, will take some coordination to take effect; the in-progress state will take a significant amount of time so must be represented.

When a status area is present, such as those described in Notifications, the any current behavior should also be indicated there. This should be true for actions that will result shortly in the process becoming idle. A command to cancel loading should display "Stopping..." or similar.

Antipatterns

Examples

Reload, Synch, Stop (last edited 2011-07-31 21:53:39 by shoobe01)