RE: If not Multiple-Contents, how do we have Widgets with multiple modes?

Hi Ivan, Marcos, All,

Some specific comments inline, marked [mp]. I will send out a separate
email outlining a proposal that we believe meets the requirement around
modes.

A more general comment - from Ivan's email, a requirement I would add to
the list I communicated in [1] is:

"A widget MUST be able to adapt its layout in response to the mode in
which it was initialised."
 
Thanks,

Mark

[1] http://www.mail-archive.com/public-webapps@w3.org/msg02038.html


>-----Original Message-----
>From: public-webapps-request@w3.org 
>[mailto:public-webapps-request@w3.org] On Behalf Of Marcos Caceres
>Sent: 13 February 2009 13:27
>To: ivan.demarino
>Cc: public-webapps
>Subject: Re: If not Multiple-Contents, how do we have Widgets 
>with multiple modes?
>
>
>Hi Ivan,
>
>2009/2/9 ivan.demarino <ivan.demarino@orange-ftgroup.com>:
>> Hello.
>>
>> I'm following the specs evolving for Window Modes 
>(http://dev.w3.org/2006/waf/widgets/#window-modes).
>> Given the fact that the "content tag" has an occurrence of 
>"0 or 1", and the fact that the "mode" is one, my question is:
>>
>> - Would it be possible to have widgets that have "multiple views"?

[mp] IMO yes, in a number of different ways. I will send a separate
email explaining how.

>> I dug into the "widgets-api", and what it looks like is the 
>fact that the only place where the widget should handle "mode 
>change" is the call-back named "onmodechange()".
>>
>> That's fine.
>>
>> But we are assuming that there is an "initial mode" chosen 
>by the Developer and that the widget "change it's shape" based 
>on the event "onmodechange".
>>
>> - What if the Developer can't know in which mode the Widget 
>will start?

[mp] This is obviously a requirement that needs to be addressed. Note
that it could be done using media queries or by querying the
widget.viewmode attribute in javascript.

>We could make it explicit that the widget user agent should 
>attempt to start the widget in the mode the author declared 
>(or in floating, as is the default).

>> - What if the "User-Agent" running the Widget does not pass 
>a "onmodechange", because NO MODE WAS CHANGED: it was simply 
>initialized with a mode different from the one chosen in the 
>"config.xml"?
>>
>
>We could specify that a user agent must fire a mode change 
>event if it initializes the widget in a mode other than the 
>default or the mode that the author specified.

[mp] IMO it would be better just to fire an event or media query
whenever the widget was initialised, whether or not it was opened in the
preferred mode.

>> It's a bit "tricky" to explain, but I can give more details 
>if needed.
>
>If the above would not help, then more details would be 
>helpful to build a use case.
>
>> One of the great thing of having "widgets with multiple 
>modes", is the fact that the same widget can run in different 
>scenarios, based on the hosting platform screen resolution AND 
>other requirements. The widget has to adapt itself at "load time".
>>
>
>Right.
>
>> A widget that, for example, run in "window mode" and just 
>after load has to change to "docked", because that's the mode 
>supported by the current User-Agent, will look "clunky" and 
>"not seamlessly integrated".
>>
>> What do you think?
>
>This may be true. Can you go into more details about how we 
>might overcome this? is this an author's problem or a user 
>agent problem?
>what more can we do on the user agent side to overcome this issue?

[mp] I would suggest that if the user agent only supported docked mode,
it would open the widget in that mode (not window mode) and the widget
would adapt its content accordingly.

>Kind regards,
>Marcos
>--
>Marcos Caceres
>http://datadriven.com.au
>
>

Received on Thursday, 19 February 2009 12:21:26 UTC