On Tue, 23 Jul 2013 13:44:56 +0200, Marcos Caceres <w...@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
use.
> > - 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.
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
