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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
