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