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

Hi All,
The following draft requirements for display modes were formulated
during the F2F based on Mark's strawman proposal (also below). Please
feel free to comment.

=== General Requirements ===

RXX. Display Modes
A conforming specification MUST specify a set of display modes for
widgets that stipulate how widgets SHOULD be rendered at runtime when
in a specific mode. A conforming specification SHOULD also define
particular allowed, or disallowed, user-interaction behaviors for each
display mode; such as the ability for a widget to be dragged or
re-sized. For each display mode, the way in which the widget is
displayed MUST be specified so that the rendering of the Widget is as
consistent as possible across widget user agents. The display modes
SHOULD also be specified to interoperate with device independence best
practices and/or specifications. Proprietary display modes MAY be
supported by the Widget User Agent.

Rationale: To provide authors with a variety of commonly widget
display modes and to help ensure that their widgets are renders as
consistently as possible across different Widget User Agents. In
addition, allowing proprietary display modes provides a means to
support innovative user experiences.

==CONFIGURATION DOCUMENT REQUIREMENT==

R.XX Preferred display modes
A conforming specification MUST provide a means for author to indicate
at least one preferred display mode for a widget. In the absence of a
preferred mode, a conforming specification SHOULD provide a consistent
default display mode across all user agents. A conforming
specification SHOULD make it possible for an 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, but SHOULD NOT ignore the preferred display mode.

Rationale: To provide authors a means to indicate a preference over
how their widget is initially rendered, though this would not be not
guaranteed by the widget user agent. A means of declaring the
preferred display mode also provides authors some reassurance, as some
widgets may be better suited to being displayed in one display mode
over the others. As already stated, widget user Agents may choose to
ignore the author's display mode preference, for example, if they do
not support the indicated display mode.

I don't agree with: "A conforming specification SHOULD make it
possible for an author to indicate to the widget user agent which
display modes the widget has been designed to run in." This should be
handled via CSS media queries and handled by the author.

==API AND EVENTS REQUIREMENT===
Rxx Display mode API and Events
A conforming specification MUST provide an API to allow authors to
programmatically switch between display modes. A conforming user agent
MUST be allowed to ignore requests by the author to switch to an
unsupported display mode, but MUST throw an exception or error if it
will not perform the mode change. A conforming specification MUST also
provide a guaranteed means for authors to detect a change in display
mode. A conforming specification MUST provide a means for an author to
check the current display mode of a widget.

==USER AGENT REQUIREMENT==
Rxx. Display Mode Switching
A conforming specification MUST allow a widget user agent to
dynamically change display mode of a widget. Switching from one mode
to another, however, MUST not cause the re-instantiation of the
Widget. Furthermore, it MUST be possible for a Widget to seamlessly
move between modes, maintaining runtime state and any processes that
are in progress.

Rationale: To allow a widget user agent to have a degree of control
over how widgets are displayed for the purpose of mediating the user
experience. For example, the widget user agent my attempt to switch
all widgets into floating mode and then display them in a 3D carousel.


2009/2/3 Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>:
> 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.
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 24 February 2009 13:29:56 UTC