[Design] Stamping design issues

[Mimi Yin]

As a follow-up to the Design Session 3 on Stamping and  
Communications: http://wiki.osafoundation.org/bin/view/Journal/ 
StampingStoryboards

I've been tasked with replying to Alec's question write-up from 3  
weeks ago. The answers below are not set in stone. Instead, this is  
simply a way to jump-start a discussion to work out implementation  
issues and design details.

:o) Mimi

On Mar 15, 2006, at 5:31 PM, Alec Flett wrote:

> [and this one is design and implementation questions]
>
> Mimi Yin wrote:
>>
>> Re: The example: Your wife comes to OSAF to watch the Cane Toads  
>> movie doesn't mean that she becomes you. I'm not sure that that's  
>> an apt analogy for stamping.
>>
> hehe. It was more an illustration of the difference between  
> "identity" relationships and "an item of one kind appearing in the  
> context of items of another kind" - i.e. just because the data from  
> an e-mail message shows up in my task list doesn't require that the  
> e-mail message itself be the task. Perhaps it's just tightly  
> coupled to a thing you need to do.
>
> We can certainly present it to the user as the "same thing" but it  
> seems like many folks are still on the fence about the actual  
> identity issue. I'm hearing lots of questions like:
>
> - If I delete an e-mail message stamped as a task from my task  
> list, does that delete the original e-mail message itself (the one  
> that was originally recieved), or just "unstamp" it as a task and  
> leave it as an e-mail message? Can I leave the "task" part in the  
> trash and keep the e-mail part around?

Delete = Delete the whole item. Stamps and all :o) See comments about  
un-Stamping below.

> - when I "unstamp" something am I breaking identity by destroying  
> one facet of the item, or are they being split off into two items?  
> If we're destroying, where does that data go? Can it be restored?  
> If its being split off, where does the other half go? the trash?

*Ideally*, when you unstamp and re-stamp, you don't lose any data.  
However, stamping is not bringing together 2 items. It really is the  
ONE item. For example, if you have a Task, which right now consists  
of a Body and a Title. And you put it on the Calendar, which adds  
date/time fields. If you were to split the Task from the Event, who  
would get the Body and the Title? Would the Event just be date/time  
fields with not Title or Body? Treating Stamping as 2 separate items  
joined at the hip presents a whole host of problems like that:

1. If something is stamped as 3 things (Message/Task/Event) and un- 
Stamp 1 of them (Task), how does the item split? (Message/Event +  
Task, Message/Event + Message/Task)?

2. If I tag or add user-defined attributes to a stamped items, how do  
those attributes get split between the Stamps? (ie. I add an Owner  
attribute to a Task/Message). Does the Owner attribute get applied to  
both items? Or just to the Task? How do I specify which item? What if  
there are 3 or more Stamps? Can you apply tags and user-defined  
attributes to 2 out of the 3 Stamps?

3. If I have an Message/Task and I added a bunch of text to the Body  
field, do those edits apply to the Message as annotations" or to the  
Task or to both if I take the item off the Task list?

> - when something is "stamped" vs "tightly coupled" is there an easy  
> transition between these two? i.e. if the user has to make a choice  
> between "Stamping" and "tightly coupling" what happens if they want  
> to 'spin off' the taskness of an event into a whole separate item?  
> Do they unstamp (potentially losing information?) and then "tightly  
> couple" or is there a smooth demotion?

Again, Stamping needs to be thought of as 1 item in multiple  
contexts, rather than multiple items tightly joined. If I receive a  
Message and I put it on the Tasklist, it's just an Message I've  
flagged. I can always un-Stamp the Message and take it off the Task  
list. I can also create new Task items that are either directly  
linked off the Message item or Embedded inside the Body of the  
Message. For more, see: http://wiki.osafoundation.org/bin/view/ 
Journal/StampingStoryboards#RelationshipTypes

If I've edited the Message on my Task list, I can always go view the  
original Message that was sent to me, which is preserved as a Retired  
'Version' of the item.

> - If I sent a mail message to 3 people, stamp it as a calendar item  
> and add 2 more people, where is the original e-mail message that I  
> sent to the first 3 people? Is it visible/searchable/etc?

It's in the thread as a previous 'Version' of the item. The Calendar  
stamp is treated as an Edit/Update.

> - If my e-mail comes in with the subject "Re: [Chandler-dev]  
> sections oddity" and I put it on my task list, can I give it my own  
> Task title like "File a bug against alecf for this problem" or does  
> it show up in my task list as "Re: [Chandler-dev] sections oddity"?

