Re: Web Widgets, Where Art Thou?

On Mon, Jul 22, 2013 at 11:55 PM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> On Mon, 22 Jul 2013 09:59:33 -0700, Daniel Buchner <daniel@mozilla.com>
> wrote:
>
>  In my opinion, the current spec's complexity in relation to its feature
>> goal, is high.
>>
>
> I think it is pretty important to this discussion to understand what parts
> of the widget framework you think bring complexity (or alternatively, bring
> little value).
>
> Different people interpret complexity very differently. For example there
> are many developers today who find JSON extremely comfortable and flexible.
> But others find it extremely limited (no common internationalisation
> mechanism, the strictness of the syntax is almost invisible being expressed
> only in tiny punctuation marks, no clear comment mechanism, ...)
>
> Without a clear idea of what you mean by complexity (or clarity) it is
> very hard to understand what your statement means, and therefore what
> should be changed...
>

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/


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


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


> Declaration via the app manifest is a huge piece - I'd argue that
> this alone would realize a huge increase in developer utilization.
>

I suspect this is a very common perception.
>
>  Let's look at current consumer perception of widgets, and how the space
>> is evolving:
>>
>>    - Widgets are commonplace on mobile platforms
>>    - In the view of consumers, search, discovery, and purchase/
>>
>          installation of widgets is now distinguishable from apps
>
> Do you mean "indistinguishable"?
>

I did, sorry about that :)

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