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?
