- From: Pollington, David, VF-Group <david.pollington@vodafone.com>
- Date: Fri, 15 Feb 2008 12:19:25 +0100
- To: <public-appformats@w3.org>
Hi all, Some initial comments on the Widgets Reqmts doc and Spec: Requirements: - $1.2 Security model; this is stated as being in scope whilst access to platforms APIs is currently out of scope. One approach is that W3C focus solely on the security model for Widgets accessing config parameters and status info (and nothing else). But assuming that we want to evolve the Widget user agent to also expose (have access to) platform APIs (and there is a lot of pull for this), then we need the remit of the security model to be a lot broader. - $1.2 Benefits - currently states that it opens the marketplace for new vendors to come in with their own Widget user agents which to some extent seems to contradict a previous bullet that users will have fewer user agents that they need to install. The aim should be to have one Widget user agent per platform (which on a mobile device probably means only one user agent on the device) and encourage new entrants to come in with their own Widgets hence creating a thriving Widget ecosystem. A final point (which relates to the first bullet) is that rather than necessarily enabling any Widget to be run on any Widget user agent, the aim should be to enable code re-use; in reality a desktop Widget will never be suitable for running directly on a mobile platform without optimisation due to the differing UI constraints. - $3 Design goals: Interoperability - I agree with the principle that the specification should align with existing Widget user-agents but we should also bare in mind that there can be some big differences between PC and mobile platforms (and even within PC depending on whether we're talking about desktop Widgets or Web page Widgets) so we should still keep an eye on what is best long term and what might need to be different based on the target platform (in particular mobile vs PC). - R10 Data Compression - I take the point that mobile data tariffs might currently be considered expensive, but probably not a good idea to include this within a standards doc as the situation is likely to change. What we could add though is a comment on battery life - the smaller the Widget, the quicker the download and therefore less impact on battery life. $4.3 Intro para, third bullet needs updating to reflect that device APIs are currently out of scope R31 XHR - my assumption was that this would be mandatory (currently 'should' not 'must'); have there been any concerns with making this mandatory? To put it in context, the following reqmt R32 regarding inter-Widget communication is a much more advanced concept but also currently a 'should' R33 Language Accessibility - I'm guessing when you say non-graphical UI you're referring to a tab based UI rather than a mouse/cursor based UI. IMHO both approaches should still apply to a graphical UI (?) R.37 Persistent Storage - again I think this has to be mandatory ('must') as it's such an important feature in the overall user experience of using Widgets. I understand that such status information could also stored and retrieved online but the user agent should always offer a local storage option. R.38 Multiple instances - a comment relating to this (and possibly something for section $4.6 on Security) when multiple Widgets are instantiated on a given user agent they should be effectively sand-boxed to prevent one Widget accessing the config data, status or cache of another. My colleagues in our Security team have been developing our own vision for the security model so we should be in a position to contribute something shortly. However, harking back to my previous comment, we will need to be clear what the scope of the security model is and whether it makes more sense specifying this wherever the device API considerations are being held (e.g., OAA, OMTP etc.) Some additional comments: - UI methods: we've run into problems whereby there has been inconsistency in some Widget user agents in the handling of widget UI components such as text boxes (selectable in 'mouse/cursor' mode but not in tab mode); this is an area that might need some additional requirements BUT does it fall within the current charter? - Spec 5.7 Icons - you mention only one permitted but before that in the spec it mentions zero or more (I think); anyway we will need support for at least 2 icons: a static icon which represents the Widget in the Applications folder (for example) and a dynamic icon which can be used in a Widget Gallery/Carousel and provide status information for the Widget without the Widget needing to be opened full screen. For example a stocks Widget might provide an indication of the current price of a share and whether it's up or down; opening the full Widget could then provide a detailed chart, comparison against financial indices etc. To be clarified whether the full Widget would need to be instantiated in order for the dynamic icon presentation level to be supported... Cheers, David David Pollington Senior Manager - Terminals Research Vodafone Group R&D Tel: +44 1635 685504 Mobile: +44 7771 775063 E-mail: david.pollington@vodafone.com Web: www.betavine.net Mobile Web: betavine.mobi Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 -----Original Message----- From: Marcos Caceres [mailto:marcosscaceres@gmail.com] Sent: 04 February 2008 13:28 To: member-appformats@w3.org; Pollington, David, VF-Group Subject: Re: [waf] Scheduling a voice conf for Widgets Hi, I'm OK with either date choice. Both specification have been substantially updated over the last two months. I will be continuing work on the Widget specification throughout the week, so please keep an eye on the cvs logs for changes. David, it would be great to get some feedback on either specification or the req doc... and if you see any requirements missing, then please let us know. I'm hoping we can gather some outstanding security requirements over the next two weeks and republish the req doc. My preference for the teleconf is to discuss the wording of sections 1-4, and steps 1-6 of section 6 of the spec. I'll mostly be working on section 5 this week... if I finish it, then I guess we can also discuss it during our teleconf. Kind regards, Marcos On Feb 3, 2008 8:43 AM, Pollington, David, VF-Group <david.pollington@vodafone.com> wrote: > > > I'd like to be involved (and apologies for being so quiet to-date); I > should be able to attend either Tues or Thurs at the specified time > although will be at 3GSM that week... Thurs probably better if possible. > > Cheers, > > David > > > > David Pollington > Senior Manager - Terminals Research > Vodafone Group R&D > > Tel: +44 1635 685504 > Mobile: +44 7771 775063 > E-mail: david.pollington@vodafone.com > > > Vodafone Group Services Limited > Registered Office: Vodafone House, The Connection, Newbury, Berkshire > RG14 2FN Registered in England No 3802001 > > > > -----Original Message----- > From: member-appformats-request@w3.org > [mailto:member-appformats-request@w3.org] On Behalf Of Arthur Barstow > Sent: 01 February 2008 21:09 > To: member-appformats@w3.org > Subject: [waf] Scheduling a voice conf for Widgets > > > Widget People, > > I would like to schedule a voice conference regarding Widgets with a > tentative agenda of: what's the current status and what are the next > steps? > > We'll need to accommodate people in at least Boston, Oslo, Tokyo and > Brisbane: > > <http://www.timeanddate.com/worldclock/meetingtime.html?month=2&day=1& > ye > ar=2008&p1=43&p2=187&p3=248&p4=47> > > My time preference is: 07:00 Boston; 13:00 Oslo; 21:00 Tokyo and > 22:00 Brisbane. > > My day of the week preferences are: 1st Tuesday and 2nd Thursday > > I would like to meet week #7 and thus Feb 12 or 14. > > If you are interested in attending this call, please submit your prefs. > > I consider the participation of Marcos and Arve as pretty much > mandatory. > > Thanks, AB > === > > > > -- Marcos Caceres http://datadriven.com.au
Received on Friday, 15 February 2008 15:09:34 UTC