Re: Web Widgets, Where Art Thou?
On Mon, 29 Jul 2013 21:22:38 +0200, Daniel Buchner
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 wrote:
On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote:
>
> On Tue, Jul 23, 2013 at 4:44 AM, 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: ...
}.
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
Re: Web Widgets, Where Art Thou?
Hi Daniel, On Monday, July 29, 2013 at 8:22 PM, Daniel Buchner wrote: > FWIW, I ran a dev poll last week: ~95% of respondents What was the sample size? Who were the developers? Where was the poll run? > 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: How did you select the sample of responses you sent us? Can I have access to the complete questionnaire? I need to check the validity and reliability of the questions as well as the overall design of the poll - as the ordering of the questions can influence answers as well as how the questions are phrased, etc. If it's a non-probabilistic sample (as it appears to be), we can't conclude anything definitive from it because it's not representative - though it can be indicative of something descriptively, but not inferentially. > 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. Please don't confuse questions for "stop energy" - the costs of standardization (social/monetary) is extremely high - specially so if we don't do it right, so there will be a lot of scrutiny on anything being proposed.
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 wrote:
>
>
>
> On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote:
>
> >
> > On Tue, Jul 23, 2013 at 4:44 AM, 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: ... }.
> 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 impract
Re: Web Widgets, Where Art Thou?
On Tuesday, July 23, 2013 at 3:06 PM, Daniel Buchner wrote:
>
> On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres (mailto: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: ... }.
> > > 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 e
Re: Web Widgets, Where Art Thou?
On Tuesday, July 23, 2013 at 4:12 PM, Marcos Caceres wrote: > 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? I tried looking for some sites, but failed. You are free to do a search also. Otherwise, we will need to find some other way to move forward on this. -- Marcos Caceres
Re: Web Widgets, Where Art Thou?
On Tue, Jul 23, 2013 at 4:44 AM, Marcos Caceres 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:
>
>
>
> Which indicated to the UA that "floating
Re: Web Widgets, Where Art Thou?
On Tuesday, July 23, 2013 at 2:29 PM, JC Verdié wrote: > > > > Right, but this is a platform/system issue (how events traverse through the > > system). This was outside the scope of the work. > > Agreed. But it's been a hurdle and I don't know how many companies just > gave up about widgets because of this. I think this will come up if one moves to using hosted-web apps in TV like environments too (sounds like an overall architectural problem for the Web platform). If you can describe the problem more fully, I think we should absolutely look into this and then see where it needs to be fixed. When replying, please change the subject of the email appropriately.
Re: Web Widgets, Where Art Thou?
Marcos Caceres wrote: On Tuesday, July 23, 2013 at 1:56 PM, JC Verdié wrote: Hi Marcos, Obviously as you point out, digsig were a nightmare. May be it was us, but the spec was not really straightforward to implement and we found it difficult. As lead Editor, I'm really very sorry about this - I strive to make specs as accessible to everyone as possible, and I'm sorry if what was written was confusing/difficult to interpret. If there are bits that should be clarified, then please let me know and I'll see what I can do to improve it. We're talking about long-lasting history here :) I'd need to ask the developers from this time if they do remember what's been the biggest problems. Stay tuned. On widgets itself, our main issue came from our own constraints (TV browser with no chrome ui), it lead to some inconsistencies to handle to overall UX. For instance, the impossibility to handle user events on a global level so that buttons used for exit or any immediate actions are not caught up by the widget, but by the "root" application. We hacked in several ways to achieve this but it was a disappointing point. Right, but this is a platform/system issue (how events traverse through the system). This was outside the scope of the work. Agreed. But it's been a hurdle and I don't know how many companies just gave up about widgets because of this. I guess what I'm saying is we missed a wider view of how widgets are handled, run, die, and interact with the browser itself. Despite this, it's been very useful to us and we have deployed many solutions based on it, so anything that keeps compatibility with widgets is good to us Happy to hear.
Re: Web Widgets, Where Art Thou?
On Tuesday, July 23, 2013 at 1:56 PM, JC Verdié wrote: > Hi Marcos, > > Obviously as you point out, digsig were a nightmare. May be it was us, > but the spec was not really straightforward to implement and we found it > difficult. As lead Editor, I'm really very sorry about this - I strive to make specs as accessible to everyone as possible, and I'm sorry if what was written was confusing/difficult to interpret. If there are bits that should be clarified, then please let me know and I'll see what I can do to improve it. > On widgets itself, our main issue came from our own constraints (TV > browser with no chrome ui), it lead to some inconsistencies to handle to > overall UX. For instance, the impossibility to handle user events on a > global level so that buttons used for exit or any immediate actions are > not caught up by the widget, but by the "root" application. We hacked in > several ways to achieve this but it was a disappointing point. Right, but this is a platform/system issue (how events traverse through the system). This was outside the scope of the work. > I guess what I'm saying is we missed a wider view of how widgets are > handled, run, die, and interact with the browser itself. > > Despite this, it's been very useful to us and we have deployed many > solutions based on it, so anything that keeps compatibility with widgets > is good to us > Happy to hear.
Re: Web Widgets, Where Art Thou?
Hi Marcos, Marcos Caceres wrote: On Monday, July 22, 2013 at 9:16 AM, JC Verdié wrote: Hi Daniel While widgets were (unfortunately) not widely adopted, a few companies (including mine) are using it and it does the job for many simple issues. It's true that the complexity of the spec vs the service provided was not really a good deal. As editor, I'm interested about the complexity aspect of widgets (aside from digital signatures, what other complexities have been faced?). Can you provide some more details about that? Obviously, we want to avoid similar issues with the packaged apps and hosted apps efforts. Obviously as you point out, digsig were a nightmare. May be it was us, but the spec was not really straightforward to implement and we found it difficult. On widgets itself, our main issue came from our own constraints (TV browser with no chrome ui), it lead to some inconsistencies to handle to overall UX. For instance, the impossibility to handle user events on a global level so that buttons used for exit or any immediate actions are not caught up by the widget, but by the "root" application. We hacked in several ways to achieve this but it was a disappointing point. I guess what I'm saying is we missed a wider view of how widgets are handled, run, die, and interact with the browser itself. Despite this, it's been very useful to us and we have deployed many solutions based on it, so anything that keeps compatibility with widgets is good to us Regards JC
Re: Web Widgets, Where Art Thou?
On Tue, 23 Jul 2013 13:44:56 +0200, Marcos Caceres 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
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,
Re: Web Widgets, Where Art Thou?
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".
> > > 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:
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"]
...
}
> > 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/
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.
> > > - 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.
Sure. Again, being biased, I don't think we had a single complaint from devs
about the format being XML while I was at Opera (we built an extremely robus
Re: Web Widgets, Where Art Thou?
On Mon, Jul 22, 2013 at 11:55 PM, Charles McCathie Nevile <
cha...@yandex-team.ru> wrote:
> On Mon, 22 Jul 2013 09:59:33 -0700, Daniel Buchner
> 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.
Re: Web Widgets, Where Art Thou?
On Mon, 22 Jul 2013 09:59:33 -0700, Daniel Buchner 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... [...] I'd like to step back and formulate a strategy based on the progression and growing prevalence of widgets on native mobile platforms, Presumably unsurprisingly, this was part of the approach that led to the current family of Widget specs. as well as how we can align widgets with the packaging and distribution of web apps. Yes, this is important. The paradigm of declaring/packaging widgets inside app packages is a beneficial pairing that reduces the amount of code and management developers are forced to think about, Yes... 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? 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. 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"? - Widgets remain a feature used primarily by savvy users, but new presentations will blur the lines between what a widget is - let's get ahead of this! The last point here is important for the next generation of 'widgets'. Widgets in the "statically-present-on-a-home-screen" incarnation are currently the most recognizable form, but this is changing. Look at Google Now - those cards, they're just widgets IMO. Yes, and likewise Yandex Islands - and yandex Widgets. And Opera's "Speed Dial Extensions". In the early days of widgets there also a lot of things like Yandex widgets - ways to collect bits of web content onto a page that was put together server-side. That paradigm hasn't disappeared, although I think it is fair to say that widgets arenow more familiar to users as stand-alone apps. Conclusions: - If users no longer distinguish between apps and widgets in practice, a common packaging vehicle makes sense. Yes. - We are seeing proactive, contextual presentation of data in widget-esque forms on Android and iOS (Moto X looks like it will introduce more of this). Under the proposed direction of widgets, developers need only know what context their widget is being evoked in, and how best to layout a UI for the intended display. (media queries for something like "blocks" - just an example, you get the idea) - 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 we want to make a splash, actively encourage implementers to add features based on widgets or widgets + apps (this is a feature we've discussed for future enhancement of the Firefox desktop experience) This sounds a bit like partying like it is 2009. I'm sure with a marketing budget people can make a splash of that, but it seems more like catching up to me. Which means we should do it primarily to promote interoperability with the systems that are several years in f
Re: Web Widgets, Where Art Thou?
Hi Daniel, On Monday, 22 July 2013 at 17:59, Daniel Buchner wrote: > In my opinion, the current spec's complexity in relation to its feature goal, > is high. I'm not sure what this means, to be honest. The engines that have used widgets always managed to do it without significant problems and seem to be fit for purpose (in the way's they use the capabilities afforded by the format) - I'm of course, extremely bias as I wrote the things and was directly involved with many projects using widgets. Regardless, for example, Opera's Extension platform successfully used widgets and related technologies without significant problems (it was then abandoned in the switch to Blink, as Opera is now able to cleverly leverage Chrome's extension platform). Also, WAC's runtimes made use of widget's element to enable APIs without any problems, AFAIK (see http://specs.wacapps.net/). > This doesn't mean it was a bad spec or deficient, it could be due to a number > of factors: different assumptions about what widgets should do, packaging > choices that existed before web apps gained steam, or a different focus on > where and how widgets would be displayed. In the case of WAC, I think it was just poor execution (compared to, say, FirefoxOS and the great developer drive behind it … again, I'm bias because I work for Moz also ^_^). Opera Extensions were quite successful as a platform and served Opera's users well, IM-Biased-O. Anyway, I could rant for hours about how different *product management* choices affect the uptake of widget technologies :) > I'd like to step back and formulate a strategy based on the progression and > growing prevalence of widgets on native mobile platforms, as well as how we > can align widgets with the packaging and distribution of web apps. This is basically what we are doing with: http://www.w3.org/2012/sysapps/manifest/ > The paradigm of declaring/packaging widgets inside app packages is a > beneficial pairing that reduces the amount of code and management developers > are forced to think about, while taking advantage of natural synergies that > result from reusing a common base. 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. Declaration via the app manifest is a huge piece - I'd > argue that this alone would realize a huge increase in developer utilization. Historically, this has not been the case however. Web apps are significantly different beasts to the experience provided by a packaged application: packaged apps offer a more tradition software experience, while web apps generally work better as services (… someone should try to do a PhD about this… oh, wait! that poor fool was me :) ). > Let's look at current consumer perception of widgets, and how the space is > evolving: > Widgets are commonplace on mobile platforms true. > In the view of consumers, search, discovery, and purchase/installation of > widgets is now distinguishable from apps true (in some stores). > Widgets remain a feature used primarily by savvy users, but new presentations > will blur the lines between what a widget is - let's get ahead of this! Sure: this was the intention of the view mode media feature. > The last point here is important for the next generation of 'widgets'. > Widgets in the "statically-present-on-a-home-screen" incarnation are > currently the most recognizable form, but this is changing. Look at Google > Now - those cards, they're just widgets IMO. Sure, or they could just be iframes. Point is, there is more than one way to skin this cat: the use case is more important than what technology is used to address the use case. > Conclusions: > If users no longer distinguish between apps and widgets in practice, a common > packaging vehicle makes sense. I believe we have this covered by the suite of specifications already available. For those that want packaged web apps "today", they can use: "Packaged Web Apps (Widgets) - Packaging and XML Configuration" - http://www.w3.org/TR/widgets/ For those that want to "install" web pages (or have an allergic reaction to XML), the Web Manifest format is under development: http://www.w3.org/2012/sysapps/manifest/ And for those that have an allergy to XML, but want things in a zip file - the SysApps runtime and security model spec has that covered: http://runtime.sysapps.org/ > We are seeing proactive, contextual presentation of data in widget-esque > forms on Android and iOS (Moto X looks like it will introduce more of this). > Under the proposed direction of widgets, developers need only know what > context their widget is being evoked in, and how best to layout a UI for the > intended display. (media queries for something like "blocks" - just an > example, you get the idea) > I believe we should retool efforts in this area to focus on sharing the app > packaging vehicle and reducing c
Re: Web Widgets, Where Art Thou?
In my opinion, the current spec's complexity in relation to its feature goal, is high. This doesn't mean it was a bad spec or deficient, it could be due to a number of factors: different assumptions about what widgets should do, packaging choices that existed before web apps gained steam, or a different focus on where and how widgets would be displayed. I'd like to step back and formulate a strategy based on the progression and growing prevalence of widgets on native mobile platforms, as well as how we can align widgets with the packaging and distribution of web apps. The paradigm of declaring/packaging widgets inside app packages is a beneficial pairing that reduces the amount of code and management developers are forced to think about, while taking advantage of natural synergies that result from reusing a common base. 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. Declaration via the app manifest is a huge piece - I'd argue that this alone would realize a huge increase in developer utilization. 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 - Widgets remain a feature used primarily by savvy users, but new presentations will blur the lines between what a widget is - let's get ahead of this! The last point here is important for the next generation of 'widgets'. Widgets in the "statically-present-on-a-home-screen" incarnation are currently the most recognizable form, but this is changing. Look at Google Now - those cards, they're just widgets IMO. Conclusions: - If users no longer distinguish between apps and widgets in practice, a common packaging vehicle makes sense. - We are seeing proactive, contextual presentation of data in widget-esque forms on Android and iOS (Moto X looks like it will introduce more of this). Under the proposed direction of widgets, developers need only know what context their widget is being evoked in, and how best to layout a UI for the intended display. (media queries for something like "blocks" - just an example, you get the idea) - 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) - If we want to make a splash, actively encourage implementers to add features based on widgets or widgets + apps (this is a feature we've discussed for future enhancement of the Firefox desktop experience) I'd like to hear any additional feedback, and your thoughts on next steps.
Re: Web Widgets, Where Art Thou?
On Monday, July 22, 2013 at 9:16 AM, JC Verdié wrote: > Hi Daniel > > While widgets were (unfortunately) not widely adopted, a few companies > (including mine) are using it and it does the job for many simple > issues. It's true that the complexity of the spec vs the service > provided was not really a good deal. As editor, I'm interested about the complexity aspect of widgets (aside from digital signatures, what other complexities have been faced?). Can you provide some more details about that? Obviously, we want to avoid similar issues with the packaged apps and hosted apps efforts. >
Re: Web Widgets, Where Art Thou?
Hi Daniel While widgets were (unfortunately) not widely adopted, a few companies (including mine) are using it and it does the job for many simple issues. It's true that the complexity of the spec vs the service provided was not really a good deal. However, what you describe makes sense. I know there are other members who have been pushing a lot in the past to keep widgets alive. May be they'll also pop in. Regards JC Daniel Buchner wrote: As some of you are aware, a widget spec or two (http://www.w3.org/TR/2012/PR-widgets-apis-20120522/) have been floating around for a while. These were never widely adopted for various reasons - not the least of which was their complexity. Well, hold on to your shorts folks: I would like to rekindle the idea of web widgets, but with an eye toward simplicity that builds on open web app concepts and mechanism. My proposal is simple: Widgets are just an alternate (or even the same) app 'launch_path' a developer would declared under a 'widget' key in their existing App Manifest. The UA would launch this URL in whatever widget UI containers it creates, for example: squares on a New Tab, a floating panel, etc., and add a few things to the document context - namely: an imperative means for detecting the document is being displayed in a widget state, and a new media query type 'widget' for styling (especially helpful if the developers chooses to use a single origin for their app and widget) What this allows for: - Let's us utilize the existing declaration and installation mechanisms for web apps (which is the same place widgets are already declared in today's common native app packages) - Provides a great new variant of content for all UAs who already are implementing apps - Delivers huge user benefit at a relatively low cost "Stupid-Simple Web Widgets: great idea, or greatest idea?...I'm gonna put you down for great." - /PS - If the word 'widget' makes you feel dirty and sad-faced (which it shouldn't, as Android proved and iOS concurred), let's just imagine we're talking about the W3 Web Dingus spec for now and focus on the user value proposition ;) /
Re: Web Widgets, Where Art Thou?
I always found Widgets (in the MacOS X Dashboard way) as a sort of self-contained web apps... :-) 2013/7/19 Daniel Buchner : > > As some of you are aware, a widget spec or two > (http://www.w3.org/TR/2012/PR-widgets-apis-20120522/) have been floating > around for a while. These were never widely adopted for various reasons - > not the least of which was their complexity. > > Well, hold on to your shorts folks: I would like to rekindle the idea of web > widgets, but with an eye toward simplicity that builds on open web app > concepts and mechanism. > > My proposal is simple: > > Widgets are just an alternate (or even the same) app 'launch_path' a > developer would declared under a 'widget' key in their existing App > Manifest. The UA would launch this URL in whatever widget UI containers it > creates, for example: squares on a New Tab, a floating panel, etc., and add > a few things to the document context - namely: an imperative means for > detecting the document is being displayed in a widget state, and a new media > query type 'widget' for styling (especially helpful if the developers > chooses to use a single origin for their app and widget) > > What this allows for: > > - Let's us utilize the existing declaration and installation mechanisms for > web apps (which is the same place widgets are already declared in today's > common native app packages) > > - Provides a great new variant of content for all UAs who already are > implementing apps > > - Delivers huge user benefit at a relatively low cost > > "Stupid-Simple Web Widgets: great idea, or greatest idea?...I'm gonna put > you down for great." > > - > > PS - If the word 'widget' makes you feel dirty and sad-faced (which it > shouldn't, as Android proved and iOS concurred), let's just imagine we're > talking about the W3 Web Dingus spec for now and focus on the user value > proposition ;) -- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
Web Widgets, Where Art Thou?
As some of you are aware, a widget spec or two ( http://www.w3.org/TR/2012/PR-widgets-apis-20120522/) have been floating around for a while. These were never widely adopted for various reasons - not the least of which was their complexity. Well, hold on to your shorts folks: I would like to rekindle the idea of web widgets, but with an eye toward simplicity that builds on open web app concepts and mechanism. My proposal is simple: Widgets are just an alternate (or even the same) app 'launch_path' a developer would declared under a 'widget' key in their existing App Manifest. The UA would launch this URL in whatever widget UI containers it creates, for example: squares on a New Tab, a floating panel, etc., and add a few things to the document context - namely: an imperative means for detecting the document is being displayed in a widget state, and a new media query type 'widget' for styling (especially helpful if the developers chooses to use a single origin for their app and widget) What this allows for: - Let's us utilize the existing declaration and installation mechanisms for web apps (which is the same place widgets are already declared in today's common native app packages) - Provides a great new variant of content for all UAs who already are implementing apps - Delivers huge user benefit at a relatively low cost "Stupid-Simple Web Widgets: great idea, or greatest idea?...I'm gonna put you down for great." - *PS - If the word 'widget' makes you feel dirty and sad-faced (which it shouldn't, as Android proved and iOS concurred), let's just imagine we're talking about the W3 Web Dingus spec for now and focus on the user value proposition ;) *
