Re: Web Widgets, Where Art Thou?

FWIW, I ran a dev poll last week: ~95% of respondents preferred a simple,
separate HTML document specifically for their widget and use all the
existing DOM APIs and modules from across the web for things like storage,
localization, etc. In fact, of the only 2 respondents opposed to the idea,
one fundamentally misunderstood the widget concept and the other
accidentally selected the wrong option.  Here are some of their qualitative
responses:

 Why did you choose the option you did? Use a separate widget document
declared via your app manifest? I like the separation of files for the high
level conceptual mental model of my app. So, I tend to defer to the latter
suggestion/other option in the interest of performance. Yes separation of
concern, smaller foot print when only the widget is open; we can use a
shared background worker to make the full-site loading faster by reusing
the same core js thread anyway. Yes Separation of concerns. I would much
rather have a common set of library code, and two html files that use that
library code differently. Mixing two very different behaviors like a full
app and a widget into one html file sounds gross. Yes Inheritance of styles
and integration into presentation layer, maintenance. Likely not going to
work so easily via a shadow DOM, though styling has been available for some
composite elements. The second method also gives greater portability to
devices that don't yet support shadow-DOM implementations.

For sufficiently small 'widgets' that are nothing but a small API-able
event driven interface, option 1 is viable when legacy support isn't.

**** This user misunderstood a few things, and seemed to believe that
widgets are somehow bound to Web Components*

No
I like to have standalone chunks of functionality. **** This user selected
the wrong option, but I still counted it toward `No`*
No It's easier. And better for the user. Yes Testability and
maintenance YesIn my experience there is no universal cut and dry
answer to this question
(yet). Yes It's probably much more work to adapt the style of a full app to
turn it into a widget. And it will be possible to modify the full-app
without altering the widget. Yes

Given the miniscule level of adoption/use of the current widget scheme, and
the fact the proposed addition of a lighter declaration via the app
manifest wouldn't affect use of the old spec, I'm having trouble
understanding why this proposal is facing such stop energy.


On Tue, Jul 23, 2013 at 8:12 AM, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
>
> On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote:
>
> >
> > On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres <w3c@marcosc.com(mailto:
> 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.
> I guess here we would need to see actual data. Like I already mentioned,
> while I was at Opera, we did not see any issues with partners/devs who made
> use of this feature.
> > 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.
>
> Memory management is a shared responsibility between the developer and the
> UA. You can make both widgets and apps that perform badly in the same way
> that you can make apps that can run effectively as widgets. In other words,
> putting things in a separate file won't save a device from a bad developer.
> >
> > 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.
>
> The belief that this is not practical has to be supported with data. The
> same argument could have been made about mobile websites (and in many cases
> it's true - some organizations have opted to make a mobile variant of their
> site). The question remains, can a solution that doesn't require additional
> changes to what we have be used to achieve having different documents for
> this? If not, then yes - we might need to add a mechanism as you suggest -
> but I don't think we've exhausted all options here.
> >
> >
> > > > > > 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.
> Again, you need data to show that this is actually a problem (where is the
> actual *practice* using the mechanisms discussed about that clearly show
> this as a problem?). You and I have conflicting theoretical viewpoints
> here: We (WebApps WG) based our design on what was already being used on
> the Web to cater for adapting content to different layouts (i.e., media
> queries) - and we have a lot of data that using media queries in the way
> that view mode media features uses them theoretically works - and we saw
> them work in at least one, albeit it now dead, implementation (in Presto).
>
> So, I guess the thing would be to try to quickly dig up a few of the old
> sites that are using view mode media feature targeted at presto and see if
> they have a separate page or if they use the same page. That should at
> least be indicative of who is more right?
>
>
>
>
>