|
Size: 152
Comment:
|
Size: 1769
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 OR: if menus or menu functionality already used up by other items, but a menu is needed for the whole app. |
|
| Line 4: | Line 7: |
| Yeah... it's a menu. Docked to an edge. Always visible. Work a lot off the secondary or app-specific menu; more suitable for that than reveal menus. Since it's visible, no learning curve to speak of. Note that it's only this pattern if it happens across an interface; app or OS wide. Controls on a screen do not count. Controlling the weather radar image on one page, just controls. Playback controls for the video player app, same in all modes of it, are a Fixed Menu. |
|
| Line 6: | Line 15: |
| iPhone style, every menu function is visible in a bar or list to one edge of the screen. 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. |
|
| Line 8: | Line 21: |
| Copy from reveal menu, except for the reveal parts. "More items" needs to be included. Can include play controls, so things like photo taking, or photo/video playback often have fixed menus |
|
| Line 10: | Line 29: |
| 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. |
|
| Line 13: | Line 38: |
Problem
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 OR: if menus or menu functionality already used up by other items, but a menu is needed for the whole app.
Solution
Yeah... it's a menu. Docked to an edge. Always visible.
Work a lot off the secondary or app-specific menu; more suitable for that than reveal menus. Since it's visible, no learning curve to speak of.
Note that it's only this pattern if it happens across an interface; app or OS wide. Controls on a screen do not count. Controlling the weather radar image on one page, just controls. Playback controls for the video player app, same in all modes of it, are a Fixed Menu.
Variations
iPhone style, every menu function is visible in a bar or list to one edge of the screen.
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.
Interaction Details
Copy from reveal menu, except for the reveal parts.
"More items" needs to be included.
Can include play controls, so things like photo taking, or photo/video playback often have fixed menus
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