Hi John,
I think there are a few things missing from the user model below that
might help clarify things.
1. Focus is rarely in the sidebar...Focus only shifts to the sidebar
through tabbing (which is rare) and/or d-clicking to edit a
collection name.
2. There will be separate menu items for manipulating collections:
Duplicate, Remove, Delete etc...
see proposed menu structure in: http://wiki.osafoundation.org/bin/
view/Journal/UnifiedDataInAndOutProposal
3. There shouldn't be 2 selections in the sidebar. The user shouldn't
know about 2 sidebars.
More comments/questions in line.
On Aug 29, 2006, at 9:23 AM, John Anderson wrote:
Hi:
As I mentioned to Philippe, after nearly three weeks working on the
new sidebar, it's still not finished and it's raised a number of
sticky issues, which makes me wonder if it's the right approach.
I was hoping to get a "somewhat" functional demo for people to play
with to spark some debate, however, getting a version that doesn't
seem totally broken is taking longer than I thought.
So, let me start by posing one of the problems to at least start
the debate.
The new sidebar has is made up of two separate sidebars, one for
the "out of the box" collections, another for the "user"
collections. This means there are two separate sidebar selections.
When you're displaying the "out of the box" collections in the
summary view, you're limited to only collections in the "out of the
box" sidebar. Likewise for the "user" sidebar.
I'm not sure I understand this...what does you mean when you say that
users are limited to only the collections in the OOTB sidebar?
According to the spec, OOTB collections can't be overlayed. In the
OOTB area, uou should only be able to see the selected OOTB collection.
One problem is caused by an ambiguity of whether or not a command/
operation refers to selected items in both sidebars, the "out of
the box" sidebar, or the "user sidebar".
Only 1 collection should be selected at a time.
When the sidebar has the focus, it seems like you probably want to
consider the focused sidebar only. However when neither sidebar has
the focus, should you consider both sidebars together, or perhaps
the last one that had focus. If neither sidebar has focus, but only
one is "active" then we'd probably have to draw it differently
otherwise you couldn't tell which one the command would operate on.
This might lead to some confusion. It's breaking the simple, and
universal notion, of a single "active selection" -- it's like we
have more than one "active selection": the one where typing goes
and the one when some other command affecting the sidebar go.
It seems like if nothing has focus, then the menu items should be
disabled?
As an exercise to help sort this out, go through them menus and
ask yourself the question: what should each command do given the
various combinations of focus and selections in both sidebars?
Even if we were to go with exposing the 2 sidebars to the user (e.g.
persist selections in both sidebars and shift focus back and
forth)...I'm not sure how this would be that different from Apple's
multi-vertical-pane Finder UI.
John
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
