|
Size: 1175
Comment:
|
Size: 3296
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| If your device has no functionality for a menu button, softkey, etc. present a menu... (but Pre gets around with a drag!) Or... make options clear in all cases | There is a need for access to options or controls across the application, but a '''[[Revealable Menu]]''' is already in use, or would be unsuitable due to lack of controls or conflicts with other key interactions. |
| Line 6: | Line 6: |
| Yeah... it's a menu. Docked to an edge. Always visible. | An always-visible menu or control set is docked to one edge of the viewport. This is often used for media players, cameras and other applications where a key set of controls or options should be visible at all times. Any time there is a need for immediate action or a learning curve must be avoided (discovering a '''[[Revealable Menu]]''') then a '''Fixed Menu''' is a good solution. Note that this pattern is being used only if it happens across the entire OS or an entire application. Controls on a single screen are simply controls. Controlling the weather radar image on one page is just a set of controls. Playback controls for a video player which are the same in all modes, are a '''Fixed Menu'''. |
| Line 10: | Line 14: |
| iPhone style, every menu function is visible in a bar or list to one edge of the screen. | Fixed list... |
| Line 12: | Line 16: |
| If a revealable menu is available, may also present some key tasks in a Fixed Menu always visible on the screen. Doesn't count any old control on the page, just a set that are grouped and appear in the same place for the application or whole OS. | Also with "more" which pops up a vertical list... Often used in concert with a '''[[Revealable Menu]]''', but must be deconflicted. Both are best when placed along the bottom of the viewport. If the closed paradigm for the '''[[Revealable Menu]]''' has visibility, that may need to be changed, the visible tabs minimized in some manner, or the '''Fixed Menu''' may need to float higher up or be attached to a different side of the viewport. |
| Line 16: | Line 22: |
| Copy from reveal menu, except for the reveal parts. | Fixed menus are either used for pen and touch devices, or when the page content does not have to be interacted with directly, such as video playback; the controls are the primary interaction method. |
| Line 18: | Line 24: |
| "More items" needs to be included. | Fixed menus are not contained in a modal dialogue, and the entire page content can be accessed as much as needed. If it is not accessed as a matter of course, such as for video playback, this does not change the general state of the interaction. Other controls may also exist on the page, and are accessible at any time. |
| Line 20: | Line 26: |
| Can include play controls, so things like photo taking, or photo/video playback often have fixed menus | For devices with 5-way pads, opened menus should be able to be scrolled through. Touch and pen devices use direct selection of the items in the menu. For controls, drag and other gestural actions (such as to change zoom level or jog to another portion of a video file) may also be supported. Selection of any single item will initiate the action, which may load a new page, change states of the current content, cause a modal dialogue of options to appear or even exit the application. When the options in a subsidiary dialogue are simple, they should be docked to the original selection. If preventing obscuring of the primary content is key, or if selection inherently disrupts other primary functionality, these subsidiary menus may be press-and hold items; with touch or pen devices, press the menu item, then drag over to the selection and release when it is focus. "More items"... |
| Line 24: | Line 34: |
| Copy from reveal menu, except for the closed parts. | Copy from reveal menu, except for the closed parts. Or, refer back to it even??? Docked to an edge. Never scroll |
Problem
There is a need for access to options or controls across the application, but a Revealable Menu is already in use, or would be unsuitable due to lack of controls or conflicts with other key interactions.
Solution
An always-visible menu or control set is docked to one edge of the viewport.
This is often used for media players, cameras and other applications where a key set of controls or options should be visible at all times. Any time there is a need for immediate action or a learning curve must be avoided (discovering a Revealable Menu) then a Fixed Menu is a good solution.
Note that this pattern is being used only if it happens across the entire OS or an entire application. Controls on a single screen are simply controls. Controlling the weather radar image on one page is just a set of controls. Playback controls for a video player which are the same in all modes, are a Fixed Menu.
Variations
Fixed list...
Also with "more" which pops up a vertical list...
Often used in concert with a Revealable Menu, but must be deconflicted. Both are best when placed along the bottom of the viewport. If the closed paradigm for the Revealable Menu has visibility, that may need to be changed, the visible tabs minimized in some manner, or the Fixed Menu may need to float higher up or be attached to a different side of the viewport.
Interaction Details
Fixed menus are either used for pen and touch devices, or when the page content does not have to be interacted with directly, such as video playback; the controls are the primary interaction method.
Fixed menus are not contained in a modal dialogue, and the entire page content can be accessed as much as needed. If it is not accessed as a matter of course, such as for video playback, this does not change the general state of the interaction. Other controls may also exist on the page, and are accessible at any time.
For devices with 5-way pads, opened menus should be able to be scrolled through. Touch and pen devices use direct selection of the items in the menu. For controls, drag and other gestural actions (such as to change zoom level or jog to another portion of a video file) may also be supported.
Selection of any single item will initiate the action, which may load a new page, change states of the current content, cause a modal dialogue of options to appear or even exit the application. When the options in a subsidiary dialogue are simple, they should be docked to the original selection. If preventing obscuring of the primary content is key, or if selection inherently disrupts other primary functionality, these subsidiary menus may be press-and hold items; with touch or pen devices, press the menu item, then drag over to the selection and release when it is focus.
"More items"...
Presentation Details
Copy from reveal menu, except for the closed parts. Or, refer back to it even???
Docked to an edge. Never scroll
Note they CAN disappear... but only for full-screen playback types of items. They re-appear on any interaction, not by a deliberate Menu callback, hence do not at that point become reveal menus.
Antipatterns