| 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
|
