Re: Web Widgets, Where Art Thou?

On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote:

>  
> On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> >  
> > On Monday, July 22, 2013 at 11:54 PM, Daniel Buchner wrote:
> >  
> > > To clarify, I am proposing that we make a simple app manifest entry the only requirement for widget declaration: widget: { launch_path: ... }. The issue with viewMode (https://github.com/w3c/manifest/issues/22), is that it hard-binds a widget's launch URL to the app's launch URL, forever tying the widget to the "full app". I'd like to give devs the option to provide a completely different launch path for widgets, if they choose. As for the finer points of widget declaration, why force developers to generate two separate files that regurgitate much of the same information? --> this looks a lot more complex than adding a launch path to an existing file and a few media queries for styling: http://www.w3.org/TR/2009/WD-widgets-reqs-20090430/
> >  
> >  
> > The thing here is that you are adding an explicit "role" or "type" for an application (by declaring "widget":). We view the representation of the application as being more "responsive" than that through a view mode. What you propose explicitly encourages two different applications to be created, instead of a single one that adapts to the context in which it's being displayed. Again, take a look at how Opera's speed dial was making use of view modes.
> >  
> > However, I can see how splitting the two application classes into different resources can be appealing at first… but it goes against the principles of responsive design: it would be like telling people to build a separate desktop site and mobile site, instead of responsibly adapting the content to fit the layout. Using view mode media queries works naturally with the way modern web applications are designed today - they fit naturally into just being another "break point".
>  
> In theory, responsive design seems like the clear answer for widgets - I love making my apps responsive so they work for phone/tablet/desktop etc. However, there are issues with the widget case. In phone/tablet/desktop views, apps still use most or all of an app's data/features, the major differences tend to be in DOM arrangement and style of the content they present. It's easy to think of widgets as a logical next level to that - but that can devolve into the impractical quickly.  
I guess here we would need to see actual data. Like I already mentioned, while I was at Opera, we did not see any issues with partners/devs who made use of this feature.  
> Widgets are (generally) by nature, small presentations of a sliver of app content displayed in a minimalist fashion that update a user to the state of something at-a-glance. Also, many widgets can be in active view at once - consider a home screen with nine 1x1 widgets. If each widget was itself the full app, with the addition of responsive styles, it would be a recipe for crippling performance. Imagine nine Gmail tabs on a screen, nine Facebooks, etc.

Memory management is a shared responsibility between the developer and the UA. You can make both widgets and apps that perform badly in the same way that you can make apps that can run effectively as widgets. In other words, putting things in a separate file won't save a device from a bad developer.   
>  
> The obvious retort will be: "well devs are smart, they'll proactively structure their app, have tiered checks for assets, and place conditions throughout their code to ensure they are catching the *very different* widget use-case everywhere in their app" <-- I'd assert that this is not practical, and in many cases, devs would welcome a clean document they knew was intended specifically for their widget.

The belief that this is not practical has to be supported with data. The same argument could have been made about mobile websites (and in many cases it's true - some organizations have opted to make a mobile variant of their site). The question remains, can a solution that doesn't require additional changes to what we have be used to achieve having different documents for this? If not, then yes - we might need to add a mechanism as you suggest - but I don't think we've exhausted all options here.  
>  
>  
> > > > > while taking advantage of natural synergies that result from reusing
> > > > > a common base.
> > > >  
> > > >  
> > > >  
> > > > I think I agree, but can we be explicit about the things we think we're getting?
> > >  
> > > Many mobile apps include widgets, and users are beginning to think: "Hey, I wonder if this app has a widget?"; some users even seek out apps that provide a companion widget in addition to the app itself. Using an app manifest for packaging is easier on developers, and aligns with user perception of the output.
> > Sure, that might be fine. In the case of W3C Widgets, one simply said:
> >  
> > <widget viewmodes = "floating"/>
> >  
> > Which indicated to the UA that "floating" mode was supported (i.e., you can widgetized it on a home screen).
> >  
> > In hosted apps, we are proposing to have the same thing. See:
> > https://github.com/w3c/manifest/issues/22
> >  
> >  
> > {
> > …
> > "viewModes": ["fullscreen", "maximized"]
> > ...
> > }
>  
>  
> Again, this suffers from the points outline above - good in theory, less than thrilling outcome in practice.  
Again, you need data to show that this is actually a problem (where is the actual *practice* using the mechanisms discussed about that clearly show this as a problem?). You and I have conflicting theoretical viewpoints here: We (WebApps WG) based our design on what was already being used on the Web to cater for adapting content to different layouts (i.e., media queries) - and we have a lot of data that using media queries in the way that view mode media features uses them theoretically works - and we saw them work in at least one, albeit it now dead, implementation (in Presto).  

So, I guess the thing would be to try to quickly dig up a few of the old sites that are using view mode media feature targeted at presto and see if they have a separate page or if they use the same page. That should at least be indicative of who is more right?

Received on Tuesday, 23 July 2013 15:13:12 UTC