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: Polished FileSystem API proposal
>> Hell yes!!! +1000 to add an interface to inotify :-D > I'm concerned that you're taking this API too far. What's next - > mmaping a file to a byte array? It would be cool... :-P Ok, let's get serious. Maybe inotify would be too high level API and I agree it would be moved to a later version, but I find it a really useful feature. in a per-domain sandboxed filesystem maybe it would not be so important (except if it's accessed from several pages on the same domain), but if it's a sandboxed mountpoint defined by the user on a folder on the computer filesystem and he has direct access to it, if he modify the contect of this sandboxed folder/mountpoint the webapp wouldn't know about that modifications, and for my personal use case I'm really interested on this feature (in fact, I proposed it some time ago, not remember if on this list or on Chrome...). -- "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
