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

I've now integrated the requirements below into the Requirements spec [1].

In acknowledgment of the work that Mark has done on both the Dig
Sig/Security requirements and Window modes, I've added him as
co-editor (now he can also get the blame!:) ).

Please also note that I have switched to CSS counters for the
requirement numbers, meaning that they are dynamically inserted into
the document... not all browsers support CSS counters, so apologies if
you can't see the generated content.

Kind regards,
Marcos
[1] http://dev.w3.org/2006/waf/widgets-reqs/

On Tue, Feb 24, 2009 at 2:29 PM, Marcos Caceres <marcosc@opera.com> wrote:
> 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
>



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

Received on Friday, 6 March 2009 13:02:37 UTC