> >> + 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. The other is "the primary (PIM) UI should be optimized for CC usage". This is closer to the intended meaning. So the rest of my email should be interpreted as a cautious inquiry into "do you really mean the filebrowsing UI should be optimized for the CC"? No one was saying this, so there's no disagreement. > And furthermore, it's unclear that people using the filesystem > view are working within the PIM domain. My understanding was that it > was highly unlikely homedir browser users would be using the homedir > view for PIM use cases. That seems true as well. > 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. 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. > 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. This was the crux of my inquiry. I agree with the view that the homedir view should not be optimized for the CC. I interpreted the original "We need to design the right UI optimized for our primary target user - casual collaborator" as contradicting that. When I reinterpret this one point to say that the *PIM* UI should be optimized for the CC, that makes total sense. And means I found no objections to Sheila's recap of the issues, after attempting to review carefully. > > I agree that the file browser should be available to all users and not > > confuse the casual collaborator, but user-centered design would > > seem to suggest optimizing for the common case. > > What do you mean by common case? For the file browser, the common case would be file browser users and/or admin users. > 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. 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. -- Jared Rhine <[EMAIL PROTECTED]> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
