Re: Web Widgets, Where Art Thou?

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".  

> > > 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"]
...
}


  

> > For example, many browsers now use some form of JSON to write a manifest that (other than the syntax) is almost identical to the XML packaging used for widgets. And as JC noted there are actually numerous systems using the XML Packaging and Configuration.
> >  
> > > I see widgets as a web page (perhaps the same page as a "full" app,if the dev chooses) with near-zero additional, cognitive overhead.
> >  
> > I'm afraid I have no idea what this means in practice.  
>  
> I was referring to the choice (detailed above) a developer has to use the app launch path, or an different URL, as their widget path, and to do so via a common declaration vehicle. That simplifies the declaration side. On the code side, I would stay away from adding any mechanisms (other than display helpers, like widget-specific media queries) to the widget context - the message: just use the same APIs you would use for any other app/page. With today's web, are these APIs really necessary? --> http://www.w3.org/TR/widgets-apis/
Yes, they are totally required unless you want developers do deal with i18n things themselves. It takes away the pain of finding out which localized values the app is using from the manifest.   

> > > - I believe we should retool efforts in this area to focus on sharing the app packaging vehicle and reducing complexity to near-zero (besides things like widget-specific media queries)
> >  
> > This is where it is critical to know what you think is "near-zero complexity". Having seen a couple of systems deployed based on JSON packaging (Google and Mozilla), and a bunch of them based on the current XML Widget Packaging, I personally find the latter far less complex. But I realise not everyone thinks like I do.
>  
> If you asked the average client-side web developer, who lives primarily in HTML, CSS, and JS, I would bet a trillion dollar coin that the overwhelming majority prefer JSON for description, packaging, and data transmission - consider: web app manifests, NPM, Bower, and nearly every client-consumed web-service API launched in the last 4 years.  
Sure. Again, being biased, I don't think we had a single complaint from devs about the format being XML while I was at Opera (we built an extremely robust parsing algorithm based on HTML5's parser, which made it much easier to work with than JSON). In practice, it doesn't make much of a difference (you gotta close your "}" or your tags in both). Of course, JSON has become more prevalent in the time that W3C widgets were developed. It's why we are redoing everything in JSON now (including having to rewrite a lenient JSON-post processor for the hosted apps manifest format) - so JSON is not without its own problems - you get very little for free.

Received on Tuesday, 23 July 2013 11:45:28 UTC