[Design] [Cosmo] Accessibility for home collection browser

[Mimi Yin]

Hi Jared, see comments in-line:

On Dec 4, 2006, at 2:58 PM, Jared Rhine wrote:

>>>> + We need to design the right UI optimized for our primary target
>>>> user - casual collaborator.
>
> Turns out that this original language can be interpreted multiple  
> ways.
>
> One way is "the filebrowsing UI should be optimized for CC usage".   
> This
> was how I interpreted the statement, given all the surrounding
> context/language/thread of "filebrowsing UI"; this interpretation was
> wrong.

Yes, I can easily how someone might interpret it that way.

>
> The other is "the primary (PIM) UI should be optimized for CC usage".
> This is closer to the intended meaning.

I would refine that further. The UI as a whole, which includes access  
to the admin and filebrowsing UIs should be optimized for CC usage. I  
believe that is what is meant when we say that it's okay if access to  
the admin/filebrowsing UIs is a bit awkward, the important thing is  
to not confuse the CC user.

>> I think this is where I'm getting lost. When you say 'optimizing for
>> the casual collaborator" do you mean, making the homedir browser
>> accessible to the CC? just in case the CC might also want to use the
>> homedir browser?
>
> I meant that the homedir browser functionality shouldn't be simplified
> to suit only the CC users.  As a "power"+admin user, I'd rather see an
> ugly, rough, but featureful set of pages than a trimmed-down  
> version of
> the filebrowsing UI.

I agree that we don't want / need to simplify the filebrowsing UI.  
We've mostly been talking about how to provide access the  
filebrowsing UI from the end-user CC UI.

>
> One observation from an offline conversation is that the admin user
> typically accesses the filesystem browser via the "user list" page  
> (the
> "browse" link next to each user's row).  Power/PIM users who want  
> to see
> the filesystem view of their same data go directly from the PIM to the
> filesystem browser, a different route than admin users.

Yes power CC's should be able to access the homedir browser from the  
CC UI. But being that it's a power feature, access to the homedir  
browser probably shouldn't be a first order link on the UI, but  
should instead be at least 1 click away.

>
>> The homedir browser and access to the homedir should not be
>> optimized for the CC, but instead, should be optimized for the file-
>> sharing user, a user who is not collaborating with a Chandler user on
>> PIM scenarios via the Hosted Service.

Again, I think there's a slight misunderstanding here. It's not that  
the homedir browser UI itself should be optimized for the CC, but  
access to the homedir browser needs to be optimized for the CC  
because we don't want the CC to accidentally go to the homedir UI and  
get confused.

>> What do you mean by common case?
>
> For the file browser, the common case would be file browser users  
> and/or
> admin users.

Agreed. However, the common case for the end-user UI will be the CC.  
And I think what we're discussing/debating here is how to provide  
access to the homedir browser from within the end-user CC UI.

>
>> I think I see a clear separation in designs or UIs. 1 for admins. 1
>> for file-sharing users and 1 for the end-user CC.  [...] I believe as
>> consumer facing products/services, they should be distinct and
>> separate. Perhaps that is the source of the general confusion?
>
> Per the above, we're not really on separate pages; the confusion was
> temporary.  I'd note that "distinct and separate" can take multiple
> forms.  While separation through task-focused UIs is a good thing,
> distinct-and-separate to the point of needing to logout of one to  
> get to
> another would be taking the separation too far, for instance.

I don't think anyone was proposing this? Although this thread has  
been going for so long, I'm sure I've missed things.

>
> Also, I encourage the "end-user CC" UI to be usable and suited to the
> "standalone" case.  I will continue to support not targeting  
> standalone
> web usage in the Preview timeframe, but I would not like to see a  
> 4th UI
> developed when the standalone case is directly addressed later.

I think we can agree on this. :o) Mimi