Keyboard Interaction for Re-ordering Portlets
smkeesle at syr.edu
Wed Jan 16 19:29:25 UTC 2008
Sorry, everyone, that was a misplaced email!
On 1/16/08 12:00 PM, "Sean Keesler" <smkeesle at syr.edu> wrote:
> Does the username msmarcoe ring a bell?
> On 1/16/08 11:46 AM, "Joseph Scheuhammer" <clown at utoronto.ca> wrote:
>> Previously, I stipulated that "focus" means the target of keyboard
>> events. With that in mind...
>> Shaw-Han wrote:
>>> - Tab key works as it does on My Yahoo or uPortal currently, focusing
>>> first on the portlet's container, and then each internal link in
>>> sequence. For the purposes of the reorderer, if a link within a portlet
>>> is in focus, we treat that portlet as 'selected'. When the last link in
>>> a portlet is focused, and the tab key is pressed, we should move to the
>>> first link in the next portlet.
>> I interpret this as saying:
>> - that keyboard focus is moving around "inside" the portlet for every
>> tab press -- that focus is on a link* within the portlet.
>> - arrowing does not move focus. It changes the appearance of other
>> portlet frames to indicate that it is selected.
>> - tabbing from the last link* in a portlet moves keyboard focus to the
>> next link.
>> Regarding the last point: shouldn't tabbing from the last link in a
>> portlet move to the container of the next portlet? And then to the
>> first *link in the the next portlet? (This is Anastasia's point, I
>> *Regarding links: don't you mean any focusable element within the portlet?
>>> - When a portlet is selected, the arrow keys are used to select adjacent
>>> portlets. When a new portlet is selected, we change focus to the portlet
>> This doesn't seem to fit with the first set of rules above, namely,
>> focus is moved by tabbing; selection by arrowing. Going back to the
>> first set of rules, I think there needs to be a way to move focus
>> "abruptly" from one portlet to another via yet another key stroke. That
>> is, the user moves focus to something within a portlet via tabbbing.
>> They can then select (but not move focus) by arrowing. If the want to
>> move focus to the now selected porlet, they have to hit some other key
>> to indicate that. But, that seems clunky.
>> Perhaps it is better to move focus between portlets using the arrow
>> keys. That is, tabbing works as it does now -- a fine-grained movement
>> of focus from focusable element to focusable element. But arrowing
>> immediately moves focus at the coarser grain of portlet-to-portlet.
>> That way tabbing continues to work the way it does now -- you noted that
>> users expect a portal to behave as any other web page does with respect
>> to tabbed navigation.
>> Having said that, I'm not sure that this covers all the issues yet
>> (e.g., if focus is on a link in a portlet, and user moves by arrow to
>> another portlet, but then moves back to the original portlet, should
>> focus return to the previously focused link?).
> Sean Keesler
> Project Manager
> The Living SchoolBook
> 030 Huntington Hall
> Syracuse University
> fluid-work mailing list
> fluid-work at fluidproject.org
The Living SchoolBook
030 Huntington Hall
More information about the fluid-work