Re: Context menus in XForms

Hi Oskari,

First I want to say how much I liked reading your mail. You really seem 
to have given this great thought :)

> Hi,
>
> Firstly, a few examples of what kind of behavior context menu should be
> able to provide (feel free to add):
> - On a PC, when you right-click you get a hierarchical context sensitive
> pop-up menu.
> - On a Series60 mobile phone, the left soft key is always (by
> convention) labeled "Options" and triggers a hierarchical,
> context-sensitive menu. The right soft key can be anything (depending on
> context).
> - On a Series80 Communicator, there are four soft keys on the right side
> of the landscape screen which may be labeled anything. By convention
> first one is the default action (same as pressing enter or selecting
> with joystick). Hierarchical context menus are not directly supported
> (by convention the more rarely needed things are put into the menu bar),
> though one could of course label one of the soft keys as "Options" and
> make it trigger a hierarchical pop-up menu (this goes against UI style
> convention though).
>
> So, first question, are soft keys different from pop-up menu options?
> I.e. should the form author be able to set the right soft key on a S60
> device, or should he only be able to add things to the menu that appears
> when you press the left soft key? On a more general level, the
> difference is that a device may be able to show a limited number of the
> context-sensitive options to the user as soon as the focus moves to the
> form control, whereas the user has to perform an extra action to see the
> rest of the options. Note that this is not phone or PDA-specific, but is
> also sometimes used on PC UIs (on the bottom of the screen there is
> dynamically changing description of what the function keys do) and could
> be used on voice UIs (some of the options are read out aloud as soon as
> the user navigates to the form control, for the others you have to say
> "options"). One possibility is that the context menu options should be
> listed in importance order, and they are put into soft keys as far as
> possible, with remainder put into a separate menu. Form author can
> specify an appearance such as "softkey" or "options" for a menu item
> e.g. to prevent placing of menu items into soft keys.
>
>   
I think it might be a problem having appearance="softkey" as that make 
the appearance attribute specific to the mobile UI and only make little 
sense on a desktop machine (browser user agents don't normally use the 
F1-F12 and show a meaning full description, I guess AS-400 systems does 
something like that). Maybe it could get that styling information from a 
CSS stylesheet. Since authors can use the @media to apply different 
properties depending on the user agent it will make that solution 
flexible? Could the softkeys actually be selected using the accesskey 
attribute?
> Secondly, while the functionality is superficially like a select1, you
> don't want the binding to be mandatory, but optional like for trigger.
> Also you don't want to be forced to give dummy value elements. Like it
> was said earlier, the menu is an UI concept - like trigger.
>
>   
Yep, agree!
> What this points to, is that a new UI element is needed. In general, the
> concept of a menu seems to have been forgotten from the spec. I would
> propose adding a menu element, which typically is used for navigation or
> for toggling switches, but in this case would be used for context menus.
> There is no need for an appearance attribute in this case, it must be a
> context menu because it is within a form control:
>
> <xf:input>
>   <xf:label>Label</xf:label>
>   <xf:menu>
>     <xf:label>Input Options</xf:label>
>     <xf:item appearance="softkey">
>       <xf:label>Menu Item 1</xf:label>
> 	<xf:action ev:event="DOMActivate">
>         ...
>       </xf:action>
>     </xf:item>
>     ...
>
> Choices element can be used for nesting, and itemset might be useful
> too...
>
>
> Now, just for this one use case you might not like to add a menu
> element, but consider the common case (especially on mobile phones where
> screen is small) where form consists of several parts (switch + cases)
> and the user selects at the beginning where he wants to go:
>
> <xf:switch>
>   <xf:case id="menu">
>     <xf:menu>
>       <xf:label>What do you want to do?</xf:label>
>       <xf:item>
>         <xf:label>Enter part 1</xf:label>
>         <xf:toggle ev:event="DOMActivate" case="part1"/>
>       </xf:item>
>       <xf:item>
>         <xf:label>Enter part 2</xf:label>
>         <xf:toggle ev:event="DOMActivate" case="part2"/>
>       </xf:item>
>       ...
>     </xf:menu>
>   </xf:case>
>   <xf:case id="part1">
>     ...
>   </xf:case>
>   <xf:case id="part2">
>     ...
>   </xf:case>
>   ...
> </xf:switch>
>
>
> Now, one can of course do the same thing with triggers, but that loses
> author intent information which is essential for device independence.
> Typically a menu would be rendered differently than a series of
> triggers. If a separate menu element is used, a device can render it in
> the most appropriate way for the device (and also do things like
> autoassign shortcut keys on mobile phone).
>
> And then there is the case of tabbed panels, which can be done with
> triggers but it is hard and cumbersome, and cannot be made to take
> advantage of built-in tabbed panel widgets because the author intent is
> lost. It is a navigation internal to the switch, so it can easily be
> represented by a menu element which is a child of the switch element.
> Typically this would be rendered as a tabbed panel, but a no-frills
> implementation can also display it as a regular menu.
>
> <xf:switch>
>   <xf:menu>
>     <!-- label is usually ignored in a tabbed panel, but we provide it
> in case tabbed appearance is not supported -->
>     <xf:label>Show:</xf:label>
>     <xf:item>
>       <xf:label>Part 1</xf:label>
>       <xf:toggle ev:event="DOMActivate" case="part1"/>
>     </xf:item>
>     <xf:item>
>       <xf:label>Part 2</xf:label>
>       <xf:toggle ev:event="DOMActivate" case="part2"/
>     </xf:item>
>     ...
>   </xf:menu>
>   <xf:case id="part1">
>     ...
>   </xf:case>
>   <xf:case id="part2">
>     ...
>   </xf:case>
>   ...
> </xf:switch>
>
>
> Note also that an appearance attribute value of "menubar" could be used
> to indicate that the menu should be always kept visible, and should not
> be a part of the focus traversal order (i.e. pressing tab repeatedly
> will not move focus to it). Depending on device it might be shown in top
> or left part of the screen. In a voice environment this might mean that
> the menu is not a part of the normal navigation structure, but is always
> available via some keyword like "menu".
>
> Finally, a no-frills implementation is simple. Don't support appearance
> attribute. For the regular (non-context) menus, use a one-column table
> that contains triggers, first row has the menu label. For the context
> menus, add the menu options to system context menu if you can, otherwise
> add a small button labeled "Options" to the form control which makes the
> menu (= regular table-based menu) visible (hide the menu again once user
> has selected an option). For switch menus (tabbed panels), use a one-row
> table that contains triggers, possibly with label in first column.
>
> Comments?
>   
I really like it all. The only thing I had doubts about was the softkey 
otherwise it looks really good. As you might have seen from one of my 
previous posts I need this functionality now and I would like to make it 
an extension for exforms.org. If no one complains about misusing this 
list I would really like to send the text out here to get some feedback?

Best regards,
David

> BR,
>      --Oskari
>
>   
>> -----Original Message-----
>> From: www-forms-request@w3.org 
>> [mailto:www-forms-request@w3.org] On Behalf Of ext David Landwehr
>> Sent: Wednesday, March 22, 2006 10:48 AM
>> To: www-forms@w3.org
>> Subject: Re: Context menus in XForms
>>
>>
>> Allan Beaufour wrote:
>> Hmm, in my world action elements have no visual appearance...
>>
>>
>> That is a good point! Since the meaning of action is already 
>> overloaded with deferred updates and grouping of other actions 
>> it would make it hard to give it a visual appearance without 
>> getting weird behavior in other places.
>>
>> Maybe it would be better with a completely new element for 
>> this visual construction.
>>
>> ...
>> David
>>
>>
>>     
>
>   


-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------

Received on Monday, 27 March 2006 14:31:28 UTC