Bugzilla – Bug 13668
Design/implement pagination controls for overflow text on "text + options" screens
Last modified: 2011-11-06 23:25:23 UTC
After discussing with Matt Cuson, this is a P1 for 7.4 release. Assigning to Noah so he can remind me to discuss it today (screen comps are already done I believe, not sure about assets)
Created attachment 5689 [details] Ref artwork - paginate top NOT a spec, rather where the development of this idea was left...
Created attachment 5690 [details] Ref artwork - paginate bottom
Yes, I know it's crazy to add P1s at this point. But the verdict is that we really need this for launch. It will have a BIG impact on usability and product quality IMHO. So this screen template will apply to "App Gallery" description pages, setup pages, etc - basically screens with selectable options + supporting text. ------ Basics ------ - Supporting text is displayed in the top area of the screen, between the title bar and the selectable menu option(s). - If the copy overflows this area, is is truncated (...) and pagination controls are added in the right-side of the area (we estimate the range of pages to be about 1-7, based on how many pagination icons it is reasonable to display in the worst-case scenario) - moving up/down (or moving the scroll wheel/knob) switches between "pages" in the supporting text area. The currently selected "page" is highlighted in the column of boxes on the right. - if the user is viewing the bottom "page" of copy, and moves down another notch, the first menu item becomes selected and vice versa. - "looping" menu navigation (i.e., if I'm on the bottom menu option and I keep scrolling down, I end up at the top) should be REMOVED from this type of screen (I'd actually be ok with killing that behavior entirely if we have to, IMHO) ----------------- Layout Variations ----------------- The number of menu items on the screen should determine the ultimate layout. If only 1 menu option is available (such as "install" on the App Gallery "description" screens), then the supporting text area expands to take up the remaining space on the screen. Thus on baby, in this case the supporting text area would have the equivalent height of three menu item "slots," with the fourth "slot" being taken up with the single menu option. Here's where it gets mildly complicated. The max number of menu items that should display on baby is 2; on jive and fab4 it's 3. Use a scrollbar when needed when there are more menu items than space. ----------------- Assets ----------------- Noah has (I believe) checked the assets for this screen into SVN, which should include artwork for the pagination controls and divider lines between the menu items (this type of screen will always have an initial state with no menu items selected, which will look weird without the divider line).
*** Bug 12625 has been marked as a duplicate of this bug. ***
Created attachment 5705 [details] Ref artwork - paginate MAX w/ divider line We will need to add back in the 1px menu divider line for all menus to make this work right. Could actually be a good all around enhancement to the non-touch skins. The problem is with this example when no menu item is selected there is no division btwn the 2 options.
retargeting for 8.0 after other shorter-term fixes were discussed with Tom/Noah.
Tom is no longer available to us
Unassigned bugs cannot have a priority.