3 Apr 2006 01:44
[Sum] Dession Session 2 on Stamping and Communications
Sheila Mooney <sheila <at> osafoundation.org>
2006-04-02 23:44:56 GMT
2006-04-02 23:44:56 GMT
In advance of the design session this Tues, I wanted to summarize the stamping discussions we have had on the list since the last design session on Mar 14th.
Thread: Dession Session 2 on Stamping and Communications
Relevant concerns giving context to this email
- stamping will not work for all use cases
- stamping does not allow you to link multiple items together - no way to link 2 events to a single note
- we don't really have a fully vetted ui solution for linking
Take away concern from this thread
- there is some disagreement that this use case is really suited to stamping
- there is a need to want to solve the multiple item problem
- the developers think about it from the perspective I have this thing "book" and there are some events I want to link to it - that have some relationship to the book
- Mimi is thinking, I have this thing "book" and I want to put it on my calendar for relevant events - this book directly spawns some events - kind of like I will likely take this book to all these various events I am attending
Proposal:
+ Morgen replied to this thread with a proposal that unifies stamping and linking in the detail view.
+ instead of the stamp being a stamp/no stamp toggle, you could continue to click on any stamp to add more kinds to that particular item
Use Case:
+ I have a book "Time Traveller's Wife" and want to stamp it as an event multiple times or add multiple messages, notes etc.
Philippe:
+ there is a current assumption made by the detail view that it displays one item only.
+ we don't currently have a UI proposal for displaying and manipulating linked items (ie: item browser)
Morgen:
+ explained that under the hood we are actually displaying multiple items in the detail view. Each attribute itself (email address vs to field) is an item.
+ likes his proposal because if you collapse the linked items you have the item list you want.
+ if you want to see more detail, you don't have to leave the context you are in.
+ you should be able to click on any of those linked items - using some affordance to get to the detail view of that item
Mimi:
+ we could consider an alternative approach to thinking about this
+ you could think about this scenario as it it's a recurring event
+ we have a book and we want to create a custom recurring series to put it on the calendar in multiple places
+ each of these would be represented as a row in the summary table view.
+ we can edit the data in the detail view to be specific for this instance of the event - who field might contain data that relates to a host for a book club, a lecturer, the author for a book signing
+ you basically have a set of events where the topic is this book but the events could be quite different (book club vs book signing)
Morgen:
+ doesn't understand how you would create such an event
+ would you create a series (monthly) and delete everything that you didn't care about, just to have 3 events which are kind of distinct anyhow.
+ this seems more like 3 discrete events
+ as a user I would rather be viewing the book in the detail view and have affordances for attaching an event* to the book; or be viewing the week view, creating an event on the appropriate day and attaching the book (or multiple books) to the event (by dragging, or having a +Book button in the detail view like in my mockup).
Mimi:
+ there is no ui for this currently
+ we would assume we would support advance recurrence where we could create such a series in an easy way
+ just providing another perspective on how to think about this rather than thinking about linking
+ just exploring this to address concerns about how far we can push stamping
Jeffrey:
+ we haven't exposed any UI for custom recurrence but he imagined that we would support powerful features like this in the future
Bryan:
+ at a user perspective, he doesn't feel this is a recurrence use case
+ thinks it's really a situation where some form of tagging relates what are really disparate events.
+ recurrence is best suited for situations where we are trying to present the appearance of one thing - a recurring meeting
+ changes would not likely apply to all these events once they are related other than fixing a spelling error etc.
+ each of these events is it's own thing and just links back to something it has in common
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
RSS Feed