Re: Bjartur's Actual Criticism (finally)

Bjartur wrote:
> User Agents should only follow the intents of users, not sites.

User Agents can only understand intents that they were programmed to
understand. While user agents are updating every 6 weeks, they aren't
shifting dramatically more than every 6 months.

The following intents are things that most UAs handle today:
View
Persist
Print

(technically, those should really be potentially a single intent, but gah)

Some UAs around 2001 learned "Subscribe" (for RSS and later ATOM), but
not all have it.
Some UAs don't even have Print (or Persist).

If someone is designing a web site and wants to offer some magical
thing which a UA doesn't have, we can't just freeze everything and
wait until all UAs implement it. It's nearly 2012, and we will still
have UAs without Print when January comes around. Ideally with
Intents, we can actually map window.print() to an Intent, and then UAs
which don't have native support for Printing could let users pick a
Web based Print partner provider. Now, if a UA doesn't have any native
support for Printing, it's unlikely that it would have a button in its
"UI" for printing (why have a button that does nothing?). Eventually,
as UAs
add support for Intents, a UA without support for native printing
could provide a Print button which in fact just triggers an Intent for
Print, and walks the user through selecting a Print partner and then
sends the selected page to that Intent partner. But that's a long way
off.

> Users, not sites, choose actions.

User Agents are always going to be limited. Eventually some UAs may
offer buttons for triggering a certain intent, or selecting an
arbitrary intent. But some Intents will be mostly too complicated for
a User to fill out using a simple "Intent + page". This is where [1]
§10 Manual Providers would come into play. If a User wants to trigger
a complicated intent and the UA doesn't know how to do it, the user
will need to have a §10 provider that they can load (probably via
Bookmarks or something like them) which will let them initiate the
intent they want to initiate. §10 Manual Providers are not something
we can require browsers to provide for all possible intents, since
there are an infinite number of them א‎₄[2] might be the correct size
fwiw, it's pretty large.

> The current proposal gives the responsibility of choosing an action to scripts,

The current "proposal" is not formally proposed. In terms of
deliverables, the webintents proposal that you're looking at covers
parts of the deliverables [3] for B, C, D and E. The proposal doesn't
preclude User Agents providing other ways to manage discovery [3] B,
nor does it preclude other ways for User Agents to trigger dispatch.
In terms of things which you want, I think that they're mostly covered
by Action Features [1] specifically §10. As long as those exist, you
should be relatively happy.

> but essentially requires that users select implementations of the action.

Well, if a user wants to do something, the user has to have some idea
of what the user wants to do. There's at least an א‎₁ level of
complexity there. Web pages can sometimes have moderately good ideas
of what users might want to do, and thus are not in a terrible place
to offer suggested actions. In fact, web pages have had <Print> and
<Download>(Persist) links or buttons since at least 1994. Links to RSS
appeared as soon as RSS became vaguely popular, and probably a year or
three before User Agents added their own.

Similarly, Audio/Video embedding has been present on the web since at
least 1995 [4]. Links to them in the form of <a href> or <embed> or
later <object> were also common. It would have sucked if we forced the
web to pause until 2010 when we started working on adding UA support
for <audio> and <video> as part of html 5 [5].

Certain intents are likely to become integrated and accelerated by
User Agents just as <back> and <forward> and <bookmark> and <print>
were early on (but not all of them were present initially). There were
browsers which didn't have Back and Forward (or at least the
multilevel back/forward we have today). Nexus [6] didn't have
Bookmarks, or "Forward" (it had Back -- "Back up" and next/previous,
but not forward * i'm told you might have been able to back up to the
page you from which you had just backed up,
which would be forward, but well, blah) [7]. Systems without access to
printers didn't have print (e.g., Maemo MicroB). Trivial embedded
browsers often don't have Back (yes, they're lame, but sometimes you
really don't need it, and sometimes web pages break it or provide
their own).

> The problem with this is twofold.
> Firstly users must have the power to pick actions.

As long as §10 is done by someone and there's a directory (this is
mentioned in the introduction "directory lookup/search" [8]), then
users will have the power to pick actions. This is not something that
we can demand from UAs. Competition will probably cause general UAs to
integrate searching for providers. If you feel it's missing in your
favorite UA, you can either contribute a patch, a bounty, or a bug.

> In practice, scripts should defer to users but are left without
> a standard way to do so.

??

The workflow described in [8] and [9] outline where the user is in
control and there would be standards by which the pages/scripts really
don't have any control beyond defering to the user for the action
they're presenting.

This should be satisfactory for your purposes.

For certain forms of abuse [10], the most one can do is kill scripts,
block access, provide dummies, or stop visiting the site.

