[Design] [Cosmo] Login-related workflows update

[Mimi Yin]

Hi, see in-line...

On Nov 6, 2006, at 11:06 AM, Priscilla Chung wrote:

> That's fine. One of the questions I've been pondering is if the  
> users who would use file sharing might also be a casual  
> collaborator (CC) target user. So my original thought would be to  
> have an 'advance features' link in the 'settings' dialog.  See  
> image on update wiki page: http://wiki.osafoundation.org/bin/view/ 
> Journal/WorkflowsZeroDotSix
>
> After speaking with Mimi last Friday, she mentioned that it sounded  
> like the 'file sharing' user and the CC were two different types of  
> users and why expose the calendar UI to users who want to just do  
> file sharing. The proposal she suggested would be to differentiate  
> the user when logging on. Our original thought would be to add a  
> check box somewhere on the log in page for admin user, file sharing  
> user and uncheck both if you're a CC. (Mimi feel free to chime in  
> if you were thinking differently here…)

Oh I think it was just to have separate links (off to the side) on  
the Login page for:
+ Login as admin
+ Login for filesharing UI

>
> This proposal bothered me for various reasons:
> + Why confuse the user with all these checkboxes before log in?  
> Users do not define themselves as CC as we're doing to meet product  
> goals for 'Preview'. Additional checkboxes on login will just  
> confuse users.
>
> + Would a user who is using file share also want to use the  
> calendar UI? Though there are different types of usage for Cosmo  
> this early in the stage, there is no reason why the file sharing  
> user and the CC are the same person. So then I would ask, why would  
> you have to force the user to sign in and out (switch identities)  
> of the web app to go from one area to another?

I think the question is less: Should we prevent file-sharing users  
from accessing the Casual Collaborator UI?
It's more: Is it important to design the right UI to allow file- 
sharing users to access the CC UI?

>
> So here is an alternate proposal I'd like to suggest:
>
> 1. Opposed to having login checkboxes, use separate subdomains for  
> capabilites. This is the model followed by a number of web apps,  
> for example calendar.google.com, mail.yahoo.com. A user may login  
> to any google of google's 'properties' such as gcal or gmail, enter  
> the subdomian url of another property and preserve their login status.
>
> For an OSAF example, it might be:
> remotedisk.osaf.us/cosmo	--> file sharing UI (currently part of  
> automation, but really should be its own application)
> osaf.us/cosmo -->the web ui for calendar and collections, as  
> supported by cosmo.
> admin.osaf.us/cosmo --> the current administration interface.

I think this is a better alternative in that it doesn't confuse  
Casual Collaborators with links for admin/file-sharing login.

>
> 2. In addition to the subdomains, I propose we also keep the  
> advance link within the settings dialog to allow users to  
> administer their own collection. This 'advance' link will open the  
> admin interface in a separate browser window thus providing a  
> direct connection between the calendar UI and home collection.

My only confusion about this proposal is that I don't really think of  
the file-sharing and admin UIs as settings. Settings connotes  
preference settings for the CC UI.

>
>> i would also like to point out that we shouldn't be overly worried
>> about time constraints at the moment. you guys should just spec out
>> what you want to ultimately happen, and the devs will analyze and do
>> time estimates, and if the whole team decides we need to cut things,
>> we will. don't pre-emptively cut, please :)
>
> Yup. As I had mentioned to you in passing, there are lots of things  
> which run though our heads when we're coming up with design  
> workflow and this is sometimes our way of suggesting priority. That  
> if we were to cut features, how would the design workflow behave?  
> Does it still make sense if we don't complete the full feature.  
> This is why we come up alternate designs and iterate with  
> development. ;)
> -Priscilla
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design