Calling Mac Developers: Request for a Collaborative Editor

At 9:44 AM -0700 8/1/06, Adam C. Engst wrote:
>At 1:55 PM -0700 7/29/06, Wolfgang Keller wrote:
>>And there is at least one GPLed diff tool for XML files that does this,
>>available from http://www.logilab.org/projects/xmldiff
>>
>>And it's implemented in Python, which fits excellently with both Serna and
>>Subversion.
>
>We've run across a few character-level diff tools, which is great,
>since perhaps that code (which is essentially useless on its own)
>could be used in a real editor.

Perhaps there's something inherent to Subversion which obviates this
suggestions (and I'm simply not aware what that might be), but why
not specify that Subversions's diff be BBEdit's bbdiff?


[BBEdit's diff is not currently character-level, and it currently does not allow editing in the comparison window, so it's not really as useful as it might be for writers. -Adam]


--
Andrew Laurence
atlaurenuci.edu

On Aug 1, 2006, at 12:44 PM, Adam C. Engst wrote:
> I'd actually prefer to eliminate conflict resolution entirely - we
> have no need in most situations for multiple people to edit
> simultaneously. Check in/out with sequential editing is fine and is
> how most editorial groups work. I've never worked with version
> control in code, but in text, small changes can affect meaning in
> ways that make other changes completely and utterly wrong.

In that case you probably want something less like subversion and
more like any of the version systems that grew out of RCS. They are
based on the lock-modify-unlock model, which is what it sounds like
you want.


[That could work fine, then... My main goal is not reinventing the wheel such that we can actually use something sooner rather than later. -Adam]


Steve

At 9:44 AM -0700 2006/08/01, Adam C. Engst wrote:

>At 11:39 PM -0700 7/26/06, Chris Pepper wrote:
>>A lot of this stuff ends up coming down to conflict
>>resolution. Note that Subversion assumes you are doing line-by-line
>>diff with hard-wrapped paragraphs. You certainly don't have to do it
>>that way (I hard-wrap about 80% and forget about 20%, and it works
>>okay), but introducing a good character-by-character comparison
>>tool/algorithm would be a big win for a whole lot of people.
>
>I'd actually prefer to eliminate conflict resolution entirely - we
>have no need in most situations for multiple people to edit
>simultaneously. Check in/out with sequential editing is fine and is
>how most editorial groups work. I've never worked with version
>control in code, but in text, small changes can affect meaning in
>ways that make other changes completely and utterly wrong.

        You may not need conflict resolution personally, but the
back-end needs the same underlying technology (efficient
differencing) to avoid bloat, and some people want it. For TidBits &
Mac Publishing maybe not, but for a developer who would like to
produce software for more than a few hundred people, it's an
important feature to some potential users.

        Without efficient differencing between versions, 100
revisions of a 1mb (average) file would be 100mb, and disk space,
network performance, and backups would all suffer.

        rsync uses excellent binary differencing, but I don't know of
a version control system that uses the rsync algorithm or anything
else to handle non-text-based files well.

        The code is available (rsync & librsync are open source), but
it's much easier to find version control systems based on the
assumption that most things are textfiles.


>At 11:31 AM -0700 7/27/06, Stephen A. Cochran Lists wrote:

>>During any kind of merging or revision checking, online access would
>>be needed since the file itself is not storing the revision. That
>>could be a limitation, but it saves the trouble of inventing a whole
>>new document format and uses standards that already exist. The
>>question comes down to required features. Do you want to be able to
>>edit offline, or check all the previous revisions offline?
>
>I don't see significant need for access to previous revisions offline.

        I find it important when reviewing others' changes. I
typically want to review everything since *my* last change, to see
what he/they did. If I was working with a group of editors and/or a
group of writers, I'd want to see everything since the last
signed-off version, which might not be the previous version.

        Again, it's easier to ignore this feature (now, maybe
forever) than to add it later...


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

On 1 Aug 2006, at 17:44, Adam C. Engst wrote:

> Interesting concept... One problem I see is how you prevent
> simultaneous changes. With Subversion, you can have locking, but with
> a decentralized system, you're guaranteed to have conflicts.

Honestly, that seems more like a workflow problem than a versioning
problem to me. Keeping track of who's doing what to a document and
where it needs to go to next is probably best not implemented using
Subversion locking either.