You can either:
1. Have it show up as "Re: [Chandler-dev] sections oddity". This is  
how it works for people who Flag email today.
2. You could pre-pend that Subject line with: File bug
3. You could add File bug... to the Body of the Message.
4. You could add a user-defined attribute to the store the Task  
description
5. You could customize the Task Kind to include a separate Task  
description attribute (not currently slated for 1.0)
6. You could create a separate Task item: File bug... and link it to  
the original Message item in the various ways described in: http:// 
wiki.osafoundation.org/bin/view/Journal/ 
StampingStoryboards#RelationshipTypes

> - If the title is shared and I've edited it to be "File a bug  
> against alecf for this problem" then what does it look like in my e- 
> mail collection, grouped with other messages with the same original  
> subject?

It says: File bug... That way, you can differentiate the messages in  
the thread...Right now, you have to hunt through each message in the  
thread to find the one that you had to file a bug about.

Re: [Chandler-dev] sections oddity
File bug. Re: [Chandler-dev] sections oddity
Re: [Chandler-dev] sections oddity
Re: [Chandler-dev] sections oddity


> - If the title is not shared, what does the detail view look like?

The title is shared.

> - What if two people stamp the same, shared event as a Task because  
> they each have items to prepare for the meeting and then sync.. is  
> the "taskness" now merged between the two?  If the 'task' on each  
> person's personal chandler is different, but the event is the same,  
> does identity still hold?

So you could imagine this scenario playing out in several ways:

Priscilla and Mimi are both tasked with coming up with the next  
Design Session's agenda. So the PPD team sees that this Meeting is  
stamped as a Task and the Task is assigned To: Mimi, Priscilla  
(Here's another example of how keeping From: and To: flexible allows  
people to use it in different ways).

Bear and Mimi have different reasons for putting the Meeting on their  
Task lists. Mimi needs to write up follow-up questions. Bear wants to  
read the meeting notes.

