[widgets] Strawman requirements for widget (view/display/window) modes

Hi All,
 
Closing the action 291
(http://www.w3.org/2008/webapps/track/actions/291) please find below a
strawman for a set of requirements relating to widget
(view/display/window) modes. I have tried to define the requirements
without basing them on any of the technical solutions that have been
discussed to date.
 
I am in no doubt that the proposed requirements need discussion and
refinement - essentially, they are meant only as a starting point. It's
over to the group now to agree how best to progress them - I welcome any
suggestions on how they could be improved.
 
Thanks,
 
Mark
 
---------------------------------------------------------------------
Strawman Requirement for widget modes
---------------------------------------------------------------------
 
1. There MUST be a defined set of display modes for a Widget. For each
defined display mode, the way in which the Widget is displayed MUST be
specified so that the rendering of the Widget is consistent across
Widget User Agents. The display modes SHOULD be based on the most common
display modes existing in widget implementations today. Proprietary
display modes MAY be supported by the Widget User Agent.

Rationale: This is required if Widget Authors are to be able to design
Widgets that work across different Widget User Agents in a consistent
manner. Without this feature, Widget Authors will end up developing
Widgets for specific Widget User Agents.  Failure to define a core set
of display modes will also confuse Users. Allowing proprietary display
modes provides a means to support innovative UIs. 

2. There MUST NOT be a display mode for each possible screen dimension. 

Rationale: Such an approach is not scalable and fails to leverage the
ability to define flexible layouts, e.g. using CSS and JavaScript.

3. It MUST be possible for a widget author to indicate the preferred
display mode of a Widget.

Rationale: Some Widgets will suite being displayed in a particular
display mode. Having designed the Widget to run in a particular display
mode the author should be able to request that the Widget opens in that
display mode. Widget User Agents may choose to ignore this indication,
for example if they do not support the indicated display mode.

4. It SHOULD be possible for a widget author to indicate to the Widget
User Agent which display modes the Widget has been designed to run in.
The Widget User Agent MAY ignore the indications of display mode
supported.

Rational: Some Widgets will not be designed to work in some modes. It
should be possible for the author to indicate this to the Widget User
Agent. This allows the Widget User Agent to provide a better user
experience, e.g. by advising the user that the widget is not designed to
work in a particular display mode. 

5. It MUST be possible for a widget author to indicate the preferred
dimensions of the widget in each display mode in the Configuration
document of the Widget. The Widget User Agent MAY ignore the preferred
dimensions. 

Rationale: The Widget Author may have designed their Widget such that
viewing it with larger or smaller dimensions than those indicated will
negatively effect the user experience. This is especially true in the
case in which Widgets are expected to run on devices with very different
screen dimensions, e.g. a mobile, a monitor, a TV. 

6. Switching from one mode to another MUST not require the
re-instantiation of the Widget. Furthermore, it MUST be possible for a
Widget to seamlessly move between modes, maintaining any processes that
were in progress.

Rationale: Users will expect the "state" of their widget to be
maintained when switching between modes. 

7. It MUST be possible for a Widget to change the content it presents
for rendering in reaction to a display mode change.

Rational: The Widget may need to adapt the content displayed when it
moves from one mode to another. 

8. It MUST be possible for a Widget to change its behaviour in reaction
to a display mode change.

Rational: The Widget may need to adapt its behaviour when it moves from
one mode to another, for example if a content is changed, actions
related to new/removed elements might need to be started/stopped. 

9. The Widget User Agent MAY display the same instance of a Widget in
multiple display modes at the same time, subject to any behavioural
restrictions based on individual display modes. If supported, it SHOULD
be possible to react to user interaction with one display mode in the
other display modes.

Rationale: To allow maximum flexibility in UI design, while ensuring a
certain level of consistency across Widget User Agents.

10. The Widget User Agent MUST be able to move a Widget between display
modes. 
 
Rational: If a Widget User Agent supports multiple display modes it
should allow the user to switch between display modes at runtime. It is
for discussion whether a Widget should be able to move itself to a new
display mode as there may be security concerns dependent on the display
modes that are defined.