[Design] [Scooby] Anonymous access to read-write tickets and
security concerns
Mimi Yin
mimi at osafoundation.org
Fri Jul 14 16:30:43 PDT 2006
True, users create accounts all the time for services they decided to
invest time and effort and sometimes even dollars in to use.
Users are generally loathe to create accounts for services somebody
else wants them to use. That's the key difference between the Hub
user (who is happy to go through the trouble of setting up a Cosmo
account) and the Casual Collaborator who never heard of Chandler,
Scooby, Cosmo, the Hosted Service or the Ecosystem...and is for
better or worse, being forcibly collaborated with.
Creating and managing accounts is a pain, and unless a person really
wants to use a service, they'd just as soon as not use the service if
it means creating and managing yet another account. The thesis is
that in our 0.3 use case of updating a shared office calendar with
PTO information, the Casual Collaborator is an example of someone
who: presented with a choice between sending an email or creating and
managing an account in order to use a new collaboration tool, would
just as soon as not use the service, thereby saving themselves the
trouble of having to create an account.
In other words, the interests and goals of the Collaborat-OR and the
Collaborat-ED are not aligned. The Hub/Coordinator gets all of the
benefit out of getting everyone to use the Ecosystem...But the Casual
Collaborator is the one that has to surmount hurdles to make the
collaboration work. (There is an analog to this scenario in the way
that calendaring, scheduling and invitations has been set up to work.)
This misalignment of interests and goals is why:
+ Evite doesn't require user accounts to RSVP.
+ Flickr doesn't require user accounts to view pictures.
+ Many e-tailers (including Amazon) are now allowing users to make
purchases without creating accounts.
+ It's one of the reasons why Microsoft created Passport.
It's why it's impossible to get some of my friends and family on IM
to chat with me, because they don't use IM enough to feel like it's
worth setting up an account. Yet, once in a while, it would be really
useful to be able to chat.
Instead I should be able to send them an email when I know they're
online...pinging them to click on a link and engage in a chat with me
by using a temporary 'anonymous' account.
I'm also guessing this is one of the reasons why shared calendars on
Yahoo and Hotmail never really took off, even though they've been
around for a hundred years.
+ Does anyone have anecdotes about services that have been successful
at getting users to sign up for accounts?
+ Does anyone have anecdotes about services that have had a hard time
getting users to sign up for accounts?
Perhaps a few case studies will clarify the issue for all of us.
Mimi
On Jul 13, 2006, at 11:40 AM, John Townsend wrote:
>
> On Jul 12, 2006, at 5:26 PM, Mimi Yin wrote:
>
>> It's also problematic because one of the design requirements we're
>> putting forward is that users don't feel like they're creating /
>> maintaining an account. Jeremy's proposal meets this requirement
>> because the accounts are auto-generated (although asking users to
>> pick and remember a password is still problematic).
>
> I don't understand why this is a design requirement. Users create
> accounts online all of the time. They are used to it, they do it on
> multiple web services already. I really don't like the idea of auto-
> generating accounts. I would rather see us be more explicit with
> the user and tell them we are creating an account on their behalf,
> let them tell us how to name/identify this account, etc.
>
> I understand that Chandler doesn't require a login. But, this is
> another case where Chandler is not a web application and Cosmo/
> Scooby is. The requirements and expectations are different.
>
> --> towns
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060714/06688f15/attachment.html
More information about the Design
mailing list