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
