[Design] Conceptual model for "stamping" (Modified by Mimi Yin)

[Lisa Dusseault]

Thanks Mimi, this page is great.  It filled in a lot of history and 
some concepts that I, too, was missing.

Lisa

On Jan 21, 2005, at 3:21 PM, Mimi Yin wrote:

> Apologies, there was a typo in the URL, the correct one is:
>
> http://wiki.osafoundation.org/bin/view/Journal/StampingRevisited
>
> =====
> I'm going to stay out of the discussion about how the user's mental 
> model of stamping is actually implemented, but I'm going to try to 
> throw in yet another "from the user's perspective" explanation of 
> stamping in the context of extensibility in the hopes that it might 
> clarify things a bit.
>
> http://wiki.osafoundation.org/bin/view/Journal/StampingRevisted
>
> Again, I don't think this changes requirements for implementation. If 
> anything I think it reinforces our original thinking which is that 
> Stamping Kinds or Mixin Kinds, which I actually call Action Kinds on 
> the wiki page are a limited set and non-Mixin Kinds (aka Object Kinds) 
> will be far more prevalent. But perhaps both should be extensible, at 
> least in an ideal world.
>
> Mimi
>
>
> On Jan 21, 2005, at 12:09 PM, Phillip J. Eby wrote:
>
>> At 10:58 AM 1/21/05 -0800, Donn Denman wrote:
>>> In the multiple-items model, when you do a search for "Bob's 
>>> Wedding", you expect to see three items:
>>
>> This depends a lot on what an "item" is.  Part of what I'm suggesting 
>> is that the things that go on a calendar or task list might not 
>> necessarily be "items" in the sense that you're saying.  For example, 
>> in Ecco, date field values are what go on the calendar; they're not 
>> independent "items".
>>
>> So, it's possible to preserve a user model of single "item" without 
>> necessarily having single "objects" in the implementation.  Make 
>> sense?
>>
>>
>>> In the one-item model, when you do a search for "Bob's Wedding" you 
>>> only find one item as the result.  It's a single item which can 
>>> appear in several different places: in your mail box, in your task 
>>> list and on your calendar.
>>
>> Right; I'm suggesting that those *appearances* may be more cleanly 
>> modeled using separate objects in the implementation.
>>
>> Or to put it another way, a "user-visible content item" may be 
>> composed of more than one "repositority item" or "content API item".
>>
>>
>>> Can you make one model look like the other?  Sure, but you start 
>>> running into problems.  For instance in the multi-item model you can 
>>> chose to present all three items in a single view, so you see 
>>> exactly the same thing when you click on the Task as when you select 
>>> the calendar Event.  But this can confuse the user into thinking 
>>> there's only one item, when they really are three independent pieces 
>>> of information.
>>
>> I'm not entirely clear what you mean here, but that's probably 
>> because I am working from a model that isn't "multi-item" in the same 
>> way you're saying here.
>>
>> The problems that you experienced previously (if I understand them 
>> correctly) are a result of not *dividing* the responsibility between 
>> objects, but instead having overlapping responsibilities where more 
>> than one object had responsibility for a given item of data.
>>
>>
>>> Given a requirement to build the one-item stamping model, I think 
>>> morph-stamping works much better than link-stamping.  If you have 
>>> multiple-items at the Data Model level, it's going to be hard to 
>>> keep that from showing up at the Content Model level, and to the 
>>> user.
>>
>> Only if you require all repository content to be user-visible, and I 
>> don't think that's currently an issue.  An entry on a calendar need 
>> not be the same thing as an item of kind "Event".  Rather, an Event 
>> would be a titled item that has an attribute referencing a calendar 
>> entry.  The calendar entry object encapsulates calendaring behavior; 
>> the Event represents the entry as a content item.
>>
>> So, to implement a one-item stamping model with delegation, you 
>> simply have a "Note" type that has attributes for calendar entries, 
>> task entries, and transmission history.  These "entries" are *not* 
>> content items and have no title or body or anything of their own.  
>> They're just "entries" on the relevant lists that represent "putting" 
>> the original "item" on those lists.  The "Note" contains the actual 
>> content.
>>
>> In this model, there is no changing of types between the N/E/T/M 
>> types, because there is only one actual type!  Everything else is 
>> just a stub referencing the Note that contains all the shared 
>> information.
>>
>> If you search for "Bob's Wedding", you would only find one item - the 
>> note - because it's the only item that has any text for you to search 
>> on.
>>
>>
>>>> Then, as Mimi suggested, it isn't actually necessary to morph 
>>>> anything in order to accomplish the desired model; stamping is just 
>>>> adding a new item.
>>> Well this sounds like the multi-item user model!  Have we been 
>>> implementing the wrong user model?
>>
>> I didn't say that, and neither did she.  She said:
>>
>> """
>> In short, is it possible that we want to model Email-ness and 
>> Taskness as
>> attributes and only have Notes and Events as Kinds?
>>
>> I'm not sure what kind of a mess this creates for other parts of the
>> application, but it answers some of these questions about stamping and
>> extensibility (as new Kinds are introduced to Chandler) in a tidy way.
>> """
>>
>> Which sounds like opening up a question for further thought, not 
>> rejecting the previous model or definitely choosing a new one.
>>
>> All I'm taking from her email is that arbitrary combinations of 
>> arbitrary kinds isn't a requirement, or expected to be one.
>>
>> That is, that morphing is something specific to the 
>> email/task/event-ness of an item, and that items in general need to 
>> be added to a calendar or to-do list, and sent or received via email.
>>
>> These four capabilities (add to calendar, add to todo, send, receive) 
>> are therefore common characteristics of a "user content item"; which 
>> does not necessarily imply that distinct user-visible kinds are 
>> needed just to model those abilities.
>>
>> In other words, there's no need for "Events", just notes you can put 
>> on the calendar.  No need for "Tasks", just notes you can put on the 
>> to-do list.  No need for "Email", just notes that come and go by 
>> email.  This is, as I understand it, much closer to the single-item 
>> morphing model, and it's easier to say to someone "you can write down 
>> your thoughts and then put them on your calendar, to-do list, or send 
>> them out to people, or all three" than it is to say "you can write a 
>> note, and then you can change your mind and make it a calendar event 
>> and an e-mail."
>>
>> Or, to put it another way, putting your notes on a to-do list or 
>> mailing them out are actual user goals, but the ideas of morphing and 
>> even "stamping" are concepts about *how* they might achieve that 
>> goal.
>>
>> What's more, in the presence of other content types, it becomes more 
>> complex to explain how photos and blog entries "become" tasks while 
>> still being a photo or blog entry.  In fact, it's pure doubletalk 
>> when compared to just saying, "anything in Chandler can be put on 
>> your calendar or to-do list, or e-mailed".  Talking about changing 
>> kinds is just a distraction from the simple and uncontroversial idea 
>> of putting something on a list or calendar, or mailing it to 
>> somebody.
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design