W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

Re: Web Widgets, Where Art Thou?

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Tue, 23 Jul 2013 14:16:13 +0200
To: "Daniel Buchner" <daniel@mozilla.com>, "Marcos Caceres" <w3c@marcosc.com>
Cc: JC VerdiƩ <jc.verdie@mstarsemi.com>, public-webapps <public-webapps@w3.org>
Message-ID: <op.w0ocdby6y3oazb@any.yandex.ru>
On Tue, 23 Jul 2013 13:44:56 +0200, Marcos Caceres <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: ... }.

OK. In Opera we did this with something like

  <link rel="widget">

I wrote an extension for Yandex Browser (should work for more or less any  
chromium-based browser) that took about 6 lines to point to a widget from  
a hosted app.

The link element seems to me clearer than havig to carry a manifest that  
points to a launch point that would in turn have to carry its own  
manifest. And for an app that is actually responsive, I agree with Marcos  
that this sounds counter-intuitive.

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

Yeah, you get that with link...

>> 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/

I'm a bit sceptical...

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

For non-adaptive designs, maybe. But we start running into the "No I don't  
want to download your !@#$%^&* app" UI issue pretty fast, so this should  
be done with a bit of thinking if the goal isn't to annoy users more than  
help them (yes clippy, I am looking at you).

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

OK. There are lots of ways to skin that cat, as noted above. In  
particular, there are some developers who want to make separate versions  
of everything, and some who want to make an app that will function equally  
well whether hosted on the web or installed. (Hence the endless  
discussions about how to make the emchanisms for that work better)

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

Yeah, there are a bunch of things that are simplified by the API, and  
making developers build their own libraries for it doesn't strike me as a  
win. My experience from making widgets is completely the opposite - having  
the API there saves masses of work, and it is pretty straightforward to  

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

I believe this if you ask US-based small-shop developers. We still release  
APIs with XML response because there is demand for it, and I think the  
benefits of JSON are sometimes overplayed. While it is relatively compact  
and familiar to people who live in javascript, it is less intuitive than  
XML to a surprisingly large number of developers.

It really suffers from being terrible for internationalisation, although  
that is something a company working in multiple scripts and languages sees  
more than people who only work in english.

And it isn't otherwise as free as it seems. I guess Mozilla and Google  
will continue to work with JSON, so it is important to take taht into  
account. But others will continue to find it extremely limited, while  
requiring a high-degree of complexity for a limited set of features. As  
far as I can see it currently makes sense to continue doing what we do and  
produce/consume both JSON and XML, and keep the two in synch.



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Tuesday, 23 July 2013 12:16:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:12 UTC