[Design] Design Session 2 on Stamping and Communications

[Philippe Bossut]

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... 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...

Creating links between items (in a UI way), displaying them and 
manipulating them is not something we have a solution for yet and 
certainly something we need to think about. Using a "browser" metaphor 
between items (as I hinted here above) is an idea. But, I digress... so 
back to 0.7...

Quite clearly, no one was saying that stamping would solve all the 
scheduling issues. We collectively raised a bunch of scenarios where 
stamping will break down and Mimi's proposal (see the bottom diagram of 
http://wiki.osafoundation.org/bin/view/Journal/NotesDSStampingComm) is a 
mix of stamping and email threads: stamping to carry all the info for an 
event in one item (and not breaking the current DV assumption) and email 
threads for all the communication chatter, viewable via the Summary 
Table View. It's not the end all solution for the problem but a good 
first approximation for 0.7, isn't it? I think that was the question on 
the table today.

One thing on stamping that Mimi said today and created an "Aha!" moment 
in my brain is that stamping is like flagging. Stamping is more powerful 
in the sense that, while a flag has no semantic beyond the one you want 
to give it by convention, stamping carries the whole semantic of this 
other kind you are stamping with with it. It's a cool idea, right in the 
line of the "peeling the onion" metaphor of Mimi (i.e. add a little info 
one bit at a time while you nibble at an item over time). That being 
said, it has the same limitation than flagging since it ties stuff 
together in a unique thicket that has none of the powerful semantic 
capability of representation that a topology of links has. Stamping is a 
sort of first order extension with none of the management complexity 
(for users) of links, but none of the link topology power either. I 
think we established that during the discussion today (or may be I'm 
extrapolating too much, am I?)

The question is: can we use stamping in 0.7 to reach a good enough 
scheduling feature, something usable (with limits) in the short term?

After today's meeting, I'd say "yes" though I can see how users are 
going to bump into the limitations pretty fast.

What are others thinking?

Cheers,
- Philippe