[Design] Design Session 2 on Stamping and Communications

[Bryan Stearns]

Mimi, I don't think this example is a "recurrence" use case - it's 
really an example where some form of tagging should relate what really 
are disparate events.

The recurrence mechanism is most suited for situations where we're 
trying to present the appearance of one thing ("my weekly staff 
meeting") even though it might take several under-the-hood items exist 
to support it (the user even sees this duplicity in the "change one" / 
"change this and future" dialog). I don't think this use case fits that: 
I don't see a change that the user would want to apply to all these 
events once they're related (other than correcting a spelling error in 
the book title, but that begs linkage to a 'book' item anyway).

...Bryan

Mimi Yin wrote:

> 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
>
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>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/20060316/479e4108/attachment.html