Specifications/Trays

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).

Interaction spec

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.

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.