[Chandler-dev] stamping design issues

Alec Flett alecf at osafoundation.org
Wed Mar 15 17:31:31 PST 2006


[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?
- 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?
- 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?
- 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?
- 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"?
- 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?
- If the title is not shared, what does the detail view look like?
- 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?
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
>

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


More information about the chandler-dev mailing list