[Design] [Sum] Dession Session 2 on Stamping and Communications

[Sheila Mooney]

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
http://lists.osafoundation.org/pipermail/design/2006-March/004334.html

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.
+ http://wiki.osafoundation.org/bin/view/Journal/LinkingAndStamping
+ 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060402/71681de2/attachment.html