Philippe Bossut wrote:
Hi,
I thought that Chandler's repository has internally a versioning system
(a la CVS) for each item (I was talking about that with Andi a couple
of days ago, can't remember though if it's something he did or planned
to do...). Without going into the UI aspect of things, wouldn't that be
something we could leverage to provide edit versioning?
Yeah, that's true. I guess one difficulty I see with using the
repository is that you'd be looking at versioning just within your
repository, in between local commits - so if you shared it, and it was
edited by other people 3 times before you synced, then the "diff" would
show all 3 of those - and those other people would have a different set
of changes to get to the same final item.
We could include version information along with sharing information
when we post CloudXML to cosmo, then you could "play back" the changes
within your repository, and commit in between each change so that your
repository versions match the version set you just downloaded.
If we did that, the next technical hurdle would be to sync up the
versions in the situation where:
1) I share something, say at version 5
2) I make an edit locally, it becomes a local version 6
3) Someone else makes an edit locally, and syncs back to the server, it
becomes version 6 on the server
4) A third person makes an edit locally, and syncs back to the server,
it becomes version 7 on the server
5) I sync with the server - in order to be in sync with the server,
we'd need to roll back to version 5, apply the changes from 6 and 7,
and then apply our local version 6 change, which becomes version 8, and
apply that up to the server.
Actually, I think morgen does something like this already in his
merging-with-views...
So maybe it isn't that hard. Neat.
Alec
One
simple UI trick would be to see the rev number of an item somewhere in
the Detail View and be able to navigate back. Styling the diff text
would provide a visual display "a la Word".
Cheers,
- Philippe
Alec Flett wrote:
Personally I think that annotations that
modify existing fields is bound to be very difficult to manage
on-screen, not to mention the technical hurdles that will be necessary
to show "out of band" information like edits...
The first thing that jumps to mind is Word's "track changes" mode -
which provides visual cues as to what has changed in the document...
screenshots attached. I've watched my wife use this system very
effectively to collaborate on documents. I think whats most interesting
about is that each change is remembered as a separate transaction that
you can accept in any order.. so if I make 4 changes to a document, my
collaborator can accept the 1st and 3rd of these changes without
affecting the rest.
I personally find the "normal" mode to be more helpful. It keeps the
changes themselves inline with visual cues in the front (color,
strikethrough). I find the "print layout" annotations a bit bothersome
because the annotations are callouts that are separated from the actual
changes.
I think a bug system like bugzilla is another interesting collaboration
tool.. (not always the most beautiful interface, but the concepts are
there) in particular:
1) the "comments" fields are constantly appended to the bug, each with
a timestamp so you can get at least some visual cue as to who and when
made what changes
2) the "View Bug Activity" (see
https://bugzilla.osafoundation.org/show_activity.cgi?id=3968 as an
example) shows you the history of what changed.
Some have argued that these two "lists of changes" could/should be
merged - so that in between the comments, or as a part of the comments,
you'd see which fields changed.
I think that an easy, low-cost solution here is actually something like
the "notes" field in a Note... but not as its stands right now. I've
seen wikis used effectively as a way to manage a sort of thread of
conversation within a single document, but it relies on people sharing
a set of conventions within the document.
If we could formalize conventions in the UI to allow, for instance, a
log of changes within the item itself, that could be shared and
extended by sharees, then people could collaborate on a list of
changes.
Alec
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.
*Use cases:*
1. You receive an invitation for a party from your friend Janus. The
party is actually being hosted by Janus and his wife Psyche. You'd like
the From field to reflect that.
2. You receive a draft of a proposal via email that will be the topic
of discussion for a meeting. During the meeting, you'd like to take
notes on the draft, in-place in the body of the proposal.
This is some of the motivation behind allowing users to edit their
email, even emails that have been sent and received.
*Ideally, this free-form annotation and editing is supported by:*
1. Ability to Edit and then Update the item (propagate changes to
others via email or item sharing)
2. Ability to maintain snapshots of Updates (as part of a conversation
thread) so you can look back on previous versions of the item.
So an email thread might look something like this:
*Original*: Here's a draft of the proposal...
*Reply*: Great, I'll look at it later.
*Update 1*: Here are my edits.
*Reply*: Thanks, get back to you by end of today.
*Update 2*: Incorporated your edits, I think we're close.
Etc...
For a more detailed write-up:
http://wiki.osafoundation.org/bin/view/Projects/CommunicationsDesignNew
Replies and Forwards are simply treated as separate items that are part
of the conversation thread. The original item + it's subsequent updates
are treated as versions. So if the original item was labeled: Project
Foo, then all subsequent Updates are labeled Project Foo as well,
etc...
We can continue further to imagine that annotations and edits could be
visually distinguished (ie. highlighted) so that users can distinguish
between the original text and their annotations. However, we can try
out this notion of free-form annotations in a relatively low-cost way
by pushing the burden of distinguishing between annotations and
original text onto the user for now. (ie. Place double [[ xxx ]] around
all your annotations.)
What are some other low-cost ways we can experiment with
annotations?...I can think of lots of high-cost ways (ie. floating
stickies on the detail view ;o)
Mimi
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
|
