|
Size: 552
Comment:
|
Size: 2784
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Usually page, but also chunks of the page... Same element for whole device. All the stuff we talk about, like size, bezel obscuring, indicator or interactive, relative size (suggested!) and so on. Space saving techniques like letting it overlay content, vs being a strip, and letting it disappear being not suggested (how to tell where you are without scroll, when eyes are somewhere else often). | == Problem == More information is in the page or element than can fit in the viewport. A method of access to this information must be provided. |
| Line 3: | Line 4: |
| == Problem == | |
| Line 6: | Line 6: |
| Scrollbars, long used in information display systems of all sorts, |
|
| Line 8: | Line 10: |
| Primary direction: vertical suggested, sometime horizontal (define why! data that applies, generally)... Additional secondary direction: sometimes a short scroll a secondary direction is needed, such as zooming on a web page (which is generally vertical). Why is this secondary??? Does it anchor more, or... anything else??? Just the part where we allow the scrollbar that direction to be obscured more (behind SKs, as we did for browsers) maybe... Very rarely, two equal directions, such as a photo. Do not confuse this pattern with the [[Infinite Area]] patterns, either in one or two dimensions, which does not use scrollbars due to the arbitrarily large data set presented. |
|
| Line 10: | Line 20: |
| Only items in focus scroll... if multiples, be clear which is in focus... Cannot grab the scrollbar directly, as a general rule. Phones too small, so it would allow accidental grabbing of page content. Instead, touch scroll on page... care to not click items and detect scroll actions. Great care with draggable items in a scroll area. Try to avoid drags that go the same direction as the scroll; use multi-finger gestures, etc. Scroll-and-select generally scrolls by item, line by line for select lists, jumps link to link on pages. But never jump past a link... at which point (or if no links) down and up scroll at a reasonable speed. Scroll acceleration and inertia... |
|
| Line 12: | Line 32: |
| Scroll indicators are not used in mobile devices to enable scrolling, but to: 1. Provide an affordance (communicate the function) that the area is scrollable. 1. Convey the current location within the total content. 1. Indicate the relative amount of information the viewport displays, as a ratio of the total content. Show an indicator, always! When do you not? Relative size of viewport:total based on size of scroll indicator. Location and relative size need to be absolutely true, even if lazy loaded. SEE OTHER PATTERN Doesn't need to be huge. Bars can be as small as 2 px. If you have a large bezel or overscan, much larger, but current devices expose the whole screen and tend to have no bezel occlusion, so this is fine Or, a bar that sticks out further When a scrolling area is displayed, but is not in focus so scroll actions will have no effect, this must be communicated somehow. Generally, simply removing the scroll indicators will do, but often the secondary value of the indicator (position and |
|
| Line 15: | Line 52: |
Problem
More information is in the page or element than can fit in the viewport. A method of access to this information must be provided.
Solution
Scrollbars, long used in information display systems of all sorts,
Variations
Primary direction: vertical suggested, sometime horizontal (define why! data that applies, generally)...
Additional secondary direction: sometimes a short scroll a secondary direction is needed, such as zooming on a web page (which is generally vertical). Why is this secondary??? Does it anchor more, or... anything else??? Just the part where we allow the scrollbar that direction to be obscured more (behind SKs, as we did for browsers) maybe...
Very rarely, two equal directions, such as a photo.
Do not confuse this pattern with the Infinite Area patterns, either in one or two dimensions, which does not use scrollbars due to the arbitrarily large data set presented.
Interaction Details
Only items in focus scroll... if multiples, be clear which is in focus...
Cannot grab the scrollbar directly, as a general rule. Phones too small, so it would allow accidental grabbing of page content.
Instead, touch scroll on page... care to not click items and detect scroll actions. Great care with draggable items in a scroll area. Try to avoid drags that go the same direction as the scroll; use multi-finger gestures, etc.
Scroll-and-select generally scrolls by item, line by line for select lists, jumps link to link on pages. But never jump past a link... at which point (or if no links) down and up scroll at a reasonable speed.
Scroll acceleration and inertia...
Presentation Details
Scroll indicators are not used in mobile devices to enable scrolling, but to:
- Provide an affordance (communicate the function) that the area is scrollable.
- Convey the current location within the total content.
- Indicate the relative amount of information the viewport displays, as a ratio of the total content.
Show an indicator, always! When do you not?
Relative size of viewport:total based on size of scroll indicator.
Location and relative size need to be absolutely true, even if lazy loaded. SEE OTHER PATTERN
Doesn't need to be huge. Bars can be as small as 2 px. If you have a large bezel or overscan, much larger, but current devices expose the whole screen and tend to have no bezel occlusion, so this is fine
Or, a bar that sticks out further
When a scrolling area is displayed, but is not in focus so scroll actions will have no effect, this must be communicated somehow. Generally, simply removing the scroll indicators will do, but often the secondary value of the indicator (position and
Antipatterns