Specifications/Trays: Difference between revisions
m (Tray control moved to Specifications/Trays: This is a specification page) |
m (Reverted edits by 65.188.241.8 (Talk) to last version by 87.5.116.246) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
==Visual spec== |
|||
From [http://dev.laptop.org/2713 Ticket 2713]. It was initially about activity tray so it needs to be made more generic. |
|||
===Size=== |
|||
Trays will support 2 sizes. Generally spanning the full width of the screen, the standard tray will be 75px high and the large tray will be 150px tall. Anytime they do not fill the screen's width, their width should be a multiple of their height where possible to make paging natural. |
|||
The frame is broken into 75px square cells, which means there are 16 cells across the bottom of the frame. The corner cells are never used, which limits the edge to 14 cells. When there are more than 14 activities, the left and right cells should become arrow cells, thus limiting the number of activities visible to 12 per "page". |
|||
===Placement=== |
|||
| ⚫ | |||
Within activities, trays will exist primarily along the bottom edge of the screen. Optionally, we could allow the embedding of trays within toolbars as well (as the sole control within a given tab). |
|||
| ⚫ | |||
===Tabs=== |
|||
==Interaction spec== |
|||
===Type Associations=== |
|||
===Paging=== |
|||
| ⚫ | When an arrow at either end of the tray is clicked, the 12 icons visible should "slide" left or right by a full twelve icons, revealing the next page. When the last page is reached, it should still scroll over a full twelve, revealing a non-full bar. For instance, when there are fifteen activities, clicking the right arrow would scroll over to reveal 3 total activities on page 2. |
||
Note that, though the arrow icon itself is small, the entire rectangular region it sits in, up to the screen edge, should be clickable. |
|||
| ⚫ | I'm uncertain about whether or not we want to support looping back to page one. If one method is easier than the other, chose that one for now. If they are equally easy, let me know and I'll think about the interaction a bit more. (no looping is what we get by default, implementing looping animation might be tricky depending on how we decide to animate it exactly --marco) |
||
The scrolling animation should be perceivable but quick. I'd say 1/3 second, perhaps. Ideally it should have an ease-out and perhaps an ease-in also. Steady scrolling always feel mechanical; some acceleration and deceleration would help. |
The scrolling animation should be perceivable but quick. I'd say 1/3 second, perhaps. Ideally it should have an ease-out and perhaps an ease-in also. Steady scrolling always feel mechanical; some acceleration and deceleration would help. |
||
===Drag'n'Drop=== |
|||
It would be ideal if this solution were developed in a modular way since we'll need this paging in various other locations, including the people edge of the frame, and later on within the tray element which will become a standard control. |
|||
===Rollover Palettes=== |
|||
Each object within a tray will have an associated palette, as specified by the developer. This will provide a place for naming the object and the person who created it. The list of associated actions may include the option to remove the object from the tray. |
|||
Latest revision as of 06:51, 10 January 2009
Visual spec
Size
Trays will support 2 sizes. Generally spanning the full width of the screen, the standard tray will be 75px high and the large tray will be 150px tall. Anytime they do not fill the screen's width, their width should be a multiple of their height where possible to make paging natural.
Placement
Within activities, trays will exist primarily along the bottom edge of the screen. Optionally, we could allow the embedding of trays within toolbars as well (as the sole control within a given tab).
Tabs
Interaction spec
Type Associations
Paging
When an arrow at either end of the tray is clicked, the 12 icons visible should "slide" left or right by a full twelve icons, revealing the next page. When the last page is reached, it should still scroll over a full twelve, revealing a non-full bar. For instance, when there are fifteen activities, clicking the right arrow would scroll over to reveal 3 total activities on page 2.
Note that, though the arrow icon itself is small, the entire rectangular region it sits in, up to the screen edge, should be clickable.
I'm uncertain about whether or not we want to support looping back to page one. If one method is easier than the other, chose that one for now. If they are equally easy, let me know and I'll think about the interaction a bit more. (no looping is what we get by default, implementing looping animation might be tricky depending on how we decide to animate it exactly --marco)
The scrolling animation should be perceivable but quick. I'd say 1/3 second, perhaps. Ideally it should have an ease-out and perhaps an ease-in also. Steady scrolling always feel mechanical; some acceleration and deceleration would help.
Drag'n'Drop
Rollover Palettes
Each object within a tray will have an associated palette, as specified by the developer. This will provide a place for naming the object and the person who created it. The list of associated actions may include the option to remove the object from the tray.