+ If we have a notion of allowing users to decide what's shared and  
what's not shared, Bear and Mimi could privately put the Meeting on  
their respective personal task lists. And add private annotations  
about what we each need to do with this Meeting item. (/private  
feature described here: http://wiki.osafoundation.org/bin/view/ 
Journal/StampingStoryboards#StampingWorkflow).

This feature is more important for larger group collaboration (ie.  
Design list mgmt with Chandler) and less important for small  
workgroup collaboration (ie. PPD, Household tasks).

+ OR Bear and Mimi each create related Task items (Linked, Embedded,  
Threaded).

> i.e.
> if on my machine "Event 42" = "Task 1" and on your machine "Event  
> 42" = "Task 99" and we sync, does "Task 1" = "Task 99"?
>
> Anyway, not that we can really answer all of these today, but these  
> are not implementation details - these are design issues that seem  
> really big and scary, and will influence how we do end up  
> implementing "stamping"...
>
> Alec
>
> Not that these all have to be addressed immediately
>> A closer analogy might be: Put Alec in the OSAF setting and he has  
>> his Engineer hat on. Put Alec in the Home setting and he has his  
>> Dad hat on. Alec the Engineer and Alec the Dad are both the same  
>> person and changing settings doesn't obliterate the other part of  
>> who you are (eg You work from Home, you bring Holden in for Movie  
>> night). But in different settings, Alec "represents" or "is"  
>> different things. (Sorry don't mean to pick on you ;o)
>>
>> Similarly, you might receive an Email that says: Blahblahblah,  
>> help me!. In the Communications context, it is a Message. But you  
>> might also want this piece of information to show in your Task  
>> list context...and in that context it's Task. The information item  
>> however is 1 thing and just because it's a Message doesn't  
>> obliterate the fact that it's a Task as well.
>>
>> Mimi :o)
>>
>> On Mar 15, 2006, at 4:02 PM, Alec Flett wrote:
>>
>>> [resending this - for some reason it didn't make it to the  
>>> mailing lists the first time..]
>>>
>>> Mimi Yin wrote:
>>>> Hi Jeffrey,
>>>>
>>>> Thank you for writing this up.
>>>> Let me try to re-phrase what you just wrote in design terms and  
>>>> see if we're still on the same page:
>>>>
>>> I think part of the issue is that there are key differences  
>>> between the
>>> design and implementation of these relationships - from my  
>>> perspective,
>>> what jeffrey described is the domain model relationships and how  
>>> they
>>> might affect the implementation of the UI, and what you've  
>>> described is
>>> more about the design relationships and how you would design the  
>>> UI to
>>> model them.
>>>
>>> (and I think threads are orthogonal to the implementation details  
>>> that
>>> Jeffrey is trying to work out)
>>>> I get 1(Identiy coupling) and 3 (Loose coupling), I see the  
>>>> point of 2, though I'm not sure we need to address this use case  
>>>> in the short-term. But I think there's a missing relationship  
>>>> type: Threads.
>>>>
>>>
>>> At the moment, we've tightly matched the design relationships (i.e.
>>> "stamping") all the way down through the domain model (i.e. so
>>> "stamping" == "identity") and I think that is why there has been  
>>> so much
>>> resistance to stamping from those implementing it. The  
>>> implementation of
>>> stamping-as-kind-morphing has caused us some serious headaches  
>>> and the
>>> 0.7+ plans are looking even worse as long as we continue with our
>>> current implementation. I'm sure it made sense at the time, but I  
>>> think
>>> the design of the product has become more concrete and it doesn't  
>>> make
>>> sense anymore.
>>>
>>> In my mind, the crux of the matter is whether identity coupling  
>>> is truly
>>> necessary all the way down in the domain model.
>>>
>>>> 1. Identity coupling as you said is a 1-1 coupling. So this to  
>>>> me would be like: Putting an email on the Task list. Putting a  
>>>> Task on the Calendar. What we call Stamping today.
>>>>
>>> I think Jeffrey is using "identity" in the mathematical sense -  
>>> that it
>>> isn't just a 1:1 mapping, but that the two objects are actually  
>>> the same
>>> object.
>>>
>>> For instance, my work self and my home self are really the same  
>>> "Alec"
>>>
>>> I think its interesting that you interpreted this as meaning  
>>> putting an
>>> object of one type on the list of another type, because I see  
>>> that as
>>> being orthogonal to the notion of identity, though I think it is an
>>> important aspect of the design and appearance to the user. For  
>>> instance,
>>> if my wife comes to my work to watch a toad movie, this doesn't  
>>> imply
>>> that she IS me, but we are clearly tightly linked...
>>>
>>> If the intent of the design is to make it look like, for example, a
>>> calendar event is on my task list, there are other ways to implement
>>> that beyond the identity mapping that we currently do.
>>>
>>> I think frankly, it would behoove us to separate out the design  
>>> notion
>>> of an "Item" from the implementation notion of an "Item" because  
>>> when
>>> you (Mimi) say "An Item should have these properties and behave this
>>> way" we're trying to match that too exactly in the domain model.  
>>> (though
>>> there is some irony that many people correctly point out that a  
>>> "design
>>> Item" is usually composed of many "implementation Items")
>>>
>>>> 2. Tight coupling is having more than 2 items in the same Kind  
>>>> branch stamped with a 3rd (ie. 2 Spec proposals are the combined  
>>>> Agenda for a Meeting, so you would want to put both on the  
>>>> calendar for the same Meeting). So you might multi-select 2 Spec- 
>>>> items in the Summary table view and Stamp them both to "Put on  
>>>> the calendar".
>>>>
>>> No, tight coupling just describes the relationship between two  
>>> "items"
>>> -  it by no means describes the number of items involved. Being  
>>> tightly
>>> coupled to my wife does not imply that there are three of us. :)
>>>
>>> However even if we share a bank account, and mail from our bank  
>>> comes
>>> addressed to both of us at one physical address, the bank still has
>>> separate internal records for each of us with our respective social
>>> security numbers and credit history. When I call to look at our  
>>> account
>>> and give my identity information, the representative probably  
>>> sees our
>>> account, with both of our identity information on the screen at  
>>> once.
>>>> 3. Loose coupling is simply having attributes on an item point  
>>>> to another item. ie. Jeffrey in the To: field points to a  
>>>> Contacts item for Jeffrey Harris.
>>>>
>>> In the design sense, this is absolutely true. In the implementation,
>>> there is little or no distinction between Tight and Loose coupling
>>> besides perhaps the name of an attribute (for instance, tightly  
>>> coupled
>>> items may simply be related because their "tightlyCoupled"  
>>> attributes
>>> point to one another and loosely coupled items use "looselyCoupled")
>>>
>>> [and yes, those are terrible names.. and that may not even be the
>>> "right" way to implement it]
>>>
>>> If my friend gave me a gift subscription to a magazine he also
>>> subscribes to, then the publisher probably knows that we are somehow
>>> connected and will probably remind my friend next year to renew  
>>> his gift
>>> subscription.. but we are by all intents and purposes separate  
>>> customers.
>>>
>>> I guess I could debate semantics forever and come up with more
>>> analogies, but ultimately I think we need to loosen the tie  
>>> between the
>>> user's mental model and our domain model - they are not the same  
>>> thing,
>>> and by tying them too tightly together we're limiting the scope  
>>> of what
>>> chandler can really do.
>>>
>>> Alec
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "chandler-dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/20060405/954d2631/attachment.htm