RE: [widgets] Widget modes

We share Yoan's concerns. 

In addition believe that in lots of cases most of the content (in the broadest sense) will be the same between modes and only the presentation will need to be changed. In cases in which the content is different, we feel this would be better addressed programmatically and/or through styling, thereby avoiding the need for redundant html.

I would however like to return to the agreement that was made on the call of the 22nd - to list requirements for modes before attempting to agree a technical proposal. I am currently working on a strawman to circulate early next week but from this email exchange I will add something like:

"It MUST be possible to maintain the state of a widget when moving between widget view modes."

I would encourage anyone who has an opinion on this topic to try and formulate their thoughts in the form of requirements. I will then be happy to collate and, as far as possible, merge into a single set of requirements for discussion.  

Many thanks,

Mark




   

>-----Original Message-----
>From: public-webapps-request@w3.org 
>[mailto:public-webapps-request@w3.org] On Behalf Of Yoan Blanc
>Sent: 30 January 2009 09:52
>To: SUZANNE Benoit RD-SIRP-ISS
>Cc: public-webapps
>Subject: Re: [widgets] Widget modes
>
>
>The problem I see by having different html pages for each mode 
>is that you cannot handle keeping the state of a widget when 
>changing from one mode to the other.
>
>expanded -> iconized -> expanded
>
>I expect my widget to stay in the same state.
>
>> <content src="minimumbackgroundaction.js" mode="hidden"/>
>
>How is this supposed to work?
>
>The state of the application while running is stored into its 
>content file, into window (for the JavaScript part) and 
>document (for the HTML part).
>
>Regards,
>
>--
>Yoan
>Widget Developer, Opera Software ASA
>
>
>On Thu, 29 Jan 2009, SUZANNE Benoit RD-SIRP-ISS wrote:
>
>> Hi all, about the widget windows modes, I wanted to share 
>the following points:
>> 
>> *** Wording ***
>> In the wordings of the modes, I think that the wording used 
>in some of the modes are too specific to existing platforms, 
>therefore I propose the following names:
>>  *  Icon: I'm not sure this one is really a mode as it is 
>already dealt with in the rest of the spec in the right manner 
>with a static image format
>>  *  Iconized: this mode will allow to define an icon that 
>can be adapted to the content status, for example a weather 
>icon will display the right cloud or sun based on the real 
>time information. This is possible using the svg, but I 
>believe this is one of the
>>     modes of displaying information in a widget.
>>  *  Expanded: this is the reference to the existing floating 
>mode in the spec or the undocked mode for vista
>>  *  Minimized: this is the reference to the existing docked 
>mode in the spec but is too restrictive in the wordings
>>  *  Full screen: now for this one my worry is more the fact 
>that there are other attributes that should be available for 
>this mode as the display can be specific to the orientation 
>(landscape or portrait) and to the size of the screen's device 
>(vga, qvga, ...)
>>  *  Hidden: I like the proposition from mark to allow a 
>widget to run as a background task that can awaken an action, 
>so you would probably need to add this as a mode as well.
>>  *  Settings: I would also like to add the settings of the 
>widget as a specific mode as this will largely simplify the 
>coding of the widget where all the various screens to display 
>will all be defined as modes.
>> 
>> ***Context***
>> The way I see this implemented is that based on the platform 
>actions (drag on a widget bar for example) the platform would 
>switch from one view to the other. Or based on a code input in 
>the hidden mode, a widget would be able to call it's Minimized 
>mode through
>> the code. In this context the one thing that needs to be 
>included is how to pass parameters from one mode to the other, 
>but that could be resolved using some kind of parametered declaration.
>> 
>> ***Usage***
>> I do not see the mode as an element, but as an item of the 
>content element, see examples below.
>> 
>> ***Code example***
>> In the format to use the modes I propose the following as a 
>bases for discussions:
>> <content src="miniview.html" mode="minimized"/>
>> <content src="index.html" mode="expanded" default="true" 
>flying="true"/>
>> <content src="fullscreen-vga.html" mode="fullscreen" 
>width="640" height="480"/>
>> <content src="fullscreen-wvga.html" mode="fullscreen" 
>width="854" height="480" orientation="landscape"/>
>> <content src="fullscreen-wvga.html" mode="fullscreen" 
>width="854" height="480" orientation="portrait"/>
>> <content src="minimumbackgroundaction.js" mode="idden"/>
>> <content src="settings.html" mode="settings"/>
>> 
>> 
>> What do you think?
>> 
>> Best Regards, Benoit
>> 
>>
>>       [IMAGE]
>>       Benoit  Suzanne
>>       Widget Factory Project Manager - Orange Labs - 
>FT/RD/SIRP/SOL/SLAM
>>       t. +33 (0)145 298  198 - m. +33 (0)680 287 553
>>       benoit.suzanne@orange-ftgroup.com
>>       [IMAGE]
>> 
>> 
>> 
>> 
>>
>

Received on Friday, 30 January 2009 12:03:42 UTC