Keyboard Interaction for Re-ordering Portlets

[Joseph Scheuhammer]

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

*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 
> container.
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?).

-- 
;;;;joseph

'This is not war -- this is pest control!'
      - "Doomsday", Dalek Leader -