Re: Web Widgets, Where Art Thou?

On Mon, 29 Jul 2013 21:22:38 +0200, Daniel Buchner <daniel@mozilla.com>  
wrote:

> FWIW, I ran a dev poll last week: ~95% of respondents preferred

Sorry Daniel, but without a clear statement of methodology, selection of  
respondents, and the actual questions, this is equivalent to "my friends  
tend to agree with me on issues we think are important". I.e.  
unsurprising, but not very informative about any group other than "people  
like me".

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

[a bunch of stuff snipped since it isn't given with sufficient context to  
interpret usefully]

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

That's not very surprising. The name was badly chosen, since the same word  
has been used for about three times as long to describe the things that  
Web Components allow - objects that provide some kind of conventional  
interactive behaviour.

> Given the miniscule level of adoption/use of the current widget scheme,

Please define your terms a bit more clearly.

The TV industry is relatively slow-moving since like it or not they don't  
have easily upgradeable firmware and users upgrade TVs only very slightly  
faster than fridges. But there is a high (to mimic the approach to  
quantitative measurement we have so far in this discussion) level of  
widget uptake in "smart" TV. Some ecosystems like Blackberry and Sencha  
are well-known, but it is not so obvious that they are using the existing  
widget stack basically as-is. There are digital signs all over the place,  
 from supermarket tags in poor old spain to Times Square, Picadilly Circus,  
and more or less all of Tokyo - and again this industry has a high level  
of widget uptake.

These are stacks that are converging with the Web. Like mobile, we can  
expect the collective weight of these players to have a serious impact on  
the industry as a whole - although it will probably take some a few years  
to catch up.

> and the fact the proposed addition of a lighter declaration via the app
> manifest wouldn't affect use of the old spec,

Divergence - providing developers with two ways to do the same thing -  
either means that one system will die and be replaced (requiring everyone  
who relied on it to retool from the ground up), or that implementors will  
end up supporting two systems, and every small semantic divergence between  
the two (names for a term, parameters required, …) will end up being a  
minefield of error-correction and bugtrapping.

> I'm having trouble understanding why this proposal is facing such stop
> energy.

I don't think there is any stop energy - I don't see anyone saying "let's  
not work on making it easier to build apps that work whether installed or  
online, whether built as responsive to their environment or rebuilt each  
time". I see a bunch of poeple warning you that they have been doing this  
work for many years already, that there are real deployments and there is  
a lot of experience with real user feedback (e.g. "I'd like a faster horse  
please") and the sort of things that are and aren't problems at a higher  
level (e.g. "digital signatures are really hard" or "Apple's claimed  
patent on auto-update systems is a non-issue if you implement the way  
everyone else does, otherwise it might have to be looked at more deeply if  
you don't want to invite a lawyer-fest into your ecosystem").

Please, continue the discussion, but it is reasonable to expect that  
people will question things quite closely if you expect a global industry  
to invest millions of dollars in something...

cheers

Chaals

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


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 30 July 2013 12:59:52 UTC