Re: Web Widgets, Where Art Thou?

On Tue, Jul 23, 2013 at 4:44 AM, 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: ... }. 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".


In theory, responsive design seems like the clear answer for widgets - I
love making my apps responsive so they work for phone/tablet/desktop etc.
However, there are issues with the widget case. In phone/tablet/desktop
views, apps still use most or all of an app's data/features, the major
differences tend to be in DOM arrangement and style of the content they
present. It's easy to think of widgets as a logical next level to that -
but that can devolve into the impractical quickly. Widgets are (generally)
by nature, small presentations of a sliver of app content displayed in a
minimalist fashion that update a user to the state of something
at-a-glance. Also, many widgets can be in active view at once - consider a
home screen with nine 1x1 widgets. If each widget was itself the full app,
with the addition of responsive styles, it would be a recipe for crippling
performance. Imagine nine Gmail tabs on a screen, nine Facebooks, etc.

The obvious retort will be: "well devs are smart, they'll proactively
structure their app, have tiered checks for assets, and place conditions
throughout their code to ensure they are catching the *very different*
widget use-case everywhere in their app" <-- I'd assert that this is not
practical, and in many cases, devs would welcome a clean document they knew
was intended specifically for their widget.

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

This comment is in accurate for a few reasons:

   - We know consumers no longer distinguish (in general) between apps and
   widgets. Heck, on Android you even find them in the same category on the
   Play store - no one cares
   - If users see apps as widgets, widgets as apps, and some as both, why
   fight it? Other ecosystems proved that these two variants of content (at
   least) can be declared in one vehicle - this is not
   a groundbreaking concept.
   - This isn't the same as annoying sites that nag you about downloading
   their app - that's a poor comparison
   - Who says an app package needs to contain a base launch_path? Could we
   not modify the app spec to state that if the main app launch_path is
   omitted, but another type of launch_path is present, that the UA installs
   only the specified functionality? (a widget in this case)



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

Again, this suffers from the points outline above - good in theory, less
than thrilling outcome in practice.