Re: Web/Native: gap analysis

On Tuesday, October 15, 2013 at 9:36 AM, Dominique Hazael-Massieux wrote:

> Le lundi 14 octobre 2013 à 20:25 +0100, Marcos Caceres a écrit :
> > 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.

Yes. That closing the gap discussions really helped cement my ideas around priorities - particularly as it allowed us to view the problem from multiple perspectives. It's the primary reason why I joined and I'm excited about this group.  
  
> 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


The fact that appcache is severely broken makes it a non-starter for developers targeting FxOS. From that perspective, developers can't even get to the question of quota management because their apps won't even work offline.  

FirefoxOS works around quota management by allowing developers to simply bypass all the hassle and request unlimited quota (through the manifest).

So yes, quota managements is severely broken too. It should probably take higher priority than permissions.      
  
> * I believe that what you call "bookmarking" is extremely important, but
> metadata is only a small piece of it;

Sure.   
> 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


Could be, but without the guys from Google outright acknowledging that, we won't know - they might also have simply copied what iOS does (as bookmarked apps also integrate into the task switcher). It seems pretty logical that if one puts an application on the home screen, it will need to behave as other applications do as to not confuse users. I think even old Opera Widgets integrated into the OS's task switcher - and maybe even the WAC runtimes might have supported this kind of thing. It's not a new thing - just hasn't been mainstream.  
  
> * 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?

This is a chicken and egg problem: SysApps APIs are all depending on this being sorted before they can be generally made available to the Web. As we don't have these APIs on the Web, we don't know how to solve the problem.    
> how important/urgent is it
> to fix this to make the Web competitive?

Well, without it, we risk adding another centralized DRM model to the Web: packaged web apps and signed web apps. Packaged Web Apps is happening, and it's pretty sad because developers need to ask a centralized authority to get access to privileged APIs.    
> 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?

It's not too big, I guess… because there is no easy way to secure access to the APIs without relying on a kind of DRM (digital signatures).   
> 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.


Right, but that's for the UX teams in browser vendor companies to figure out. We can hint at useful things, sure - but we risk limiting the potential of what a Web OS can be… task switchers, etc. might not be the only (or remotely the best way) to think about this problem.
  
> 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.

Agree. My sense of urgency comes from what developers are feeding back to Mozilla when trying to run their apps in our browser and in FxOS devices.  
  
> > > 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).


I agree that it's pretty important that people read it.  
  
> > 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.


That would be good. There are lots of people writing about this topic, which is why I also pushed for us to keep a "library" of related articles. We can then draw on a large body of knowledge to help us make informed decisions.  
  
> > > 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?

I see that as a UX thing. The application itself has no real knowledge of where it is hosted (or how it is hosted)…. all it needs to know is that it's being hosted (i.e., `window.standalone` is true or false).   
  
> > > 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.
>  

Agree. That's also a very good list.

Received on Tuesday, 15 October 2013 11:44:17 UTC