That's not to say that workflow isn't a useful thing for your
collaborative editor to manage as well...

Jonathan


PS: for speed-of-setup, breadth of features and ease of use, I think
the most powerful tool I've used for collaborative work in the last
few years is Drupal <http://drupal.org>.

> [BBEdit's diff is not currently character-level, and it currently
> does not allow editing in the comparison window, so it's not really
> as useful as it might be for writers. -Adam]


BBEdit's diff allows editing in the comparison windows for me --
unless it's something specifically broken for Subversion, which I've
never used.

David

>>[BBEdit's diff is not currently character-level, and it currently
>>does not allow editing in the comparison window, so it's not really
>>as useful as it might be for writers. -Adam]
>
>BBEdit's diff allows editing in the comparison windows for me --
>unless it's something specifically broken for Subversion, which I've
>never used.

I somewhat misspoke. When you compare two documents in BBEdit, you
have to have both of them open, and you end up with a third
Differences window. You must click on a line in the Differences
window and then look at the other two to see the associated lines.
You can of course then edit in either document.

But it's clumsy beyond belief. When I want to view the changes
between two files, I want to see a single window, with the changes
showing in some sort of styled or colored mode, and to be able to
edit the document right then and there with the changes showing. A
three-window interface is just too awkward.

cheers... -Adam

--
Adam C. Engst, TidBITS Publisher <http://www.tidbits.com/adam/>
MDJ Power 25: #5 (2004), #4 (2003), #3(2002), #3(2001), #2(2000)
<acetidbits.com>

On 8/11/06 12:52, "Adam C. Engst" <acetidbits.com> wrote:

> But it's clumsy beyond belief. When I want to view the changes
> between two files, I want to see a single window, with the changes
> showing in some sort of styled or colored mode, and to be able to
> edit the document right then and there with the changes showing. A
> three-window interface is just too awkward.

That's because it's not designed for the use case you're looking at. I find
it quite handy to have the document window separate from the diff window.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 12:52 PM -0700 2006/08/11, Adam C. Engst wrote:
>>>[BBEdit's diff is not currently character-level, and it currently
>>>does not allow editing in the comparison window, so it's not really
>>>as useful as it might be for writers. -Adam]
>>
>>BBEdit's diff allows editing in the comparison windows for me --
>>unless it's something specifically broken for Subversion, which I've
>>never used.
>
>I somewhat misspoke. When you compare two documents in BBEdit, you
>have to have both of them open, and you end up with a third
>Differences window. You must click on a line in the Differences
>window and then look at the other two to see the associated lines.
>You can of course then edit in either document.
>
>But it's clumsy beyond belief. When I want to view the changes
>between two files, I want to see a single window, with the changes
>showing in some sort of styled or colored mode, and to be able to
>edit the document right then and there with the changes showing. A
>three-window interface is just too awkward.

Adam,

        Most of the time you want either version -- it's unusual to
look at two ways of writing something, decide both of them stick, and
write a third. Not rare, but much less common than taking either of
the existing versions.

        Scrolling down through the differences window and clicking
the left or right arrow is pretty easy. In the case where you have to
type because neither alternative is suitable, you have to switch
to/from one of the document windows, which is suboptimal.


        Breakdowns occur when you do something unexpected -- such as
edit directly in either of the compared versions, changing line
count; make changes bottom-up; apply a change twice -- and then you
have to re-run the diff. There's a button between the left and right
arrows to do this.

        Unfortunately, if you've already reviewed a bunch of
discrepancies without reconciling all of them, you may end up
re-reviewing the same changes until you get back the point where
BBEdit got confused, and then resume productive comparison. This is a
flaw in implementation.


        Additionally, comparing by "line" (paragraph) instead of
character means it's hard to tell what changed in soft-wrapped
paragraphs or if line wrapping has changed. This is a fundamental
flaw of comparison by line.


                                                        Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>

At 12:52 PM -0700 8/11/06, Adam C. Engst wrote:

>I somewhat misspoke. When you compare two documents in BBEdit, you
>have to have both of them open, and you end up with a third
>Differences window. You must click on a line in the Differences
>window and then look at the other two to see the associated lines.
>You can of course then edit in either document.
>
>But it's clumsy beyond belief. When I want to view the changes
>between two files, I want to see a single window, with the changes
>showing in some sort of styled or colored mode, and to be able to
>edit the document right then and there with the changes showing. A
>three-window interface is just too awkward.

