[Design] [Sum] Reengineering stamping

[Sheila Mooney]

Thread: Reengineering stamping

Things we are hearing from this thread:
+ there are these different types of coupling that we could use for  
our implementation model
+ we should try and loosen the tie between the user's mental model  
and the domain model.
+ by tying them too tightly together we continue to block on issues  
and we should be considering the best implementation for the desired  
user experience
+ there is still a lack of understanding on how we will solve the one- 
to-many and many-to-many relationship

Jeffrey:
+ sent out his thoughts to the dev list on stamping
http://lists.osafoundation.org/pipermail/chandler-dev/2006-March/ 
005479.html
+ introduced 3 concepts: identity coupling, tight coupling and loose  
coupling
+ identity coupling
	+ what stamping is today
	+ an email is also an event
	+ forces a 1:1 relationship between kinds
	+ able to share attributes easily
+ tight coupling
	+ a connection between 2 items
	+ when user displays email A, they also see item B
	+ Mimi would like to have users experience tight coupling but it  
doesn't have to be identity coupling
+ loose coupling
	+ link between 2 items (anchor tag on an html page)

Mimi:
+ replied to the design list and tried to rephrase Jeffrey's summary  
in design terms
+ identity coupling - 1:1 coupling, putting an email on the task list
+ tight coupling - having more than 2 items in the same Kind branch  
stamped with a 3rd (the meeting agenda is 2 spec proposals) You could  
multi-select 2 items and stamp them.
+ loose coupling - having attributes point to one another
+ Mimi pointed out there is yet a 4th kind of relationship - the  
thread relationship which has been described in the past as clusters

Jeffrey:

+ agrees with Mimi's description but wanted to point out that it's  
more of an implementation detail on whether stamping uses identity or  
tight coupling.
+ the design team should never notice this since we can make the  
experience to be like identify coupling but still allow for the  
ability to couple multiple items.
+ the issue at an implementation perspective is how to model the same  
item being multiple events
+ this still doesn't address the issue of shared attributes but the  
goal of the conversation move the apps team towards thinking that we  
can reengineer stamping and we don't have to stick with the existing  
implementation.
+ specifically avoided talking about clusters since he felt they  
mainly affected the rendering in the summary table view and would  
like to have this discussion on a separate thread from coupling/stamping

Alec:
+ points out that ...
+ Mimi is describing the design relationships and how those would be  
represented to the user
+ Jeffrey is describing the domain model relationships
+ we've tightly matched the design relationships (i.e."stamping") all  
the way down through the domain model (i.e. so "stamping" == "identity")
+ this implementation is not quite working anymore
+ the big question = is identity coupling necessary all the way down  
to the domain model
+ in response to Mimi's summary
	+ identity coupling isn't just a 1:1 mapping - it's the same item  
(alec at work and alec at home are the same alec)
	+ tight coupling describes the relationship between 2 items, it  
doesn't describe the number of items involved
	+ loose coupling - at the design sense this has meaning but at an  
implementation perspective there is no distinction between tight and  
loose coupling

Mimi:
+ only concern about a linking implementation model is whether or not  
it will make it more complicated to overlap attributes
+ this means, how do we change the context of the fields without  
creating new ones
+ ie: an email is stamped as a task and the to: field becomes  
assigned to:

Alec:
+ people are still on the fence about the identity issue
+ in my opinion there are a number of open design questions
	+ 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"?

Mimi:
+ most of these questions have already been answered over the past 2  
years but are not well documented
+ Mimi will try and address most of these with the storyboards she  
and Katie are working on rather than replying in detail to this email

Morgen:
+ is waiting for the storyboards but has one comment
+ feels that Mimi's example referenced in http:// 
lists.osafoundation.org/pipermail/design/2006-March/004356.html  
doesn't show a need from a user's standpoint
+ doesn't quite get the associating multiple events to a book case -  
understands the goal of stamping in the 1:1 case.
+ he still feels it doesn't address the one to many and many to many  
relationship
+ thinks the recurrence model is unwieldy and only works for events
+ how would you turn a book into multiple tasks
+ is hoping the storyboard will show how this is accomplished in the UI

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060403/32b7e4c2/attachment.html