I think the issue is whether to:
1. Place the burden of differentiating between marginalia and
original content on the software and disallow any kind of
modification to the content until the software is able to handle
differentiating between annotations and content (which is what most
email clients, except for Eudora do...They disallow users from
editing their email VERSUS
2. Allowing users to maintain in their own the difference between
annotation and content until the software is able to do it.
It's really a question of philosophy, I'm proposing that we take the
2nd approach and let users do what they want with their data, even if
it means corrupting the original content...until we are able to
provide more robust annotation functionality. We can probably learn a
lot about how to do annotations correctly, by studying how people
"annotate" their content on their own.
Another benefit to approach #2 is that it is often not clear whether
what you want to do is an annotation or an edit. For example, if we
go back to the use case where you want to add in a co-host's name to
the "From:" field of an invitation, is that annotation? or an edit?
It depends on whether you care about preserving the "original"
content. But why would you care "which" email account the invitation
was sent from? When you RSVPed, wouldn't you want to RSVP to both? Or
maybe you do care, but the reason "why" you should care isn't
apparent to you at the time of the edit.
For example, later on, I realize that the invitation was sent from an
evite account and that your host would really prefer that you RSVPed
just to the original email account.
The basic point being, if we study the various "end states" of
content, we can definitely say that there are two kinds of content
modifications: annotations and edits. However, if we look at the
issue from a workflow perspective, the distinction between the two
becomes less clear and the user is often "not equipped to" or
"doesn't care to" decide which kind of modification they want. They
just want to get on with the modification. (This same kind of
analysis is what led us to present collections and tags simply as two
sides of the same coin rather than offering them as fundamentally
different features...ie. folders versus categories.)
So some questions I'd like to pose to the list:
1. If you have a generic notion of "editing" the content AND
2. A generic notion of controlling how content is visually displayed
(ie. font size, face, style, color, on stickies, in marker,
highlighted, et cetera) AND
3. A generic notion of versioning...
Is there still a need for a notion of annotations that is independent
of edits and versions?
Mimi :o)
On Nov 12, 2005, at 10:22 PM, Davor Cubranic wrote:
Mimi Yin wrote:
Ted and I got into a discussion about annotations and their place
in Chandler items...
Traditionally, annotations are thought of as a separate attribute
or field on an item where users can write notes or comments. I'm
wondering if we can try a more flexible notion of annotations that
simply allows users to edit their items in any field.
Isn't annotation usually defined as attaching "marginalia" to a
document without changing the original content? To me, this
discussion is really about versioning items in the repository. I
notice that most messages in this thread actually used the term
"versioning" and "version", actually. :-)
Davor
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
