[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