Re: [Design] [Scooby] Anonymous access to read-write tickets and security concerns

[Mimi Yin]

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

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design