To this day I still find the old CodeWarrior 8, "Compare Files"
feature to be the very best diff I have every used. One window, two
scrolling panes, colors, insertion highlights, etc.

I wish Xcode would implement something similar. Is there a way to
write Xcode plugins that could allow this from the Tools submenu?

-m

Adam wrote about BBEdit's document comparison facility:

>But it's clumsy beyond belief. When I want to view the changes
>between two files, I want to see a single window, with the changes
>showing in some sort of styled or colored mode, and to be able to
>edit the document right then and there with the changes showing. A
>three-window interface is just too awkward.

It's a matter of both purpose and preference. For your purposes,
it's apparently not helpful. For my purposes, it's fantastically
easy to see the differences and to decide which version of each
difference to keep and which to discard. In the relatively rare
cases where I want to merge the two versions of a difference into
something else, it's quite easy to edit in either of the file windows
(as someone else has pointed out).

Incidentally, it's not necessary to "open" both files before
comparing. BBEdit's comparison facility remembers the last files
compared, and provides easy navigation to recently-open files and
others, independently for both sides of the comparison.

Carl

On 8/12/06 Adam wrote:

>> But it's clumsy beyond belief. When I want to view the changes
>> between two files, I want to see a single window, with the changes
>> showing in some sort of styled or colored mode, and to be able to
>> edit the document right then and there with the changes showing. A
>> three-window interface is just too awkward.

Sounds like Microsoft Word's Compare Documents feature, which is part of its
"track changes" menu. I use this a lot, and do collaborative writing with
one or two other writers and editors. It even identifies the author of the
changes, and track multiple sets of changes. Of course we have to mail the
Word files back and forth...
--
<watson.allencomcast.net>
Scripts for OE and Entourage:
<http://homepage.mac.com/allen_a_watson/AppleScripts_For_You>
Entourage questions: <http://www.entourage.mvps.org/>

>>> [BBEdit's diff is not currently character-level, and it currently
>>> does not allow editing in the comparison window, so it's not really
>>> as useful as it might be for writers. -Adam]
>>
>> BBEdit's diff allows editing in the comparison windows for me --
>> unless it's something specifically broken for Subversion, which I've
>> never used.
>
> I somewhat misspoke. When you compare two documents in BBEdit, you
> have to have both of them open, and you end up with a third
> Differences window. You must click on a line in the Differences
> window and then look at the other two to see the associated lines.
> You can of course then edit in either document.

Well, I'm sorry to mention the unspeakable...

but, wouldn't Word do what you want? You can apply a color to text written
by a certain person, you can set character format to "crossed out", so every
change is at once apparent in the document...

Udo

> > I somewhat misspoke. When you compare two documents in BBEdit, you
>> have to have both of them open, and you end up with a third
>> Differences window. You must click on a line in the Differences
>> window and then look at the other two to see the associated lines.
>> You can of course then edit in either document.
>
>Well, I'm sorry to mention the unspeakable...
>
>but, wouldn't Word do what you want? You can apply a color to text written
>by a certain person, you can set character format to "crossed out", so every
>change is at once apparent in the document...

Yes, Word's interface for displaying changes - in this particular
respect - is definitely close to what we want. But as I've said many
times, although Word is by far the best at change tracking and the
like, that doesn't mean it's good for collaborative editing. It's
not. We use it every day, and hate it.

cheers... -Adam

Udo Huth wrote:

>Well, I'm sorry to mention the unspeakable...
>
>but, wouldn't Word do what you want?

Allen Watson wrote:
>Sounds like Microsoft Word's Compare Documents feature


...and this brings us back to where we began the conversation.
Namely, that we currently do use Word, but find its implementation to
be buggy, ugly, and generally not what we want out of such a product.
It is true that right now Word is about all that exists to do this
sort of thing -- but it's really not good enough.

If Word had better collaboration tools this article wouldn't exist! :-)

-jason
--
Jason Snell / VP and Editorial Director, Macworld / jsnellmacworld.com
415-243-3565 / AIM/iChat: MW jsnell

> Sounds like Microsoft Word's Compare Documents feature, which is part of its
> "track changes" menu.

Due to the utter ignorance of my boss, I had to use this crap in my last job
for years, for (collaborative) editing of project reports.

And, obviously, it has proven to be completely unusable for the task.

