[Chandler-dev] Reengineering stamping

[Morgen Sagen]

On Mar 15, 2006, at 3:54 PM, Jeffrey Harris wrote:
>
> What you probably WOULD notice, though, is that moving forward  
> engineers
> would stop looking confused when something like
>
> <http://lists.osafoundation.org/pipermail/design/2006-March/ 
> 004356.html>
>
> is mentioned.  The problem here is that if the event and the book are
> the same item, I just can't imagine a reasonable way to model the same
> book "being" multiple events.  That I can't imagine it may be a  
> failure
> of imagination, or an architecture failure.

I was going to wait for the storyboard proposal is presented before  
replying anymore to this topic, but...  :-)

My confusion about the example in the email you linked to isn't  
really about how an engineer would model it or implement it under the  
hood, it's that it doesn't really show the need -- from the user's  
standpoint -- for a book to 'become' an event when you are going to  
associate *multiple* events with the book.  I mostly understand the  
goal of stamping in the one-to-one case (I turn a book into an event  
so it appears on the calendar, etc.), but it doesn't address the  
situations where we want one-to-many or many-to-many relationships  
between items, like multiple emails about a book.  As for that linked- 
to example, aside from the fact that it would be unwieldy to create  
such a series of recurring events, the book can 'become multiple  
events' *only* because calendar events happen to have the notion of  
recurrence.  If you wanted to turn a book into a single task ('Read  
this book by Thursday'), that's one thing, but how could you turn it  
into two tasks ('Buy this book', 'Read this book by Thursday')?  I'm  
hoping the storyboard proposal will show how this would be  
accomplished in the UI.

Thanks,
~morgen

P.S.  I think this a very important discussion as it really defines  
what 'Chandler-ness' is.