Re: Web/Native: gap analysis

Le lundi 14 octobre 2013 à 20:25 +0100, Marcos Caceres a écrit :
> > The goal of taking the wide-picture approach is to make it more likely
> > that when we pick our priorities, we do so with a clearer view; both in
> > terms of what would have the most impact, but also ensuring that closing
> > the said gap won't also affect badly another piece where the Web is
> > leading.
> 
> 
> The question is: do we really not know what the priorities are of the
> stuff we need to fix? I think we all pretty much do, so let's just get
> on with it.  

It may be that you have a well-grounded picture of these priorities; my
experience with the "closing the gap" task force we went through last
spring is that we did lack a structure to evaluate which of the many
good ideas that were raised ought to be tackled in priority.

Let me illustrate this with your suggested list of priorities:

* ApplicationCache is being replaced by ServiceWorkers to provide a
(much needed) better approach to manage (among other things) offline Web
apps; yet, I've heard more often that the main issue developers face are
managing the quota available to them — ApplicationCache is a pain, but
that can be worked around in many times; limited storage space cannot be
worked around

* I believe that what you call "bookmarking" is extremely important, but
metadata is only a small piece of it; while we can't standardize UX,
there is probably room for exploring and describing what users need; I
(maybe naively) think that the post that Scott Jenson published on Web
Apps UX as a consequence of our work last spring on closing the gap was
instrumental in getting Chrome on Android to support "save to
homescreen" with integration in the task switcher

* clearly, permissions management is something we encounter very often
as a problem while defining our specs; yet, do you have a clear idea on
how many apps are actually affected by this? how important/urgent is it
to fix this to make the Web competitive? It certainly is problematic for
apps that need access to lots of sensitive features, but how big is
their share in the targets we're trying to facilitate?


In general, I think it's hard to figure out priorities without a
framework for thinking about them; the goal of my document was to
provide such a framework: among other things, it highlights the
constituencies we need to think about (users, service providers), and
the issues they're experiencing. In particular, no matter how great we
make the platform for service providers (incl. developers), if the end
user experience is so poor that users shun Web apps, we've not made
progress.

It still falls short of setting priorities; the third part of my
(perhaps too ambitious) framework was to look at apps categories to see
what issues affect them most; and to suggest maybe we start by "fixing"
apps that have been traditionally the stronghold of the Web (news, media
consumption, entreprise software) before tackling the ones that have
been less so (e.g. games) — I'm not sure this is necessarily the best
approach, but I feel that at least discussing and understanding our
strategy in this space is a critical part of having an impact.

> > I certainly agree that at any time, the IG should focus its efforts in
> > just a few of these items.
> 
> 
> My worry was that we would spend too long as a group fleshing out
> those documents instead of tackling the high priority stuff that is
> broken. 

You're right that there is a risk we spend too much time on fixing the
document rather than putting it in use to determine our priorities; and
I probably should have brought it as a starting point for discussing
priorities rather than as a report on its own (I guess it's difficult to
use it as a starting point until and unless read it, though).

> So, I think the framework/docs you have put together serve a really
> useful function in giving the overall picture (which other folks can
> take up and run with). But would like us to get moving on trying to
> fix stuff (and start by picking what we are going to fix first).   

Yes, I think defining our priorities should be the logical next step; I
guess I probably should keep working on the document on my own rather
than getting owned by the IG — and hopefully we can still use it as a
way to structure our prioritization discussions.

> > I probably wouldn't call it bookmarking, but I agree that deeper
> > integration of Web apps in the launcher real estate is critical as well.

> I use the term bookmarking deliberately, as talking about "installing"
> leads people to get the wrong idea (technically).

Yet you then qualified it as being about "installing" Web apps :)

I agree that "installing" probably is too connoted — I guess talking
about "launcher integration" might be closer to it?

> > Well, there is a permissioning model, but it's hard to scale and is
> > pretty leaky; I would love if we can indeed help in this field.
>
> That would be good… Do you have an alternative set of priorities (at least for 2 and 3)?  

As I've put it above, I don't have a clear set of priorities; I can
relay some topics that I've heard mentioned again and again by
developers:
* storage quota management
* Smooth scrolling / "performance"
* "Security" (a mixed bag of secure storage, protection against XSS and
SQLi, code obfuscation, …)
* payments
* push notifications

But again, I think selecting the right priorities depend on how we think
we can be most effective in pushing the Web back to the top of mobile
apps platforms; we shouldn't spend too much time defining that approach,
but if we spend too little doing it, we're likely to reduce our actual
impact.

Dom

Received on Tuesday, 15 October 2013 08:37:02 UTC