[Design] [Cosmo] [Bug 8081] New: account setup information in signup dialog possibly incorrect or in need of reorganization

[Mimi Yin]

Okay so the different usage scenarios after signup are:
1. Sign-up for an account to publish to Hosted Service / Sharing  
Bundle from client, either Chandler or iCal or Sunbird or something  
else.

2. Sign-up for an account to use the web app as a Casual Collaborator.

3. Sign-up for an account to use the web app by itself.

Is option #1 what you're referring to by 'click here for instructions  
on how to set up a client application'

Nothing in-line for now...

I agree that showing the full-path URL is confusing, especially for  
Chandler and CC users. So having dynamic instructions designed around  
what users are trying to do, we can show/hide this and other relevant  
information on a case by case basis.

Okay, if I have this right, I think the UI we have for this could be  
similar to the Subscribe-experience we already have spec'd out. Let  
me noodle on this and come back with some screens.

Mimi

On Feb 16, 2007, at 12:25 AM, Brian Moseley wrote:

> <whoops, meant this to go to design>
>
> On 2/15/07, Mimi Yin <mimi at osafoundation.org> wrote:
>
>> preview chandler will not use either of these infos; it will get any
>> protocol
>> information it needs out of the user's USD.
>>
>> USD?
>
> user service document. it's an xml document that chandler and other
> programs can ask for from cosmo that lists all the the different
> protocols that can be used to access the server and how to construct
> urls for them for a particular user.
>
>> What are the other URL options? Is this in the Account Browser? I  
>> wasn't
>> able to find the 'full URL'.
>
> try signing up for an account on qacosmo or another live server. when
> you submit the form, the dialog displays a table of information. one
> of the rows is "full URL". another is "path".
>
> there are many ways to access any given collection in cosmo - in the
> ui, with dav, with atom, with morse code (which is how chandler shares
> in a5 and beyond). each has its own special url.
>
> there's also a special "home collection" accessible with dav that is
> the root of a traditional filesystem-like hierarchy of collections.
> that has its own url (which is the one that is listed as "full URL" in
> the signup dialog, and which was the chandler sharing url in a4 and
> previous versions).
>
>> I'm not following the last sentence? If the instructions are  
>> dynamic? as in
>> different instructions for different clients? Not following why this
>> requires auto-login. How would auto-login interact with email  
>> confirmation?
>
> dynamic == the instructions are tailored to the specific user and to
> the server's configuration.
>
> imagine this workflow:
>
> 1) on cosmo front page i click "sign up for account" and get the  
> signup dialog
> 2) i fill out and submit the form
> 3) the dialog replaces the signup form with a success message and
> links for "click here to view your calendar on the web" and "click
> here for instructions on how to set up a client application".
>
> given that you just entered a username and a password (and confirmed
> the password, even), it seems silly to add an extra step to this
> workflow to make the user log in.
>
> of course, if email confirmation is turned on, then auto-login isn't
> an option. in that case, i'd say replace step 3 above with a message
> that says "check your email and click the link in it to confirm your
> account." and that confirmation link could then offer the same options
> in my original step 3.
>
> i understand that different people will sign up for server accounts
> for different reasons. that's why i brought up this issue. the signup
> dialog right now doesn't make any attempt to distinguish between these
> expectations. it just shows "path" and "full URL", which made sense in
> the olden days when only dav could be used to sync/share between
> client apps and cosmo, but now that we have morse code as well, and
> people who will only ever use the web ui in preference to any other
> client app, the signup dialog needs to accomodate all of those people.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design