Keyboard Interaction for Re-ordering Portlets

[Sean Keesler]

Sorry, everyone, that was a misplaced email!

Sean


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
>> 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?).
> 
> ------------------------------
> Sean Keesler
> Project Manager
> The Living SchoolBook
> 030 Huntington Hall
> Syracuse University
> 315-443-4768
> 
> 
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

------------------------------
Sean Keesler
Project Manager
The Living SchoolBook
030 Huntington Hall
Syracuse University
315-443-4768