[Design] [Cosmo][Sum] Accessibility for home collection browser

[Mimi Yin]

Priscilla asked me to summarize this thread with high-level  
requirements and goals, a recap of the proposal and summary of the  
various concerns that have been voiced on the list about that  
proposal. It's been a long and gnarled thread, so please bear with me  
when you discover that I've forgotten something important and reply  
with your own addenda.

I will follow-up tomorrow morning with a new proposal that is a riff  
on the one described below, but hopefully tweaks the design in just  
the right way to address people's concerns. (Mostly refines step 1 of  
the proposal.)

High-level requirements, goals and mental model concepts we should be  
on the same page about:

1. There is 1 Project called Cosmo, but how should we characterize  
the Products/Services to end-users? (I think this issue needs to be  
discussed more.)

2. Admins and Filebrowsers are unlikely to be CCs. CC's are unlikely  
to be admins and filebrowsers. However, power user CC's may want to  
have access to the filebrowsing UI to help us troubleshoot bugs.

3. There are separate UIs for admin/filesharing and end-user CC.  
However, these three UIs intersect at various points and we don't  
want them to be completely segregated. However, because the CC is  
still the target user, we're going to have to do some creative  
thinking and make some hard trade-offs to ensure that the UI as a  
whole stays focused and is optimized for CC usage. This means that  
when thinking about the various 'access points' to the admin and  
filebrowsing UIs, we need to be careful that they don't become  
stumbling blocks for CC users, as in, things that are easily  
discoverable and that when discovered, will simply confuse CC's, or  
worse lead unsuspecting Casual Collaborators to commit self- 
destructive acts, e.g. ill-considered deleting of collections and  
willy-nilly issuing of tickets.

4. At the same time, we also don't want to make accessing the admin  
and filebrowsing UIs overly combersome for admins and filebrowsers.  
However, this requirement needs to be met within the confines defined  
in the above (#3).

5. Homedir browser UI is not just another view of the user's data. It  
is analogous to Chandler's repository viewer. If/when in the future  
we support filesharing or more accurately document management  
scenarios, we will most likely support those scenarios by integrating  
them into the end-user CC UI we're building today (ie. Manage your  
documents with a Dashboard and Calendar, complete with support for  
triage, stamping, alarms, edit/update etc). The homedir browser will  
also continue to develop and improve, but it will most likely remain  
a 'behind-the-scenes' UI for power users, most likely developers.

Questions about the above-stated requirements:
+ Is this a clear articulation of our requirements and goals?
+ Is this an accurate articulation of our requirements and goals?
+ Are any of these things new for anyone?
+ Is there anything you would add?

Recap of Proposal:
1. From the login page, provide admin and filesharing users with a  
separate way to login so that admins and filebrowsers don't need to  
click through the end-user UI to access the admin/homedir browser  
UIs. Access to the separate admin and filebrowsing login pages should  
be discrete enough that it doesn't distract the CC. These separate  
login pages should be bookmarkable (ie. URL/subdomains) to provide  
even more direct access for admins and filebrowsers.

URL/subdomains would also be documented for admin and filebrowser users.

2. Provide a way to access the end-user CC UI from both the admin and  
homedir browser UIs

3. If an admin logs into the end-user CC UI, we automatically put a  
link to the admin UI in the CC UI.

4. Provide 2nd-order way for CC's to access the homedir browser (as  
in, not a 1st order link on the main UI).

5. Homedir browser and end-user CC UI should open up in separate tabs/ 
windows. (This is consistent with Requirement #5 above: The homedir  
browser should not be treated as yet another view of the CC's PIM data.)

Concerns this proposal was intended to address:
1. Don't make it too hard for admins / filesharing users to find the  
UI they're looking for.
2. Don't confuse CC's with links to admin/filesharing UIs.
3. Don't make it too hard to move between the end-user CC UI and the  
admin/filesharing UIs.

Concerns people voiced:
1. Separate log in for admins and filesharing users seemed overly  
cumbersome.
2. Turning on access to the homedir from Account settings felt too  
convoluted and not discoverable.
3. There was confusion about whether users would need to logout and  
log back in, in order to access the different UIs (ie. admin,  
filebrowsing, and CC). Hopefully that confusion has been clarified in  
the proposal recap: Users will not need to re-login in order to  
'switch between the CC and admin/filebrowsing UIs'.
4. Filebrowsing and CC UIs should not launch in a separate tabs/ 
windows because they are  simply different views on the same end-user  
content.

Questions for the above-state proposal:
1. Is the proposal clear?
2. Do the concerns listed above accurately reflect people's concerns?
3. Is there anything missing from that list?
4. Do people still feel the same about the concerns they've voiced?

Thanks!

Mimi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20061206/c464cd74/attachment.html