Misc clarification Q's on the introducer stack
Will Meyer
Aside from the more conceptual discussion on typing and decoration, I
had a couple of specific questions on the introducer specs[1,2] to
hopefully finish my understanding of current state (so we can talk
more about the future). Hopefully the last of the dumb questions.
Registration and provider metadata
- Is a provider's "name" attribute intended to be a verb that should
be presented to a user? For example, google translate's provider for
accepting content to translate, would its name be "Google", "Google
Translate", "Translate with Google", "Translate with %s"? I do see
how its used in the current impl. Further, how are multiple localized
strings provided, given that this is before provider invocation time
and therefore not dynamic at the time of the introduction?
- The ability to provide multiple graphical resources, not just 16x16,
I think is important. Data is clear that the small icons (whether
favicons or more specifically targeted to the operation) perform worse
than larger and often more stylized visuals.
- I'm not sure why a provider doesn't have an icon instead of a
registration (or as an override) -- isn't that the thing thats
actually presented as a discrete option to the user?
- Registrations are one per origin. There's a case, Google's probably
the best example, where the same origin (assuming scheme host port
triple) provides multiple discrete products (google.com/buzz,
google.com/bookmark). Given that the registration mechanism is
javascript based, does this require that the page code of each product
has to be aware of the logic of maintaining provider registrations for
other, potentially completely unrelated services? This is especially
cumbersome if implementing things, as you suggest in the spec, like
removing registrations on logout. Have you considered other options
here?
- Is there an ability to unregister, as opposed to merely updating a
registration with zero providers? I'm assuming both/either would not
involve any ux at all, per the spec.
Introductions and Communications
- From a provider's perspective, if I provide both window and frame,
then the spec states that both will be opened, and that I'll only
welcome one of them, for which I'd have to somehow communicate to
really know. Is that right or is some nuance there? I'm wondering if
its possible to just leave it at a precedence order.
- There's a mention of two factor auth, in which a provider could
prompt for auth in its "window". Assuming 3rd party cookies are the
reason not to use the frame, have you already discussed other ideas
around this? I'm wondering if the practical detail means that if you
are a provider who prefers frames, then you have to update your
providers to prefer windows on logout. This ties somehow to the frame
and window in parallel question above.
- Are there prohibitions on Providers requesting introductions to
other providers?
W
Tyler Close
> Mostly for Tyler ;-),
>
> Aside from the more conceptual discussion on typing and decoration, I
> had a couple of specific questions on the introducer specs[1,2] to
> hopefully finish my understanding of current state (so we can talk
> more about the future). Hopefully the last of the dumb questions.
>
> Registration and provider metadata
>
> - Is a provider's "name" attribute intended to be a verb that should
> be presented to a user?
Yes.
> For example, google translate's provider for
> accepting content to translate, would its name be "Google", "Google
> Translate", "Translate with Google", "Translate with %s"? I do see
> how its used in the current impl.
The current implementation is representative of what all Introducer
implementations should do. Each option in a Provider selection menu
starts with the icon or name from the Registration and is followed by
the name of the Provider. So registration of Google Translate might
look like:
window.introducer.register({
icon: 'data:image/png;base64,iVBOR...',
name: 'Google',
providers: [ {
id: 'translate',
name: 'Translate',
supports: [ 'http://web-send.org/bookmark/' ],
frame: 'http://www.google.com/translate/'
} ]
}, function () {
});
Consequently, it would show up in a Provider selection menu as the
Google icon followed by 'Translate'.
> Further, how are multiple localized
> strings provided, given that this is before provider invocation time
> and therefore not dynamic at the time of the introduction?
The page that invokes register() determines the user's locale and sets
the names accordingly.
> - The ability to provide multiple graphical resources, not just 16x16,
> I think is important. Data is clear that the small icons (whether
> favicons or more specifically targeted to the operation) perform worse
> than larger and often more stylized visuals.
Adding an icon member to the Provider
<http://web-send.org/introducer/#api.Provider> object is feasible. So
each option in the Provider selection menu starts with the
Registration icon and then is followed by the Provider icon.
Out of curiosity, do you know of any data that suggests the larger
icon performs better than descriptive text localized to the user?
> - I'm not sure why a provider doesn't have an icon instead of a
> registration (or as an override) -- isn't that the thing thats
> actually presented as a discrete option to the user?
Both get presented. The Registration icon tells the user which site
the Provider is from.
> - Registrations are one per origin. There's a case, Google's probably
> the best example, where the same origin (assuming scheme host port
> triple) provides multiple discrete products (google.com/buzz,
> google.com/bookmark). Given that the registration mechanism is
> javascript based, does this require that the page code of each product
> has to be aware of the logic of maintaining provider registrations for
> other, potentially completely unrelated services? This is especially
> cumbersome if implementing things, as you suggest in the spec, like
> removing registrations on logout. Have you considered other options
> here?
Yes, it is a little cumbersome and yes I've been through multiple
alternate designs.
Under the current design, one easy solution is for the registrant to
keep its own copy of the registration in localStorage and update it in
tandem with the register() invocation. So pages from different parts
of the same origin coordinate their registration client-side.
> - Is there an ability to unregister, as opposed to merely updating a
> registration with zero providers? I'm assuming both/either would not
> involve any ux at all, per the spec.
Yes, call introducer.register().
If no Registration is specified, any current registration is deleted. See::
http://web-send.org/introducer/#update
> Introductions and Communications
>
> - From a provider's perspective, if I provide both window and frame,
> then the spec states that both will be opened, and that I'll only
> welcome one of them, for which I'd have to somehow communicate to
> really know. Is that right or is some nuance there? I'm wondering if
> its possible to just leave it at a precedence order.
Both the frame and the window are configured by the same Provider, so
it presumably has some convention that it follows for which of the two
pages will be handling requests from the Customer.
> - There's a mention of two factor auth, in which a provider could
> prompt for auth in its "window". Assuming 3rd party cookies are the
> reason not to use the frame,
Phishing is the reason to not use the frame.
> have you already discussed other ideas
> around this? I'm wondering if the practical detail means that if you
> are a provider who prefers frames, then you have to update your
> providers to prefer windows on logout. This ties somehow to the frame
> and window in parallel question above.
Switching from frame to window on logout seems like a fine design.
> - Are there prohibitions on Providers requesting introductions to
> other providers?
No.
Thanks for the questions. I'll try to update the docs to be clearer on
these points.
--Tyler
--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Will Meyer
Got it, would be helpful to clarify in spec that this can and will be
used as the call to action.
> Consequently, it would show up in a Provider selection menu as the
> Google icon followed by 'Translate'.
>
>> Further, how are multiple localized
>> strings provided, given that this is before provider invocation time
>> and therefore not dynamic at the time of the introduction?
>
> The page that invokes register() determines the user's locale and sets
> the names accordingly.
So if I switch locales, I have to visit a registrant to let it update
its registration with the new data, and until then I'll see the wrong
locale version? Don't see a way to avoid that cleanly.
Related, what is the expectation on registrants in terms of how
frequently and when they should register? Is the intent that they
will do it on every visit? Will the UA stop asking the user for
approval once they've denied it once? Will the registrant keep
getting callbacks as it makes updates even with no changes?
>
>> - The ability to provide multiple graphical resources, not just 16x16,
>> I think is important. Data is clear that the small icons (whether
>> favicons or more specifically targeted to the operation) perform worse
>> than larger and often more stylized visuals.
>
> Adding an icon member to the Provider
> <http://web-send.org/introducer/#api.Provider> object is feasible. So
> each option in the Provider selection menu starts with the
> Registration icon and then is followed by the Provider icon.
Yeah I think the icon-per-provider case is much more prevalent, in
situations where there are multiple providers. Per your comment
below, if there is an con for the provider, I'm not sure what value
having an icon for the origin adds. If I can register a malicious
provider that has the icon of some other service, i can just as easily
add that same icon to my registration.
>
> Out of curiosity, do you know of any data that suggests the larger
> icon performs better than descriptive text localized to the user?
I don't know how this maps to what HCI folks would say based on years
of study, but we've seen patterns consistently in practice for this
use particular case in pages. Big pretty icons (32x32) are 2x over
smaller (16x16), which are themselves about double triggered menus.
>
>> - I'm not sure why a provider doesn't have an icon instead of a
>> registration (or as an override) -- isn't that the thing thats
>> actually presented as a discrete option to the user?
>
> Both get presented. The Registration icon tells the user which site
> the Provider is from.
>
>> - Registrations are one per origin. There's a case, Google's probably
>> the best example, where the same origin (assuming scheme host port
>> triple) provides multiple discrete products (google.com/buzz,
>> google.com/bookmark). Given that the registration mechanism is
>> javascript based, does this require that the page code of each product
>> has to be aware of the logic of maintaining provider registrations for
>> other, potentially completely unrelated services? This is especially
>> cumbersome if implementing things, as you suggest in the spec, like
>> removing registrations on logout. Have you considered other options
>> here?
>
> Yes, it is a little cumbersome and yes I've been through multiple
> alternate designs.
>
> Under the current design, one easy solution is for the registrant to
> keep its own copy of the registration in localStorage and update it in
> tandem with the register() invocation. So pages from different parts
> of the same origin coordinate their registration client-side.
Interesting... What was the reason not to offer a registration
interrogation, allowed for the same origin, which would be used much
the same way by a registrant in practice, but supported by the
introducer directly?
>
>> - Is there an ability to unregister, as opposed to merely updating a
>> registration with zero providers? I'm assuming both/either would not
>> involve any ux at all, per the spec.
>
> Yes, call introducer.register().
>
> If no Registration is specified, any current registration is deleted. See::
>
> http://web-send.org/introducer/#update
>
got it
>> Introductions and Communications
>>
>> - From a provider's perspective, if I provide both window and frame,
>> then the spec states that both will be opened, and that I'll only
>> welcome one of them, for which I'd have to somehow communicate to
>> really know. Is that right or is some nuance there? I'm wondering if
>> its possible to just leave it at a precedence order.
>
> Both the frame and the window are configured by the same Provider, so
> it presumably has some convention that it follows for which of the two
> pages will be handling requests from the Customer.
You're saying the case of it opening both is really just a last resort
from the introducer side and that it shouldn't happen in practice
because a provider wouldn't provide both?
>
>> - There's a mention of two factor auth, in which a provider could
>> prompt for auth in its "window". Assuming 3rd party cookies are the
>> reason not to use the frame,
>
> Phishing is the reason to not use the frame.
>
>> have you already discussed other ideas
>> around this? I'm wondering if the practical detail means that if you
>> are a provider who prefers frames, then you have to update your
>> providers to prefer windows on logout. This ties somehow to the frame
>> and window in parallel question above.
>
> Switching from frame to window on logout seems like a fine design.
I think this goes to the other comment of it being a good idea to doc
the practical requirements on provider implementors so you can then
look at the cases that need to be handled to achieve compatibility and
support the common use cases, and try to make it as simple as possible
to plug in.
>
>> - Are there prohibitions on Providers requesting introductions to
>> other providers?
>
> No.
>
> Thanks for the questions. I'll try to update the docs to be clearer on
> these points.
Wicked
>
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>
> --
> You are subscribed to the OExchange list, archived at http://groups.google.com/group/oexchange.
> To post to the list, send email to oexc...@googlegroups.com
> To unsubscribe from the list, send email to
> oexchange+...@googlegroups.com
>
Tyler Close
Good idea:
http://web-send.org/bookmark/#call-to-action
>> Consequently, it would show up in a Provider selection menu as the
>> Google icon followed by 'Translate'.
>>
>>> Further, how are multiple localized
>>> strings provided, given that this is before provider invocation time
>>> and therefore not dynamic at the time of the introduction?
>>
>> The page that invokes register() determines the user's locale and sets
>> the names accordingly.
>
> So if I switch locales, I have to visit a registrant to let it update
> its registration with the new data, and until then I'll see the wrong
> locale version? Don't see a way to avoid that cleanly.
This could be addressed by loading the Registration.home link in an
invisible <iframe> when the browser locale changes. This page could
then notice the new locale and update the registration. I think I
could even implement this in the pure HTML+JS version.
> Related, what is the expectation on registrants in terms of how
> frequently and when they should register?
Registrants can assume that registrations are persistent and so should
only update them when they need to change. They are free to change
their registration as often as they like.
I expect sites that have a login/logout concept will refresh the
registration on every login.
> Is the intent that they
> will do it on every visit?
Whatever they find easiest to implement.
> Will the UA stop asking the user for
> approval once they've denied it once?
No.
> Will the registrant keep
> getting callbacks as it makes updates even with no changes?
Yes.
>>> - The ability to provide multiple graphical resources, not just 16x16,
>>> I think is important. Data is clear that the small icons (whether
>>> favicons or more specifically targeted to the operation) perform worse
>>> than larger and often more stylized visuals.
>>
>> Adding an icon member to the Provider
>> <http://web-send.org/introducer/#api.Provider> object is feasible. So
>> each option in the Provider selection menu starts with the
>> Registration icon and then is followed by the Provider icon.
>
> Yeah I think the icon-per-provider case is much more prevalent, in
> situations where there are multiple providers. Per your comment
> below, if there is an con for the provider, I'm not sure what value
> having an icon for the origin adds. If I can register a malicious
> provider that has the icon of some other service, i can just as easily
> add that same icon to my registration.
But you have to get the user to approve the registration icon, since
it is presented during user approval of a registration. I admit this
is a small stumbling block in a phishing attack, but the attack is not
automatic. Note that you can't change the registration icon of an
existing registration without going back through the user approval UX.
>> Out of curiosity, do you know of any data that suggests the larger
>> icon performs better than descriptive text localized to the user?
>
> I don't know how this maps to what HCI folks would say based on years
> of study, but we've seen patterns consistently in practice for this
> use particular case in pages. Big pretty icons (32x32) are 2x over
> smaller (16x16), which are themselves about double triggered menus.
So why does AddThis use a popup menu of 16x16 icons?
It creates additional vulnerability on an XSS attack and it also lets
sites abuse the Introducer as a data store.
>>> - Is there an ability to unregister, as opposed to merely updating a
>>> registration with zero providers? I'm assuming both/either would not
>>> involve any ux at all, per the spec.
>>
>> Yes, call introducer.register().
>>
>> If no Registration is specified, any current registration is deleted. See::
>>
>> http://web-send.org/introducer/#update
>>
>
> got it
>
>>> Introductions and Communications
>>>
>>> - From a provider's perspective, if I provide both window and frame,
>>> then the spec states that both will be opened, and that I'll only
>>> welcome one of them, for which I'd have to somehow communicate to
>>> really know. Is that right or is some nuance there? I'm wondering if
>>> its possible to just leave it at a precedence order.
>>
>> Both the frame and the window are configured by the same Provider, so
>> it presumably has some convention that it follows for which of the two
>> pages will be handling requests from the Customer.
>
> You're saying the case of it opening both is really just a last resort
> from the introducer side and that it shouldn't happen in practice
> because a provider wouldn't provide both?
No, a Provider might very well specify both, but it will know which
one it wants to receive the Customer messages. For example, Customer
messages might be handled by the iframe and the window is just a
short-lived popup to collect user authentication credentials and set
some cookies.
>>> - There's a mention of two factor auth, in which a provider could
>>> prompt for auth in its "window". Assuming 3rd party cookies are the
>>> reason not to use the frame,
>>
>> Phishing is the reason to not use the frame.
>>
>>> have you already discussed other ideas
>>> around this? I'm wondering if the practical detail means that if you
>>> are a provider who prefers frames, then you have to update your
>>> providers to prefer windows on logout. This ties somehow to the frame
>>> and window in parallel question above.
>>
>> Switching from frame to window on logout seems like a fine design.
>
> I think this goes to the other comment of it being a good idea to doc
> the practical requirements on provider implementors so you can then
> look at the cases that need to be handled to achieve compatibility and
> support the common use cases, and try to make it as simple as possible
> to plug in.
A new page of Provider design patterns is a good idea. I expect it
could get rather large over time. I've put starting this on my TODO
list.
>>> - Are there prohibitions on Providers requesting introductions to
>>> other providers?
>>
>> No.
>>
>> Thanks for the questions. I'll try to update the docs to be clearer on
>> these points.
>
> Wicked
Thanks again for the feedback.
http://web-send.org/bookmark/#acknowledgments
Will Meyer
Maybe there's a way to do this kind of thing more cleanly by defining
a data-type such that a registrant could register a utility endpoint,
which would itself be a proper provider. The messages associated with
that data-type would support operations like "locale changed" as well
as potentially lots of others to be defined moving forward. The
contract could be such that its frame-only, and its 1x1 hidden,
stipulated as a special case for that provider type in the same way
that bookmark stipulates some additional specificity over the core
interactions. That may just be nice on paper, but I think you def
need a way to have an opportunity to update registration info on cases
like this, and overloading the "home" param seems less ideal in terms
of being clear to a provider what they are supposed to do to enable
support.
>> Related, what is the expectation on registrants in terms of how
>> frequently and when they should register?
>
> Registrants can assume that registrations are persistent and so should
> only update them when they need to change. They are free to change
> their registration as often as they like.
>
> I expect sites that have a login/logout concept will refresh the
> registration on every login.
>
>> Is the intent that they
>> will do it on every visit?
>
> Whatever they find easiest to implement.
>
>> Will the UA stop asking the user for
>> approval once they've denied it once?
>
> No.
Taking all of these together... If I as a registrant don't really
know if my providers are currently registered, I would probably try to
register every time I am in front of the user. If the user accepted
my providers already, I'll keep getting the callbacks all the time,
which is fine though perhaps unnecessary, and if the user denied it,
then every time they visit my page they will keep getting the prompt.
I'm not sure how this system doesn't have the .mp3
fighting-media-players experience issue. Seems like the UA could
prevent this by treating redundant registration requests as noops.
>
>> Will the registrant keep
>> getting callbacks as it makes updates even with no changes?
>
> Yes.
>
>>>> - The ability to provide multiple graphical resources, not just 16x16,
>>>> I think is important. Data is clear that the small icons (whether
>>>> favicons or more specifically targeted to the operation) perform worse
>>>> than larger and often more stylized visuals.
>>>
>>> Adding an icon member to the Provider
>>> <http://web-send.org/introducer/#api.Provider> object is feasible. So
>>> each option in the Provider selection menu starts with the
>>> Registration icon and then is followed by the Provider icon.
>>
>> Yeah I think the icon-per-provider case is much more prevalent, in
>> situations where there are multiple providers. Per your comment
>> below, if there is an con for the provider, I'm not sure what value
>> having an icon for the origin adds. If I can register a malicious
>> provider that has the icon of some other service, i can just as easily
>> add that same icon to my registration.
>
> But you have to get the user to approve the registration icon, since
> it is presented during user approval of a registration. I admit this
> is a small stumbling block in a phishing attack, but the attack is not
> automatic. Note that you can't change the registration icon of an
> existing registration without going back through the user approval UX.
>
Right, I'm talking about that case -- I though approval was required
also for adding new providers. IOW, if I approve a registration from
the http://www.google.com:80 origin for the translate service, then I
have also implicitly approved the google bookmarks service, as a
future visit to the bookmarks service, requesting a registration with
both providers, will succeed without additional user confirmation?
>>> Out of curiosity, do you know of any data that suggests the larger
>>> icon performs better than descriptive text localized to the user?
>>
>> I don't know how this maps to what HCI folks would say based on years
>> of study, but we've seen patterns consistently in practice for this
>> use particular case in pages. Big pretty icons (32x32) are 2x over
>> smaller (16x16), which are themselves about double triggered menus.
>
> So why does AddThis use a popup menu of 16x16 icons?
Actually, very/more often you'll see 32x32 directly in a page. The
menu may be what we're more known for but its not really whats most
used (or most effective). A not-addthis-code version is what you see
at http://www.oexchange.org/demo/blog/, an addthis-code version is
what you see at
http://www.addthis.com/blog/2010/12/07/how-we-celebrate-birthdays-at-clearspring/
Without being able to coordinate that timing-wise between the two
endpoints, it seems like an unlikely use-case. Just $0.02.
Don't forget to thank your agent!
> --Tyler
>
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
>
Tyler Close
> On Thu, Dec 9, 2010 at 15:14, Tyler Close <tyler...@gmail.com> wrote:
>> On Wed, Dec 1, 2010 at 3:51 PM, Will Meyer <wi...@willmeyer.com> wrote:
>>> So if I switch locales, I have to visit a registrant to let it update
>>> its registration with the new data, and until then I'll see the wrong
>>> locale version? Don't see a way to avoid that cleanly.
>>
>> This could be addressed by loading the Registration.home link in an
>> invisible <iframe> when the browser locale changes. This page could
>> then notice the new locale and update the registration. I think I
>> could even implement this in the pure HTML+JS version.
>>
>
> Maybe there's a way to do this kind of thing more cleanly by defining
> a data-type such that a registrant could register a utility endpoint,
> which would itself be a proper provider. The messages associated with
> that data-type would support operations like "locale changed" as well
> as potentially lots of others to be defined moving forward. The
> contract could be such that its frame-only, and its 1x1 hidden,
> stipulated as a special case for that provider type in the same way
> that bookmark stipulates some additional specificity over the core
> interactions. That may just be nice on paper, but I think you def
> need a way to have an opportunity to update registration info on cases
> like this, and overloading the "home" param seems less ideal in terms
> of being clear to a provider what they are supposed to do to enable
> support.
I've added support for a 'refresh' property on Registrations, see:
http://web-send.org/introducer/#i18n
>>> Related, what is the expectation on registrants in terms of how
>>> frequently and when they should register?
>>
>> Registrants can assume that registrations are persistent and so should
>> only update them when they need to change. They are free to change
>> their registration as often as they like.
>>
>> I expect sites that have a login/logout concept will refresh the
>> registration on every login.
>>
>>> Is the intent that they
>>> will do it on every visit?
>>
>> Whatever they find easiest to implement.
>>
>>> Will the UA stop asking the user for
>>> approval once they've denied it once?
>>
>> No.
>
> Taking all of these together... If I as a registrant don't really
> know if my providers are currently registered, I would probably try to
> register every time I am in front of the user. If the user accepted
> my providers already, I'll keep getting the callbacks all the time,
> which is fine though perhaps unnecessary, and if the user denied it,
> then every time they visit my page they will keep getting the prompt.
> I'm not sure how this system doesn't have the .mp3
> fighting-media-players experience issue. Seems like the UA could
> prevent this by treating redundant registration requests as noops.
Then how do you enable a registrant to try again at some reasonable
later time? Rather than require coordination between the registrant
and the Introducer to solve this, it seems best to leave it entirely
to the registrant. The registrant can set a cookie to remember that
the user said no last time and so avoid annoying the user with another
request. This registrant can then delete the cookie if it thinks it's
reasonable to ask the user again.
A Registrant has lots of ways of annoying the user. Making register()
requests is one of the least effective ways of annoying the user,
since it only causes an infobar to be presented on the registrant's
page. The registrant could cause the same UI, or much worse, without
any help from the Introducer.
The Introducer does not have the fighting-media-players experience
issue, since there is no single default registration for the mp3
data-type. Multiple registrations for the same data-type co-exist in
complete ignorance of each other. The user's favorite option is always
presented as the top option, but only because the Introducer tracks
which one is being used most often. There's no way for a Provider to
force its way to the top of the options list.
>>> Will the registrant keep
>>> getting callbacks as it makes updates even with no changes?
>>
>> Yes.
>>
>>>>> - The ability to provide multiple graphical resources, not just 16x16,
>>>>> I think is important. Data is clear that the small icons (whether
>>>>> favicons or more specifically targeted to the operation) perform worse
>>>>> than larger and often more stylized visuals.
>>>>
>>>> Adding an icon member to the Provider
>>>> <http://web-send.org/introducer/#api.Provider> object is feasible. So
>>>> each option in the Provider selection menu starts with the
>>>> Registration icon and then is followed by the Provider icon.
>>>
>>> Yeah I think the icon-per-provider case is much more prevalent, in
>>> situations where there are multiple providers. Per your comment
>>> below, if there is an con for the provider, I'm not sure what value
>>> having an icon for the origin adds. If I can register a malicious
>>> provider that has the icon of some other service, i can just as easily
>>> add that same icon to my registration.
>>
>> But you have to get the user to approve the registration icon, since
>> it is presented during user approval of a registration. I admit this
>> is a small stumbling block in a phishing attack, but the attack is not
>> automatic. Note that you can't change the registration icon of an
>> existing registration without going back through the user approval UX.
>>
>
> Right, I'm talking about that case -- I though approval was required
> also for adding new providers.
No.
> IOW, if I approve a registration from
> the http://www.google.com:80 origin for the translate service, then I
> have also implicitly approved the google bookmarks service, as a
> future visit to the bookmarks service, requesting a registration with
> both providers, will succeed without additional user confirmation?
Yes.
If a registrant abuses this ability, the user can easily delete the
registration. That motivates a registrant to be well-behaved.
>>>> Out of curiosity, do you know of any data that suggests the larger
>>>> icon performs better than descriptive text localized to the user?
>>>
>>> I don't know how this maps to what HCI folks would say based on years
>>> of study, but we've seen patterns consistently in practice for this
>>> use particular case in pages. Big pretty icons (32x32) are 2x over
>>> smaller (16x16), which are themselves about double triggered menus.
>>
>> So why does AddThis use a popup menu of 16x16 icons?
>
> Actually, very/more often you'll see 32x32 directly in a page. The
> menu may be what we're more known for but its not really whats most
> used (or most effective). A not-addthis-code version is what you see
> at http://www.oexchange.org/demo/blog/, an addthis-code version is
> what you see at
> http://www.addthis.com/blog/2010/12/07/how-we-celebrate-birthdays-at-clearspring/
I was hoping a large general purpose share click target with a drop
down of specific options would get good clickthrough. That's probably
not the case today, since the Facebook/Twitter logo has better brand
recognition than the generic sharing icon. Maybe it's possible for
this to change over time? Especially as more sites adopt the Open
Sharing Icon?