Philippe Bossut wrote:
Mimi Yin wrote:
Another thing to consider is that in the future, we will have the
independent view selector back in the summary view area, so users
will be able to switch between the table view, the calendar view and
maybe some other crazier view altogether (timeline views, concept
maps views, thumbnail views etc) independent of the application area
that is selected.
I like this! This will separate the "filter" from the "view" aspect,
both performed by the toolbar right now and the source of the issue we
are talking about.
Having external contributors able to provide new innovative views of
data is also something we should encourage. I have a couple of wacky
ideas of my own I'd like to "parcelize" that way... (like the PCA view
:) )
+1. I've been in favor of this for a long time.
But, I agree it's weird right now that you're in the Calendar and the
In collection and you overlay it with a user-defined collection, the
view switches from Table to Calendar with no feedback as to why that
has happened.
So, what about not forcing the view switching for the moment (in 0.6)?
Anyway, as Sheila mentioned, this is a corner case for 0.6 since few
people will ever see the In and Out collections.
+1. This would also simplify the code considerably -- making our
development job easier
An alternative we considered was making it impossible to overlay the
In and Out and Trash collections with anything other than the In, Out
and Trash collections. In other words, table view collections can
only be overlayed with other table view collections. But this felt
like yet another exception to throw into the sidebar checkbox
behavior that would make it both more complicated to implement and
harder for the user to grok.
I would stay away of creating UI exceptions and rules. We should have
a UI that's elegant and does not impose or constrain the user. We can
easily imagine cases where overlaying the Out box with a user defined
collection can be useful and make sense.
+1 Good design avoids special cases. It benefits users because it's
easier to figure out, makes our job building Chandler easier, and
extends in new situations. I think it's better to start with a simple
design that avoids special cases then add special cases based on user
experience.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
