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.
