Re: questions on the April 11th draft

In this approach, I concerned that there'll be some UX penalty for user in
some cases.

If service page is responsible, it wouldn't be matter because they can
respond 404
or else in adequate time, but in some unfortunately cases ( e.g. network
trouble ),
server cannot respond to background request in meaning time (in worse case,
about 1 minutes will be required).

It'll be occurred some delayed response and inadequate UX for users.

I think I understand that there is a tradeoff which case is better or not.
But I guess
WebIntent is similar to bookmark functionality (It won't check availability
in
current implementation), unchecking in background will be worth to
consider.



2012/4/27 James Hawkins <jhawkins@chromium.org>

> In the UI for Chrome, we're planning to implement the following when the
> user clicks on a web service:
> 1. Load the service in the background (hidden context).
> 2.1 If 404 unregister the service and show appropriate UI in the picker
>   a. Grey out the button of said service.
>   b. Provide a tooltip explanation for why the service is unavailable and
> has been unregistered.
> 2.2 Else, hide the picker and show the service in the appropriate context.
>
> At 2.1 the user is still in the picker UI, able to pick another service
> (assuming one is available).
>
> If the 404 is transient, the user will eventually visit the page again
> (assuming that is their intent) and the service will be registered again.
>
> James
>
>
> On Wed, Apr 25, 2012 at 8:52 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
>
>> On "a way to refresh the registration", the approach you mention for
>> installable Webapps makes sense (browser will handle that automatically).
>> For general Web pages, I did not mean that the browser would automatically
>> check the status of a page upon an expires value being exceeded, only that
>> the browser could alert the user somehow (mark the Intent in a picker UI?)
>> and allow the user to manually check if the Intent is still valid. But now
>> that you mention it, I can also see value in a setting that authorizes the
>> browser to automatically revalidate registered intents on a periodic basis,
>> and remove dead ones. I personally would like that feature, as I really
>> don't want to do any more work than I have to as a user, because of Intents.
>>
>> I will watch for the related text on "no longer accessible" intents
>> pages, and comment.
>>
>> On the MUST vs SHOULD, I do think that "allow the user ..." provides the
>> desired flexibility for the implementation to determine when/how the user
>> is allowed to make a decision. I just would not want the SHOULD to imply
>> that user choice on whether intents are registered is optional.
>>
>> Thanks,
>> Bryan Sullivan
>>
>> -----Original Message-----
>> From: Greg Billock [mailto:gbillock@google.com]
>> Sent: Wednesday, April 25, 2012 5:11 PM
>> To: SULLIVAN, BRYAN L
>> Cc: Jean-Claude Dufourd; public-web-intents@w3.org
>> Subject: Re: questions on the April 11th draft
>>
>> On Sun, Apr 22, 2012 at 5:42 PM, SULLIVAN, BRYAN L <bs3131@att.com>
>> wrote:
>> > To address the removal of intents without the user having to browse
>> back to the site, I recommend that a couple of things be considered:
>> >
>> > 1) An expiration element that defines how long the intent will remain
>> registered. When it expires, the user could be informed somehow through the
>> UI, and potentially given a way to refresh the registration.
>>
>> That's a similar suggestion to one Hiroyuki Aizu made at the F2F
>> meeting -- an "expires" attribute of the intent tag.
>>
>> I'd like to avoid requiring the user agent to refresh any non-loaded
>> page on any interval -- I'm worried there are privacy implications
>> there. For installed app support in Chrome, the browser will take care
>> of this kind of refreshing behavior. Do you have a sense on how to
>> make this work well for web content at large?
>>
>> > 2) Recommendations on what the user agent should do if an intent
>> registration page is no longer accessible, e.g. inform the user that the
>> service may no longer be available, and offer the option to remove it.
>>
>> This make sense. Currently the spec leaves this up to the UA pretty
>> completely. I'll put this in my notes to add to a recommendations
>> section.
>>
>>
>> > These might go a long way to avoiding the cluttering of old intents in
>> the browser UI, as the user surfs around the net and these things collect
>> like barnacles (one of my hesitations with the overall registration
>> design). At least I would be more comfortable with a MUST requirement on
>> "When the User Agent loads a page with registration markup, it should allow
>> the user to configure that page as a web intents service." Rather than a
>> SHOULD.
>>
>> My hesitation there is more around wanting to provide good leeway to
>> the UA to make tradeoffs between permissions notifications and
>> interruptions. That is, a perfectly valid usability decision might be
>> "we'll suppress notification on the first and second visits, but on
>> the third, we'll consider the user sufficiently interested in the site
>> to show the registration notification." Such policies might have
>> better ergonomics than a MUST requirement. Or do you think "allow the
>> user ..." provides the desired flexibility?
>>
>> > Thanks,
>> > Bryan Sullivan
>> >
>> > -----Original Message-----
>> > From: Greg Billock [mailto:gbillock@google.com]
>> > Sent: Friday, April 20, 2012 11:18 AM
>> > To: Jean-Claude Dufourd
>> > Cc: public-web-intents@w3.org
>> > Subject: Re: questions on the April 11th draft
>> >
>> > On Fri, Apr 20, 2012 at 12:08 AM, Jean-Claude Dufourd
>> > <jean-claude.dufourd@telecom-paristech.fr> wrote:
>> >> Thanks for your answers. More questions inline.
>> >>
>> >>
>> >> On 19avr. 21:05, Greg Billock wrote:
>> >>>
>> >>> To unregister, I can put on  http://example.com/a.html the markup:
>> >>>
>> >>> <intent href="http://example.com/b.html"></intent>
>> >>>
>> >>> which basically says "this service handles no intents." Since it is
>> >>> same-origin, it should be honored.
>> >>
>> >> JCD: If you just change a.html this way, when is the intent
>> unregistered ?
>> >
>> > When the user visits a.html.
>> >
>> >> Are you doing another action with that change to get a.html to be
>> processed
>> >> by the browser ?
>> >
>> > No. A goal is for registration and deregistration to be driven by
>> > things the browser discovers in normal operation. This obviously needs
>> > to be precise, but a sketch of the algorithm I have in mind is this:
>> >
>> > When the user visits a page with an <intent> tag on it (which is
>> > same-origin, cross-origin tags are ignored), the UA is provoked to
>> > check its registry and possibly make adjustments:
>> >
>> > If the tag registers a new handler, or an unknown filter for a known
>> > handler, the UA can prompt the user for registration confirmation.
>> > If the tag unregisters a known handler (omitting the filter), then it
>> > is unregistered.
>> >
>> > (The filter is the action/type attributes.)
>> >
>> > In addition, if the UA loads a known intent service page, it'll make
>> > sure the registration records are updated to match the authoritative
>> > declarations on that page.
>> >
>> > This algorithm means the UA only does something when it actually is
>> > triggered by parsing a tag (or possibly by handling a call from the
>> > imperative mechanism, which seems likely to happen). Pages that don't
>> > have any intents API on them don't trigger anything.
>> >
>> > Note that this is all a bit different from extensions/apps that handle
>> > intents, which can potentially have their registration settings be
>> > updated using other mechanisms.
>> >
>> >> Or is a.html sitting there with the intent still registered in the
>> browser
>> >> until the next time someone invokes it,
>> >> so a.html is loaded, the browser sees the unregistering, and has to go
>> back
>> >> up into intent resolution ?
>> >> This assumes that the registration markup page is the same as the
>> service
>> >> page.
>> >> If so, I am not sure I like it.
>> >
>> > There is a hole here -- if a service provider stops offering a service
>> > on a page, the browser may still dispatch to that page, since it
>> > doesn't know the support has been removed. I agree that this is not
>> > nice, but neither is any 404. Ideally the page redirects to the new
>> > service page on the provider. There are definitely edge cases here
>> > that result in the user having to go back to the picker and deal with
>> > their chosen service provider having ceased operations, though.
>> >
>> >> If the registration markup page and the service page are different,
>> then I
>> >> have no idea when the intent will ever be unregistered.
>> >>
>> >> Note: please add an example with separate registration markup page and
>> >> service page. Thanks.
>> >>
>> >>>
>> >>> Let me note quickly that this is the registration interaction with the
>> >>> browser, which is a little tricky. For instance, if a captive portal
>> >>> returns unrelated HTML to a request for a service page, should the
>> >>> browser be forced to unregister it? Hopefully not.
>> >>
>> >> JCD: Actually, there are two variants of your question:
>> >>
>> >> - if a registration markup page is loaded "again" and this time there
>> is no
>> >> intent registration in there, yes, probably, no change to the intent
>> >> registration DB.
>> >>
>> >> - if a service page is loaded and it does not contain any intent
>> processing
>> >> code, what happens ?
>> >> -- definitely, the intent will get no response (if one was in order)
>> >> -- should there be an error message ? I think yes.
>> >> -- should the intent be removed from the intent registration DB ? I
>> would
>> >> argue it should, yes.
>> >>
>> >> However, I do not know if the browser can throw an error, because its
>> task
>> >> is to just load the service page. If nothing happens, what is there to
>> alert
>> >> the browser that something is wrong...
>> >
>> > If there's no matching intent declaration on the page, the intent
>> > won't even be delivered. But in that case, the UA can fall back either
>> > to select another service, or notify the caller via postFailure that
>> > the intent could not be delivered.
>> >
>> >
>> >>
>> >>>  But the interaction
>> >>> of the tag and intent delivery is of a MUST nature -- the UA won't
>> >>> deliver an intent to a page that doesn't expect it.
>> >>
>> >> JCD: That means intents are going to be HARD to debug. If the service
>> page
>> >> is clobbered, silent failure ? I do not like it...
>> >
>> > >From the client's perspective, the failure isn't silent, and can be
>> > handled pretty readily. From the integration perspective, the failure
>> > mode is somewhat like finding 404 links on your site -- if you're
>> > suggesting obsolete services to users, you have to discover that and
>> > suggest new ones. If you're not, it is the UA's problem. So it is an
>> > easier debugging problem than having a third-party app changing their
>> > API on you.
>> >
>> > Am I misunderstanding which debugging process you're thinking of?
>> > Clearly there's possible bugs in the caller which could lead to
>> > persistent delivery failures.
>> >
>> >>
>> >>
>> >>>
>> >>> At some point, this'll get tuned into an algorithm spec for dealing
>> >>> with the<intent>  tag. I'm holding off on that a bit because it's
>> >>> likely to grow a little more complicated as we consider
>> >>> registerProtocolHandler/registerContentHandler issues with
>> >>> registration. (See the WhatWG list.)
>> >>
>> >> JCD: Are you saying a significant part of the web intents discussion
>> happens
>> >> on the WhatWG list ?
>> >> Or just talk that has impact on Web Intents ?
>> >
>> > The <intent> tag is in HTML, and so is discussed there, yes. That's
>> > the mechanism we've proposed for registration issues, so issues
>> > pertaining to that whole (important) question are in active debate
>> > there.
>> >
>> > -Greg
>> >
>>
>>
>

Received on Thursday, 26 April 2012 17:13:26 UTC