That's the same as with any other feature. We can't do much better
(although UA UI should be able to improve for all of these, and to
some extent [11] they have).

> And annoyingly, scripts have the power to refuse to ask users.

This can't be avoided. Some browsers [12] and domains [13] have
provisions to help work around this. The same is likely to apply to
Intents.

> Either way, usability is harmed.

Usability isn't harmed significantly more than not having the feature.

> As for the representative example,
> I for one tend to read letters sites want me to spam representatives with,
> although this may correlate with my not having a representative.

Not having a representative does make that example harder to work
with. I presented it because I wanted to avoid using a technological
example initially. You can refer to the TV System [9] example instead
for a technological example which should be perhaps easier to digest.
The problem with any technology is that it may not be universally
deployed. I did intend to compose additional examples, and in fact, my
TV system example was posted before you managed to explain your
complaint :).

> Secondly, some actions are of such nature that many users have only one
> implementation to choose from.

I'm not sure this is actually true. There might be only one
implementation readily available, but generally nothing prevents
someone else from creating a competing implementation.

> What actions these are varies between users.
> Prompts for choice one of one implementation are equivalent
> to OK/Cancel prompts.

For general UAs, you'll have 3 choices in this case:
1. Use the discovered impl
2. Search for an impl
3. Choose an abort tactic
3a. Pretend to succeed
3b. Pretend to fail

If 2 results in a §10, then you are able to more effectively pretend
to succeed. If it doesn't, then depending on how annoying the intent
is, your attempt to pretend to succeed may be discovered. When this
happens, you can vote with your feet and stop using the site, or find
someone to implement §10. I'm hopeful there will be a "cottage
industry" for §7 Client Request Inspector, §8 Partner Inspector, and
§10.

UAs could even offer to post information about the intent to a
database (like WER or WineHQ's AppDB [14]), or similar to Bug Buddy
[15].

> I should not have to state how harmful overuse of them is.

Overuse of <blink> [16] died out. I think that even overuse of
<marquee> has died out.

People vote with their "feet" (or wallets) and so, such things are
self healing. Yes, early adopters are stuck being more active, but
they typically are more active and more vocal anyway.

> Sites should of course not even be able to request
> the user run fdisk C: or mkfs /dev/sda.

We can't prevent sites from asking users to do stupid things [17].
We can't even prevent people from making stupid Plugins. However, a
typical Web based intent is still a web page, it doesn't have access
to local storage.

We can't prevent your bank from having an XSS which allows someone to
trick your browser into instructing your bank to empty your account.
But this isn't our fault, it's your banks fault. When this happens,
sue your bank and replace it.

> The solution is obvious: let users choose actions
> (as sites could only be hoped to allow users to do)

Consider an action of "View". A site might expect that i'm going to
view it with a web browser on my local tablet. But if my tablet has
HDMI out, then my View action might end up going to a TV (or
projector). If my View provider actually includes the ability to
print, or even send the resulting print out to a mail address, that's
beyond what the site controls. This is already part of the design of
Intents.

> and optionally implementations.

Sorry, users choose implementations, what an implementation does is up
to the implementation, but the implementation can end up being a
totally different "action", it just happens to respond to the same
request.

> Registering an action is akin to bookmarking.

sure, more or less.

> Automatic and silent registration will be great.
> User interfaces should display actions and implementations
> actually, and by extension often, used more prominently than
> those never needed and offer blacklisting for users that can be
> bothered.

Yep, this is already envisioned [10].

> Whitelisting can of course be used in properly managed user
> agents. I expect user agents to be able to resolve this.

We all do.

[1] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0039.html
[2] http://en.wikipedia.org/wiki/Aleph_number
[3] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0010.html
[4] http://en.wikipedia.org/wiki/Real_Player
[5] http://en.wikipedia.org/wiki/HTML5_video
[6] http://en.wikipedia.org/wiki/WorldWideWeb
[7] http://www.w3.org/People/Berners-Lee/WorldWideWeb.html
[8] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0000.html
[9] http://lists.w3.org/Archives/Public/public-web-intents/2011Dec/0013.html
[10] http://lists.w3.org/Archives/Public/public-web-intents/2011Dec/0007.html
[11] http://noscript.net/
[12] http://www.opera.com/
[13] http://userscripts.org/
[14] http://appdb.winehq.org/
[15] http://directory.fsf.org/wiki/Bug-buddy
[16] http://www.goer.org/Journal/2003/10/html_house_of_horror_things_that_go_blink_in_the_n.html
[17] http://looktruenorth.com/culture/far-left-madness/11195-they-built-a-better-idiot.html

Received on Friday, 23 December 2011 01:12:34 UTC