[Design] Design Session 2 on Stamping and Communications

[Mimi Yin]

Thanks for putting together the mockups Morgen.

An alternative we might consider would be model this use case in the  
same way we do recurring events. (This was a point that we didn't  
quite iron out in yesterday's meeting)

So you have a Book: Time Traveler's Wife. And there is a series of  
events about this book. If you could violate the laws of physics, you  
might "Put this book" on the calendar in multiple places...so that  
you could use the Book itself as the reminder for what the meeting  
was about. (ie. Putting the dentist's business card in your Day  
Planner on the day you have an appt to go to the dentist).

Each event is a custom recurrence in the series, represented as a row- 
item in the summary table:

SUMMARY TABLE VIEW
Book club: Time Traveler's Wife @Lizzy's House on Mar 10, 2005
Book signing: Time Traveler's Wife @Cody's Books on Apr 3, 2006
Lecture series: Time Traveler's Wife @UC Berkeley on Sep 19, 2006

In the DETAIL VIEW you might have fields like:

WHO ATTRIBUTES
Host: (Book club event)
Guest: (Book signing)
Lecturer: (Lecture series)

WHAT ATTRIBUTES
Event notes: (Which would be different for each event)
Book synopsis: (which would be the same for each event)

Or you might not care to structure your data and you just have one  
blob of text in a generic Notes field.

Mimi


On Mar 15, 2006, at 8:17 AM, Morgen Sagen wrote:

>
> On Mar 14, 2006, at 10:58 PM, Philippe Bossut wrote:
>
>> Morgen Sagen wrote:
>>> Following up on the meeting we just had, here are some mockups of  
>>> a detail view showing how stamping and linking could be unified:
>>>
>>>    http://wiki.osafoundation.org/bin/view/Journal/LinkingAndStamping
>> Excellent. Note however that such a UI would break the current  
>> assumption (made by the Detail View) that we display one item and  
>> one item only...
>
> Actually, even today there *are* multiple items being displayed in  
> the detail view, it's just that the user may not think of them that  
> way.  For example, each email address in the To: field of an email  
> item is a distinct item, as is the Location field of a calendar event.
>
>> Well, may be that's an assumption we need to break but moving from  
>> displaying one item to displaying one item + the graph of linked  
>> items (which can branch and nest quite deeply) is not easy. On  
>> further reflection I think I would rather see for an item a list  
>> of directly linked items and allow the user to drill down rather  
>> than have nested sections. Sort of an "item browser" so to speak  
>> with clickable links from one item to the next (and a back  
>> button...). That would solve the real estate issue and the  
>> "hierarchical" issue that your proposal has IMO...
>
> What I like about my proposal is that when all of the linked items  
> are 'collapsed' you essentially have the item list you want; if you  
> want to see more detail about a linked item you don't necessarily  
> have to leave the context you are in.   I see that I neglected to  
> include in my mock-ups some affordance for navigating to the detail  
> view of any of the linked items, but I did intend the user to be  
> able to click on a linked item and have the detail view switch to  
> that item.
>
> ~morgen
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060315/ee9ea000/attachment.htm