RE: Context menus in XForms

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.

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.

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?

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
>
>

Received on Saturday, 25 March 2006 23:32:57 UTC