I think the best way to think of the In and Out collections are as lists of:
Invitations I've recieved and
Invitations I've sent...
For this reason, I've considered alternative names for those
collections: Invites and Outvites? etc...but it felt weird to change
their name for just the Calendar app area. So I'm hoping with use,
people will get it without the name change. But that might not happen.
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.
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.
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.
This will hopefully be clearer, when there's a view selector and the
view selector changes from table to calendar view.
Mimi
At 11:00 PM -0700 9/26/05, Sheila Mooney wrote:
Philippe,
The idea behind having In/Out as table views when you are in the
Calendar is because we imagine these collections to contain received
and sent invitations in the future. I expect Mimi thought this would
be more appropriate for a table view rather than a calendar view.
This was the intended design but we realize this is problematic
especially when you overlay collections. We still need to do some
thinking about this.
For 0.6 we are going to hide these collections if you do have email
setup and since we are not highlighting the email features of
Chandler for 0.6 we expect most people will not see the In/Out
collections. For the case of the 0.6 tenets, there shouldn't be much
confusion.
Sheila
On Sep 26, 2005, at 10:21 PM, Philippe Bossut wrote:
What about the case of the In and Out Collections?
Currently, they are always displayed using the Summary Table View,
regardless of what's selected in the toolbar. This leads to
problems like when "activating/disactivation" another collection:
the view switches from Calendar to Summary Table without the
toolbar being touched or even reflecting any of this.
I'd vote to consider these cases as bugs: we should always display
a view consistent with the toolbar area chosen. Indeed, events can
be stored in the In and Out Collections so there's no reason to
impose using the Summary View in that case.
Anyway, in general, being able to activate and view several
collections simultaneously certainly creates problems if some
collections are associated with one particular view (as suggested
by John).
Cheers,
- Philippe
Mimi Yin wrote:
Just talked with Katie, Lisa and Sheila about this. I think we'll
want to treat Certificates separately from collections in the
Sidebar for now. I can imagine in the future allowing users to
drag certificates into sidebar collections to manage as
first-class information items (ie. Heikki's use case of putting
certificates on the calendar as reminders for renewing them). OR
somebody writing a 3rd party parcel for admins to help them manage
certificates.
But from the end-user's point of view, certificates aren't really
information items. They're part of the mechanism that makes
sharing and email work, like the Account settings themselves. As
such, I would suggest keeping the Certificate management stuff in
a dialog, accessible from the Accounts dialog. And once we have a
more general Preferences panel, we can stick it in there.
Again, this doesn't preclude later on having a Certificate
management parcel that treats certificate items as information
items, but out of the box, I think it would make more sense to
treat it as a tool than as content.
As for scripts, given that they're really developer tools right
now, we should treat them the same way we treat the repository
viewer and block demo. In the future, I can imagine a separate
window where users can manage scripts or ("agents" or macros).
Again, for 1.0, we'll want to draw a clear distinction between the
kinds of things in the sidebar (information items), developer
tools, and end-user tools (dialogs and separate pop-ups).
Mimi
P.S. Adding this to the design list since this is more of a design
discussion.
On Sep 26, 2005, at 2:20 PM, Donn Denman wrote:
The current Drag and Drop infrastructure supports disallowing
drops that don't make sense. The Sidebar currently has the
responsibility of deciding what to allow to be dropped onto each
of its entries. I imagine the Sidebar could examine kind-centric
collections like Scripts and Certs and automatically restrict the
allowable items for the drop.
On Sep 24, 2005, at 8:07 AM, John Anderson wrote:
These are interesting problems which occur because our design
didn't consider the possibility of either the certificate store
or the scripts collection in the sidebar. Our current design
chose to focus on a limited set of scenarios. A more flexible
design might associate a viewer (CPIA tree of blocks) with a
particular collection, which would solve the display problems.
The viewer could allow/disallow stamping and other features by
containing or not containing the appropriate UI. Drag and Drop
might best be handled the collection itself. Both these design
choices would be relatively easy to implement given our current
infrastructure.
John
Heikki Toivonen wrote:
We have some unusual collections, like Scripts and Certificate Store,
that behave somewhat differently than your typical collection of events,
tasks and so forth.
This leads to interesting situations I am not sure how to solve, so some
design decisions are called for. Here are some examples.
You have Certificate Store selected in the sidebar. Arguably you should
not be able to create/move non-certificates into this collection. I
don't think we have any support for that (I am pretty sure you will get
exceptions raised if you try). And you need different type of feedback
to the user so that they won't even try or if they manage to try give
some useful feedback that it is not supported (create event from menu,
copy/paste, drag & drop, double click, ...).
You have Scripts selected in the sidebar. You click on Calendar toolbar
button. Currently what happens is that the toolbar buttons seems to be
selected but you get an empty summary table view. While at first glance
it would seem it would be ok to disable the toolbar buttons that don't
make sense, this will lead to a situation where the user does not
understand why they can't switch to the calendar, for example.
You can actually stamp a certificate to an event, for example. For some
reason this does not show up on the calendar - seems like a bug. At
first glance you might say it is stupid to stamp certificate and
stamping should be disabled for certs, but if you think of the case
where you are buying certificates (which expire yearly) you'd like to
have a calendar reminder to renew the certificate before it expires. And
come to think of scripts, why not make it possible to stamp scripts too
- a script event could run at the specified time etc.
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
