Re: Focus navigation in mobile profile

Hello Kari,

> I just went through the WICD Mobile 1.0 specification (http:// 
> and I noticed something  
> strange in the focus navigation model (3.8).
> You have defined that some devices MUST implement the focus  
> navigation, but the referred focus navigation section is completely  
> INFORMATIVE. How can you demand that informative parts of the spec  
> MUST be implemented??
> "Conformant WICD Mobile 1.0 user agents, for devices that have a  
> multi directional (2D) joystick input device, must implement a Two  
> Dimensional Focus Navigation with Flattened Children. For guidance  
> see Navigation Models in WICD Core 1.0."
> The referred Navigation Models section: 6.3 Focus Navigation Models  
> (This section is informative).

We have updated section "6.3 Focus Navigation" in WICD Core.

This section is now normative. In addition the text now starts by  
stating: "This section describes several focus navigation models.  
WICD Core does not mandate a specific focus navigation model. But  
device-specific WICD profiles should define which focus navigation  
models are required. WICD profiles may require at least one of the  
following navigation models."

The latest editor drafts, with these changes, can be found here: 

> I'm also puzzled about the navigation to children, it seems you  
> have an unnecessary extra step there. The section 3.8 says:
> "Conformant WICD Mobile 1.0 user agents, should allow activation of  
> hierarchical child elements, using the "Ok" key." - why?? From  
> usability point of view, it would be easier if the focus simply  
> enters the focusable elements in the child. Why the user has to  
> press 'ok' button?? To me, this seems unnecessary. Can't the focus  
> simply enter the focusable elements of the children?

WICD Mobile agents support flattened children. Authors only need to  
set <param name="focusable" value="flat" /> on a child, in order to  
remove the need for child activation using the Ok button (see WICD  
Core 6.1.2). Flattened children behave exactly as you desire. In some  
cases, however, it is not advisable to flatten a child. One such case  
may be an interactive MP3 player implemented inside a child. Such a  
child could capture joystick up/down events, in order to control the  
audio volume and maybe joystick left/right events to skip over songs.  
If such an interactive child would be flattened into the parent, it  
would be easy to enter, but impossible to leave. Whenever there is a  
need for a hierarchical child (like for such a MP3 player), it is  
necessary to first enter it, using the Ok button.

> "Conformant WICD Mobile 1.0 user agents, implemented on devices,  
> that have at least two soft keys and no dedicated escape key,  
> should allow deactivation of hierarchical child elements, using  
> longpress Soft2."
> Again, why the user cannot simply step out of the child using the  
> arrows?

See above.

> And how can you say that it is always soft key 2? On my mobile  
> phone, the back button is on the left side and the menu button on  
> the right side. Are you insisting that the right soft key must  
> always behave as you want, even though it is against the phone UI  
> guidelines??

If a device provides a dedicated escape (or back) button, it should  
be used to allow the user to leave a hierarchical child. Only if no  
such button is available should "longpress Soft2" be used to provide  
the same functionality. We selected this event, because it is rather  
unlikely for child content to depend on this event for internal  

> Also, I don't think many users will find such hidden long press  
> features in their phones.

Authors can make sure their child content will work in flattened  
mode, so this problem will not arise.

> To me, it looks like you have forgotten to mark the section 3.8 as  
> INFORMATIVE, I cannot see any other purpose for that section.

I think we need normative text here.

Please let us know within two weeks whether you agree/disagree with  
our course of action.

Timur Mehrvarz
On behalf of the CDF WG

Received on Wednesday, 21 February 2007 22:19:46 UTC