W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

RE: [widgets] Widget modes

From: <ivan.demarino@orange-ftgroup.com>
Date: Fri, 30 Jan 2009 19:41:02 +0100
Message-ID: <B877D90AB2240C4D84DF56169F1EAFED05EEEB0F@ftrdmel3>
To: <Mark.Priestley@vodafone.com>, <yoanb@opera.com>, <benoit.suzanne@orange-ftgroup.com>
Cc: <public-webapps@w3.org>

Hello.

Here in Orange Labs UK we think that the idea of having multiple modes with multiple HTML five can address another risk: the need of adapting the presentation layer programmatically, can drive to excessive "cpu-bound" calculation (it's Javascript after all).
Having multiple HTML document could simplify the widget layout itself, having something dedicated to the particular mode.

The preservation of status across different "mode change event" could be solved in other ways, like using APIs for Local Storage (HTML5) or with dedicated APIs.

Also I would like to highlight the importance of "allowing" companion attributes for the "mode" like "width" and "height", as expressed in the last part of Suzanne Benoit email.

Regards

---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, R&D UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demarino@orange-ftgroup.com


This e-mail, and any files transmitted with it, is intended only for the use of the person/s or entity to whom it is addressed. If you are not the intended recipient (or authorised to receive information for the intended recipient) you must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and delete all copies of this e-mail.  Thank you.

France Telecom R&D UK Ltd is a company registered in England and Wales with company number 4193379. Our registered office is Minerva House, Montague Close, London, SE1 9BB.

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Priestley, Mark, VF-Group
Sent: 30 January 2009 12:03
To: Yoan Blanc; SUZANNE Benoit RD-SIRP-ISS
Cc: public-webapps
Subject: 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 18:42:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:29 GMT