The most important reason being that it does not allow to exchange
_structured_ documents so that the merging and formatting process can be done
semi-automatically, so that the authors can concentrate on the _content_ of
their documents. In fact it was considered as "normal" by all my collegues
(except me, as I knew better from experience with other document processing
tools - but noone asked me obviously) to loose more time on formatting tasks
than we could spend on the content.

That's why I''m looking for an XML-based toolchain now which allows to
_enforce_ a given structure for contributd documents. And to fully automate
formatting.

Sincerely,

Wolfgang Keller

--
My email-address is correct.
Do NOT remove ".nospam" to reply.

On 8/14/06 11:33 PM, "Jason Snell" <jsnellmacworld.com> wrote:

>
> If Word had better collaboration tools this article wouldn't exist! :-)
>
> -jason
> --
Maybe the next version of Mac Office will hold out some hope. Not that I
know anything (I don't), but it seems like a reasonable possible
enhancement.

--
<watson.allencomcast.net>
Scripts for OE and Entourage:
<http://homepage.mac.com/allen_a_watson/AppleScripts_For_You>
Entourage questions: <http://www.entourage.mvps.org/>

>At 12:52 PM -0700 2006/08/11, Adam C. Engst wrote:
>>>>[BBEdit's diff is not currently character-level, and it currently
>>>>does not allow editing in the comparison window, so it's not really
>>>>as useful as it might be for writers. -Adam]
>>>
>>>BBEdit's diff allows editing in the comparison windows for me --
>>>unless it's something specifically broken for Subversion, which I've
>>>never used.
>>
>>I somewhat misspoke. When you compare two documents in BBEdit, you
>>have to have both of them open, and you end up with a third
>>Differences window. You must click on a line in the Differences
>>window and then look at the other two to see the associated lines.
>>You can of course then edit in either document.
>>
>>But it's clumsy beyond belief. When I want to view the changes
>>between two files, I want to see a single window, with the changes
>>showing in some sort of styled or colored mode, and to be able to
>>edit the document right then and there with the changes showing. A
>>three-window interface is just too awkward.
>
>Adam,
>
> Most of the time you want either version -- it's unusual to
>look at two ways of writing something, decide both of them stick, and
>write a third. Not rare, but much less common than taking either of
>the existing versions.

Perhaps with code, but with prose text I mostly want to see the
current version, with changes from previous versions marked. Anything
that forces me to compare visually between two windows or panes is
too much work and will be used only in dire circumstances.

> Scrolling down through the differences window and clicking
>the left or right arrow is pretty easy. In the case where you have to
>type because neither alternative is suitable, you have to switch
>to/from one of the document windows, which is suboptimal.

I just did this in an article. I had to read each paragraph closely
to figure out what had changed, and in one case, I never figured it
out. It's a useless interface for prose text. I fully realize that
BBEdit is not aimed at writers, but I'm pointing out that its current
interface simply won't work well in that situation and shouldn't be
held up as an example of what would.

cheers... -Adam

--
Adam C. Engst, TidBITS Publisher <http://www.tidbits.com/adam/>

Today I happened to come across http://www.e-texteditor.com/

If this is close to what the TidBITS editors are looking for, maybe you could
convince the author to port it to Mac OS. The GUI is implemented with
wxwidgets, so in principle it should not take too much effort.


[Looks interesting - we'll have to check it out in Parallels Desktop. -Adam]


Sincerely,

Wolfgang Keller

--
My email-address is correct.
Do NOT remove ".nospam" to reply.

Wolfgang Keller said:

>If this is close to what the TidBITS editors are looking for...


Forgive me, I'm coming to this thread late, so forgive me if this has
been brought up before.

Have you tried Writeboard?

http://www.writeboard.com/




Randy B. Singer
Co-Author of: The Macintosh Bible (4th, 5th and 6th editions)

MACINTOSH OS X ROUTINE MAINTENANCE
http://www.macattorney.com/ts.html

>Forgive me, I'm coming to this thread late, so forgive me if this has
>been brought up before.
>
>Have you tried Writeboard?
>
>http://www.writeboard.com/

Yes, as I mentioned in the articles I've written about this...

http://db.tidbits.com/article/8489
http://db.tidbits.com/article/8613

cheers... -Adam

--
Adam C. Engst, TidBITS Publisher <http://www.tidbits.com/adam/>