Re: [webintents] Should DAP revisit WebIntents?

Hey all,

I think I sent an email privately to a number of people that I think should
be shared here (I have edited it and clarified it a bit) - and note a lot
of this is my personal perspective and I know thoughts on this vary.

At a super high-level it was the UX that killed it especially on desktop
(and I believe at the time Chrome for Mobile wasn't "a thing"), we hit a
huge number of problems that the choice of API meant we couldn't solve it.

My internal take on this after the event was:

   - Android has a modal full screen (in most cases) stacking app context.
    Desktop web doesn't.  We had a huge issue with "what happens when you kill
   off the app that initiated the action" and given that we were pushing
   people to use "EDIT" intents where all the work is done in the app that
   fulfills the intent yet have the initiator save the data, if that closed
   the user was hosed.
   - We didn't specifically solve a single use case other than connecting
   apps.  We should have started with a simpler user X in twitter wants to
   attach a picture from their Google drive or Dropbox.  This would have
   certainly helped with presenting UI in many of the cases, but it also might
   have changed the API surface considerably too (we just didn't explore it).
   - We were overly broad in terms of intents: We started with a lot of
   custom ones that we thought were cool, and I tried to encourage developers
   to think of new ones.  The lesson I learnt from this is that we should have
   started with a very small pool with no ability for developers to deviate
   and lead them through to solving very specific use-cases with the API.  In
   the project we were far far to late in trying to constrain the platform and
   guide developers in a very opinionated way
   - There were two problems for developers.  Services needed clients and
   clients needed services.  Web Intents got pretty big when we solved one
   side of that problem by adding in the ability to "VIEW" RSS feeds in your
   preferred apps, it drove a huge number of installs and made it simple to
   demonstrate that the concept has value to other RSS readers who wanted to
   be in the game.  The problem we faced is that RSS is sacrosanct to the
   community and we came in and disrupted it and this community was vocal
   against this move (I believe it was one of the highest started bugs in the
   shortest amount of time on crbug.com) - we also didn't provide a
   fallback which was a major mistake we made (it turns out people like
   reading raw xml).
   - In retrospect, I also think we were overly stubborn in our
   interactions with Mozilla up until we decided that they had some good
   points (but by that time it was too late).  We were also working with a
   some of the wrong people in Moz to start with which delayed things imo, but
   that is not that important now.

I have a lot of thoughts about how a "new" project should run and I am
worried about talk of MessagePorts (they add huge complexity for developers
at a time when they don't need it, or it is not clear) without specific
use-cases.  I also see the same thing happening in "WebWishes" which is
(was... I have not checked it out in a while) looking at things in a
desktop only way and at just an API level.  I would love us to document all
the types of actions we know users are struggling with (for example, I know
a lot of people just want to view files in their preferred web app for data
that is held locally to them and registerContentHandler right now requires
a server won't work offline at the moment) and then go from there.

Right now I see: Single shot (a calls b with no data return), Returnable (a
calls b, with data being returned), Long-running Chatty (MessagePorts etc).
 I strongly suspect the API surface and the Usecases for each of these is
different, but I think even this is too far in to trying to solve the
problem.

I would like to see:

   - A list of use-cases that we need to solve to help users
   - A constrained list of actions that we think are critical (based off
   use cases) to help developers solve the problem
   - Thought on where these could fit into the existing platform (i.e, the
   pick intent we had, why was that not just part of input type="file"....)
   - I would like us to separate out discovery of services a site can offer
   (i.e, manifest or intent tag etc)
   - I would like us to separate out service resolution and selection

p.s, I am happy to get back on this and help out as much as possible, but I
would also need to get broader support from the Chrome team again on this.

P


On Thu, Jun 26, 2014 at 5:12 PM, Wayne Carr <wayne.carr@linux.intel.com>
wrote:

>
> On 2014-06-24 08:58, Robin Berjon wrote:
>
>> Hi,
>>
>> On 24/06/2014 16:24 , frederick.hirsch@nokia.com wrote:
>>
>>> Is there any new work or progress in this area, with Chrome, or other
>>> implementations?  Robin, are ‘web wishes’ related and relevant [3]?
>>> Should DAP be looking at them more closely?
>>> [3] http://darobin.github.io/web-wish/
>>>
>>
>> Web Wishes are indeed meant to be a revival of Web Intents (the name
>> being picked to be deliberately different from Intents and Activities).
>> I've been caught up in the contentEditable stuff, but I've been planning to
>> add the normative content now that the uses have been outlined.
>>
>
> Web Intents seemed to have run into trouble with dealing with what happens
> in another tab that is providing the service (like recursive web intents
> request from the providing service).
>
> A different use case that perhaps would be better to split out is services
> from native apps, not other Web apps.  An issue with Web Apps competing
> with native is it takes a long time to provide web apps with APIs needed to
> use new hardware.  So there can be a long lag where only native apps can
> use new hardware capabilities (or sometimes JavaScript is just too slow).
> Example: video face, gesture or object recognition.
>
> Web Wishes with a return value to native services would be good for some
> use cases.  More generally, a message channel provided by the UA to native
> apps would allow for the creation of native app provided services that
> cooperate with web apps.
>
>
>
>> The really, really important step however is for issues to be properly
>> listed. There have been many mentions of problems with implementability and
>> UI, but none have been documented. If they are documented, then we can't
>> make progress (and I believe they can be solved).
>>
>> Last this came up (a few weeks ago) I think that Paul Kinlan sort of more
>> or less accepted to help there. Paul, is that an option or am I cramming
>> words into your mouth? (Actually, I don't care *that* much that I am if the
>> result is that you list the issues you know about ;) I promise beer in
>> exchange.
>>
>>
>
>


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
Subscribe to my developer newsletter: https://tinyletter.com/PaulKinlan
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan <http://twitter.com/paul_kinlan>
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me