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