This discussion space is for comments on the document "rfp.html".

Please feel free to leave comments or ask questions about specific aspects of the RFP and we'll do our best to respond to them.

It's worth noting that although decentralization is absolutely necessary, GroupEdit should also be able to provide the same capabilities on an intranet or even a network of as few as two computers.

There are "groupware" solutions for source code version control in the programming world. I think "SourceSafe" is one example. It is remarkable how much overlap there seems to be in the system requirements for this project of Adam's with version control system requirements for source code.
Just my $0.03 (adjusted for inflation..;-)
George Bigham
BighamG@aol.com

As Adam has said, the problem with source code version control is that it's often implemented line-by-line, which does editors no good. Also, we're looking for an application that combines version-control and change-tracking with an editor. Our RFP specifically mentions Subversion, a popular source-code management application. It would be great if someone could take advantage of such existing tools but with a front-end that was geared toward editors and not programmers.

These sound like the specs I want for a Groupware/Content Management System (CMS)/Document Management System (DMS?). eGroupware is a fairly active open source project. OpenACS, Drupal, (both, which I've thought about trying) and many others are CMS that run on lots of platforms, including Mac OS X. I'm running Wordpress and Xoops as trials on a Linux server, but not satisfied that they do what I need.

I haven't investigated Document Managment Systems, specifically, but the version control that you are looking for seems pretty sophisticated, so I doubt you will find that in any standard CMS. Maybe groupware systems will have that functionality, but it seems very document management oriented.

I love BBEdit, but don't use that to write. TextEdit is fine for many writing tasks. I am very satified with NeoOffice and Thinkfree Office, which - in addition - could use open source file formats. For writing, research, and note functionality, I am intrigued by Ulysses by Blue Technologies Group.

The integration of client and server technologies is beyond what most off-the-shelf products offer. It would be nice to find server software that supports open source file formats, which might let the client be any open source offering.

I suggest that the program must be cross-platform to really fill the gap. Its usefulness would be extremely limited if it is Mac-only.

You should look at the programmes lawyers use to track changes to contracts. I think they're probably quite similar to what you want.

This looks like an awesome application. I'm actually kind of surprised the makers of SubEthaEdit haven't come up with an application fitting this description

> (with drastically reduced features, obviously)

Don't give away the store before you need to. How about this? "(possibly with reduced features)"

When setting up a project, editors might routinely create a project-specific group for guest access. For some projects this group would never get used. Let's say we are creating a project named Charlie. We create a group Charlie-core and add all the writers and editors that we know will be working on it. We put all the project files in this group. Then we create the group Charlie-guest and don't put any files into it. When we need to give access to a new person, we create a login for them and add it to the Charlie-guest group. Then we add whatever files they need to work with to Charlie-guest.

iChat is a good example of a UI for this kind of flexibility. The way it lets you style the display of chats is simple and natural.

Edited by author 07-25-2006 08:36 AM
Consider having some asynchronous communications between the local GroupEdit app and the server that could facilitate such conversations, without getting into a fully distributed, SubEthaEdit kind of peer-to-peer level of awareness. Let's say you are writing a response to another editor's comment. If someone checks in a new version of the document to the server, and it contains changes to the section you are working on at this moment, the server could let your local app know this and it could put up an alert: "Joe just checked in edits to this very paragraph."

In general, each user should be able to customize the level of messages from the server that they allow to interrupt their work. For example, it might be possible to turn on notification when anyone checks in a version of this document; or when anyone on the project checks in any project file; or when a particular group member takes some action (e.g. check in, check out, go offline).

Adam: lurking behind this paragraph is an assumption about the workflow that GroupEdit supports. Editorial "passes" are, clearly, not somehing that Microsoft Word knows about. Would you want GroupEdit to have "baked-in" the workflow that your group needs? Clearly this sounds too restrictive for a commercial, or even a general-purpose, product. Then we get into schemes for defining and specifying workflows. Over the last couple of decades whole companies have swirled around the drain over this problem.

Here be dragons. The user/group security model would have to be carefully thought out as to how it relates to files and folders. I must confess that I still, after all these years, don't completely understand how Unix permissions (and groups) intersect with folders.

Great idea! I've recently been banging my head on walls in trying to find an optimum solution for having my writing edited by a friend/co-writer. I have yet to find a solution that met my needs. Not a Mac programmer, otherwise I'd be interested in helping, but if this project needs anything non programming, I'm interested. This sounds like the tool I need. :)

john.wilker AT gmail.com

I'd suggest going with this option. Writers don't necessarily think in code like programmers. Having to continually translate *Word* to mean italics distracts from the all-important focus on content. Italic should look like italic. Headings should be a little bigger and bolder than body text.

I'd suggest hiding in-paragraph text styles such as italics and indicating paragraph styling in a parallel column, where editorial comments could also be placed.

Keep in mind the importance to being able to tag paragraphs for their meaning. In a longer document, it's very important to keep the levels of headings right so a level 3 heading doesn't accidentally get elevated to a level 2. It is not easy for anyone but the author to tell which is which if that tagging is ever lost. Those distinctions needed to be tagged by the author and preserved throughout the process until, in the case of books, technical papers, and magazines, it's put into printed form.

Finally, as someone who's had to deal with the horrors of importing Word files into InDesign, I'd stress the importance of separating the MEANING of content from how it is DISPLAYED. Authors and editors should deal with content that's tagged as to meaning and not bother with determining the final font type or size. Alas, all to often they klutz with that sort of thing in the hopes it's make it look prettier for their editor. That's a big time waster.

Tags for headings, quotes etc. should be preserved throughout the process, so the person doing the page layout can use them (as character and paragraph styles) to layout the document, without having to ask "What level heading is this?" or "Should this word be italicized?" But how that tagged styling is displayed along the way should be left to each user. If a writer or editor likes huge text for his tired eyes or for spotting small typos, that's his choice. The next person in the chain small see the document as he likes it, with small text or large.

And please provide a way to strip all specific formatting out at the end of the process. I had one book that was within hours of going to press with some footnotes in the wrong font (that evil virus, Times Roman), until a sharp eyed editor noticed they didn't look quite right.

In short, tagged text is important. By all means have it and let users display it as they like, but in the end only pass the tags on to the page layout (or web design) application. Most such applications have an interchange format that makes it very easy to tag text. For InDesign, simply put a short header at the top stating this is in interchange format and then start each paragraph with the tag. <Body> will define it as body text. Export and import between applicaitons only gets difficult when you try to duplicate the appearance of one in the other. Leave appearance out of the picture until the end.

--Mike Perry, Inkling Books, Seattle

I'm John's friend/co-writer. I must admit this project does sound very interesting. I'm rare, along with John, in that I write, edit and program. Unfortunately, my last mac program was in 1994. I've dabbled with X tools, but done nothing of significance with it.

I'd be very excited/willing to participate in this project as long as we can a knowledgeable mac programmer on board. (S)He does not need to be a writer or editor, but just a mac programming wizard who doesn't mind working in a group setting and answering annoying newbie questions from me! Any takers out there?

Developers may also want to consider Darcs. Also open source, Darcs has the easiest repository setup of any RCS I know. This is largely because every workspace using Darcs is a repository.

Thus you can have a server with a central repository that everyone pushes to and pulls from, or you can have easy collaboration between just a few workspaces. This ability would satisfy Adam Engst's comment on Item 2.

Branching is stupid simple in Darcs: just copy a workspace. Merging branches is no different than any other "commit" operation.

Many years into the paperless office, I still find that the best way to read and edit something (reguardless of platform) is to print it first, get a pen and highlighter and go to town... Why, because I like to circle, underline, cross out and make comments, doodles, littles sketches in the margins or even in between words....More of a "freestyle" editing that I find easier to do and read later. I think that there should be ways to do that.

I like the idea of a seperate comments space to the side of the document so that comments can be made basically in line...as long as you are allowed to draw arrows to or highlight the area you are commenting on.

Also, identifying the editor could be accomplised with 1) little icons, 2) color coding, or 3) The option to view or hide individual editors comments as you please (or 4- all of the above)

I think you should also be able to breakup the editing permissions not only by document, but also by section or even object. For example, say you have a sketch in an article, as well as the article, maybe you could designate that object to be editable by a different person than the rest of the article.

I also think that there should be two modes, online and offline...

Online Mode:

As long as everyone is working online you would show live updates and let everyone work on the document at once...If two people started to edit the same section of the document at the same time you should get a little notice of that this was occuring, and perhaps even the option to start up an IM, or whiteboard session with that person or persons.

Offline Mode:

If someone was going off the network, they would be able to check out the document, or the section of the document that they intended to edit. Other users would be given a visual cue that the document is in the "checked out" state. They would still have the option to review but once the doc is "checked in" there would have to be a process to integrate the different edits.

It also occurs to me that MS Word's document tracking misses out on the fact that reviewing a document is a different case than editing a document and should be treated differently.

Is someone offline wants to review and add comments to the doc, but not edit, all you have to do is build in a mechanism to sync those comments, no need to lock the thing up from others. So that should be considered a separate type of editing mode.

PS. I'm an engineer that write lots of test procedures using word and it is useless...however I'm not a software guy, so these are just ideas...I couldn't program a line of it!

This requirement needs to be unpacked a lot more - what constitutes an "iterative pass"? In other words, how do you define an editing session? Would appending a date/time stamp to the edit somehow suffice for this? Or would it have to be a more formal "wrapper" that contained an editing session? You might begin editing a document, leave it and log off, then come back later and want to rejoin the same session. There would have to be some way to create a container for the specific edits that belong in a session, then to allocate edits to that container, whether by default (i.e. the session/container is open and all subsequent edits automatically get bucketed to it) or manually. And how are changes by each user differentiated visually across sessions? Colors seem too limited - with 3 or 4 people making changes across multiple sessions you'd quickly run into spectrum limitations...

I'm not a coder, but I am a former software designer, and I can already see that this adds considerable complexity to the concept of tracking changes. I don't have solid suggestions here, just pointing out spots where you could expand (expound?) a bit.

Honestly, I see serious permissions as being the sort of thing that could be added in a later version. In most small workgroups, there's a lot of trust, and as long as the system is guaranteeing data and even version security, I'm not too worried about permissions early on.

Interesting - I hadn't heard of Darcs, but I'll check it out. I have no great attachment to Subversion, other than the cool name. :-) I don't think branching is much importance in writing, as opposed to coding, though. Writing tends to be pretty linear and additive; it's highly unusual for an article to branch into two independent versions that would need be able to track back to a single ancestor.

An interesting point, guys. I think you're correct that there's an implicit Word-driven assuming about workflow here, caused by how we have been forced to send files back and forth via email. A "session" is therefore all the edits that take place until the file is sent back to the next person. However, I don't think this has to be complex. I see there being two basic "save" possibilities: a local save that's protecting against local power loss, crash, or whatever, and a remote "commit" that's saving back to the repository. I'd consider a "session" to be all the changes that take place before the file goes back to the repository, since it's at that point that someone else could take over.

One thought about the interface for such changes. First off, no user should have to see any of the colors. Second, if colors are shown, they should be toggleable by author. And if timestamping is shown, it could be handled either by shades of colors (if multiple authors are shown) or by different colors (if only a single author is shown).

I'm tending toward wanting implicit locking at all times - if someone is working on the file, that fact should be evident to everyone else and no one else should be able to edit the file until it's checked back in. But here's an idea: what if GroupEdit had its own simple chat mechanism, with each document having its own permanent chat space. It would be real-time for anyone who was connected, but the entire history of the chat would be stored permanently with the document and would be viewable by anyone. And with iChat-like time and date stamping of message, it could also serve as a constantly updated blog for the document.

REF: Item 8. In any document creation/revision situation, discrepencies force the involvement of a human editor with intimate knowledge of the subject (best to be the author). Forcing revisions in a simple check-out/check-in in a serial fashion is exactly like the issues of record level and field level locking in a database. I think you must use a serial editing process with check in/out - or you create a nightmare for an editor, reconciling more than one version. It may be possible for the server software to combine multiple documents into one, highlighting revisions by different authors in a unique color. Plus, I'm not sure what "modifiable set of rules" you want for the reconciliation of offline and "live copies." I gues that one such rule would be to force the serial check in/out and revision, which is certainly possible with a limited number of writers, editors, approvers.

Discrepencies are a can of worms. Serial check in/out and editing is best. See my long post in general comments.

I agree with the comment below: separation of form and content is the key to making this work. Writers shouldn't have to think about how the text will look.

Instead, the client program should display a list of block or paragraph tags, each of which has been defined by the editor.

E.g. "Body", "Sub-heading", "Boxout", "Photo" (which would simply display a filename in the client program), "Photo Caption", etc.

The writer would pick from the list. He would not be permitted to add a tag directly, but a mechanism could be put in place to allow him to request or suggest a new tag. (The server could even CC the request to an Art Editor or some such.)

Couldn't 'iterative passes' be accomplished with the version mechanism by simply saving the document to a new version after each (editorial) pass?

Saw someone on TUAW mention subethaedit. I took a look at it. Looks like a really nice app, and almost even close to what GroupEdit could be. From what I can tell it doesn't track or version, and is more real time lots of people typing at once, but it does incorporate multiple inputs (writers, editors), and can track who did what.

Expanding on the iChat thing, not sure if this would lead to feature bloat (the avoidance of which should probably also constitute a feature request), but maybe there could be two ways of using the chat interface - document level chat as well as specific point in a document chat. So, there may be one contentious paragraph that many authors may wish to chime in on. There could then be a chat area set up around this paragraph, or word, or even punctuation mark. Again, it would be obvious via an icon where there was a chat.

I think that some kind of visual representation is important. It can be easy to specify that something should be tagged as Heading2, but sometimes it may be important to see that "oh that is THAT level heading...perhaps level 3 is better".
I would like to see an editor (or art director editor) have the permissions to assign a style sheet to a given document. The author can then choose to work in the unstyled view, or the marked up view. Being able to see invisibles is also very important. And also maybe document-level things such as "allow double spaces after fullstops" (yep, I am Australilan;-) or disallow same, for instance. Again, specified by the editor.

Journalling is really a filesystem or database technology.

GE should support rollback without network access (like Subversion), and safe writes (to a temporary file, which only replaces the previous version after changes are complete) like many other programs.

Given your requirements for network access, versioning, and usability without a network, I think Subversion provides much of the back-end infrastructure for GE. Do you see aspects of GE that don't map well to the Subversion model, or is it just a lack of clients? If the latter, it might be time to look into extending SubEthaEdit (or TextMate). Alternatively, now might be a good time to influence the development of ZigVersion.

http://zigversion.com/

The back-end requirements seem extreme for a clean-sheet approach -- you'd need to recreate at least half of Subversion, which is a very large and serious project with lots of sophisticated talent -- so hopefully you can leverage an existing framework.

And apply one individual change, or a range of changes, using the GUI.

Something I just discovered I really want as a reviewer: GE should offer options to compare against the current version ("HEAD") or the previous ("PREV"), or an arbitrary version, or the latest change/approval by a given author/reviewer.

So I could catch up on all the changes to a document since I last reviewed it, or since another trusted editor did so. Going back through the change history to figure out what version to compare against is awkward and inefficient. Matters more across sets of files than individual documents...

I would define a minimum of 4 levels of access:
Site admin - control of all projects and site settings
Project admin - control of a specific project
Project contributor - read/write on a project
Project visitor - read-only

You should be 8-) I would think about project style permissions where a project can be an article or a group of articles (i.e. an issue). Then you could define different access at each level.

I think it is significantly easier to code for security in advance than to try and hack it in later, so you should at least define some access levels.

I'm starting to agree with Chris that what you might be looking for is a better front-end to Subversion. I've only started touching on Subversion, but I know it has WebDAV support. I just hate WebDAV so I've never played with that functionality.

Your word workflow presumes one person editing at any one time and other user's "locked out" because you have the latest file. However your offline mode presumes you'll be able to just open a file and work on it -- but so will other people that have a copy of the tree with them.

For a true offline mode, track changes will have to be able to track simultaneous changes and do conflict resolution too (or at least warn that conflict resolution needs to take place...)

How would handle implicit locking in offline mode? Should somebody have to pre-check out files before disconnecting (and thereby locking others out while they are disconnected?)

The best change tracking application I have seen so far is FileMerge, which comes free with the dev. tools included with MacOS X (it's an Apple app). It gives a beautiful, graphical presentation of the changes between any two files (e.g. versions of the same file, from a version control system), high-lighting differences down to the character level. It also allows you to edit the resulting "merged" file, but it won't update the display of the comparison.

My main grip with it is that it only handles Latin-1 properly. When used with UTF-8, the character high-lighting goes way off track, since it considers bytes, not characters, when looking for diffs.

After reading through the GroupEdit RFP, the impression is that you want a single application that merge the core aspects of the following existing applications/technologies, with some refinements and tight integration:

- SubEthaEdit (for real-time collaborative writing, highlighting of authors, and tag high-lighting/styling
- FileMerge (for visual tracking and comparing of versions and diffs)
- version control system front end, e.g. CVL (for CVS) - I suggest that GroupEdit is agnostic to which version control system is used, i.e. that it can cooperate with several systems (cvs, subversion, others)
- iChat

The whole should be more than the sum of the above parts. The idea is not to try to integrate each of the above applications with each other, but serve as a starting point for what could be achieved: an integrated whole taking major ideas and features from the above list. It *might* be possible to integrate some of them, for example taking SubEthaEdit as a starting point (given that its developers are interested:-), and integrate chat functionality (I have a vague memory that iChat also provides some sort of framework that can be used by other apps), a version control front-end with features as outlined in the RFP with diff views and version comparison possibly along what is found in FileMerge.

Just my 2 c.

One caution about Darcs -- it is written in a little-used, academic programming language called Haskell. You have to install Haskell as part of installing Darcs. I did this once, long ago, and it was such a horror show that I have blanked out most of the memory.

Yes, I think combining the basic functionality of the apps you mention is roughly in the right direction. But keep in mind that SubEthaEdit is real-time only, which wouldn't be helpful in 99% of the writing situations we envision. And FileMerge, although it can compare files at the character level, doesn't let you edit in a version that shows you the comparisons, making it essentially useless. And as much as making GroupEdit agnostic to the version control system sounds like a good idea, I think it makes much more sense to have it work well with one open source system and to integrate it so the users and admins don't have to fuss with the variability that's guaranteed to come from an agnostic system. We want this to work, not be ultimately flexible.

Yes, I tend to agree, James. In most editing environments, simple check in/out would be fine. Perhaps resolving discrepancies could be something added in a later release.

Having used Subversion a bit, I think it provides everything we'd need on the back end. The real trick is in the front end, since locking, for instance, exists in Subversion, but most clients don't try to prevent users from checking out a locked file, as GroupEdit should. That's because merging changes isn't generally a program with code, whereas it is with prose text.

Yes, we're initially assuming that a major aspect of GroupEdit is to provide a really good front end to Subversion (or some other version control system, but Subversion seems like a good one).

Indeed, I think some careful thought will have to go into how comparisons are displayed between versions, because sometimes you want to see all changes since the beginning, sometimes you want to compare just two arbitrary versions, sometimes you want to see all the changes since some point (when you last saw it, for instance), and sometimes you want to hide all the changes and just see what the current version looks like.

There is indeed some conflict between offline mode and check in/out. My answer for an initial version is that check in/out should be possible only when online. An offline user should be able to open a file, and even make changes, but in such a way that they're entirely outside the system until manually merged back in (and the user should be warned about what will need to happen).

Dear Adam et al. I'm writing from a broadbased publishing perspective, with some limited software development experience, and I have some experience with older editorial systems. And, I'm thinking what would make a sellable product, and I wonder if this would be helpful:
* What output formats do you want to support? You say this is a "text" editing system, though I'm not sure you really mean it. I think you probably mean text (possiblly localized?), at least basic html, setext, and I think some kind of styled text (probably RTF). I would think RTF would make a good common ground, as you could then support a set of paragraph styles appropriate to your needs. Did I say RTF - there's the venerable TextEdit example project sitting in the OS X Developer Tools for anyone to adopt and modify!! Hopefully it includes the spell-checker.
* Workflow: I'm not sure how you work, but I'm guessing you toss stories back and forth among editors and writers until you hit a finish point, and I can see how this would work well for many, while other operations have a more rigid set of steps within a queue. At the very least, though, you have a) a bunch of submissions, or even just ideas, outlines, that are just floating there in various stages, and b) scheduled stories in an in-process queue heading towards a publication of one sort or another. So, this beast needs to be able to support multiple publications neatly, multiple editions, and a bunch of stories with rich labeling as to where they are at in production, as well as a bunch of categories of people assigned to work on them. So, to me, this thing will need a) a window where editors in charge can view clearly what's going on with any one edition in process, who has what part and what stage it is at, and b) an interface containing a list of stories that have their name attached, and labeled so they know it's time to act on it. Again, this is to make it more sellable.
* Version tracking, rollbacks, journaling, individual person-session edit-coloring. It boggles my poor mind. Wonderful, that you are promoting this!

Just checking in. Hadn't seen any postings lately. Wanted to see if there was anything new. :)

Wow! What a great concept. Anything that works better than Word's Track Changes would be a vast improvement. I'm working in the book world and often get files that are full of fancy formatting from authors who want to make it "look pretty" and have to spend a couple of hours stripping all that out before I start with the text edit. Then I send the file to another work station where all my changes in red appear in green and when I send the file back to my original station (don't ask -- I have to work on a Mac and a PC), there are blue and purple but no green or red changes. The actual changes are still there. And don't get me started on paragraphs that auto-renumber. Thank you for what you are doing. Keep up the good work.

UTF-8 and multiple suggestions on wordchoice for me is important. I work on longer documents with a need for 6-8 collaborators to help refine word choice.

It seems to me that Change Tracking and Comments are pretty much the only features you need that couldn't be supported with svn (and a user friendly front end to it) - I note that other people have made similar points.

You'd probably be able to use the svn history data to get all the delta's and assign blame. If you tie comment locations to svn revisions, you should hopefully be able to recalculate the appropriate new offsets for the comments.

Then you "just" need a nice gui for viewing that data and editing the file, delta and comment data.

Yes, I think you're right, but the devil lies in that "just". ;-)

After reviewing Adam's comments in TidBits #842, and reviewing the RFP, here are some additional thoughts. My perspective is influenced by years of publication production work, familiarity with a few high-end editorial systems for newspapers, a lack of knowledge of the software products like SubEthaEdit, some programming experience and website development experience. Let's say the features below are what I would like to see.

If I were going to attempt this project - and I assure you I am not - I would consider using Userland Frontier as the server (but after considering its long-term availability and future development. It has a lot of smart features built in or accessible. Mostly it would just serve and maintain serial versions and data on them such as the production stage, owner, writer, permissons, etc. But it would be a multifunctional server: besides serving story text, it would also serve info on, for example, all stories "owned" by an editor, a writer, etc; the production stage of each; the publication/date each story is intended; and so on. It's the latter capability that will make it a good editorial system.

I now think that stories need to be handled as tagged text with several types of tags. One set of tags would be for paragraph and in-line formatting, and would need to be rich enough to convert well into various user specified formats. The second set of tags would control the text coloring of edits and comments by various people. But I would be wary of trying to be able to see numerous stages of changes all in one version; rather it should be made easy for a user to call up previous versions for reference. Some metadata at the top would define the version, and other potentially useful control information. A possble third set of tags, possbly built into the first, might identify indivdual paragraphs (understand that a headline, subhead, bylines and other user definable styles are paragraphs); this might allow for better management of changes.

UTF-8 and Unicode probably should both be supported, or at least the latter.

The editor would probably need to be built from the ground up. I would like it to display a) styled text, as it is easier to read. That's not to say it should be the final format, just some format that the user can define for their own preferred writing/editing convenience. b) Single and multiple display panels in a single window, where one would always display the current version, and a second could display either a copy of the current version where the reader can scroll up and down to check for consistency between a current paragraph and other parts of the story. Alternatively, the second panel could display a previous version, _or_ extra windows could be opened to display these earlier versions. c) a switch for displaying in narrow or standard column views - I like the narrow for editing and proofreading.

Version control and offline edits. In professional publications I have always worked with fairly strict version/production stage controls. You have to understand that it is during edits and rewrites that a lot of errors get introduced in the copy. Essentially I see all version changes to be offline, but the editor might have a save button that would save to the active version on the server if it is available (ie. the user is internet connected that moment). A version called up from the server (as opposed to some copy on disk), would set a "lock" on the server, so that if say the writer has called the last version for rewriting, a lock is set, and the editor can see right away if the version is out for rewrite. The locks should be something the editor can override when necessary. On the user side, the version he or she has subscribed to such that they own the version is locked for their own use; when they are finished the press a Save and Submit button that releases the lock, and to do further changes they need to resubscribe, which starts a new version.

The pesky part will be the necessary situation where the writer really is offline and cannot access the server to subscribe to a version. Assuming they have the most recent version on disk, they can open it and work on it, but when the eventually submit it, it gets saved as a new version. Occasionally, another person may work on the story at the same time. So the server has to recognize that two current versions exist and communicate it. Here's a case where paragraph labeling could be handy: the editor could call up both versions (note the two display panels above) and step through the two probably doing some cut and paste; or they might choose to join the two, where paragraphs are displayed together, the version x displayed with a version x tag displayed, followed by the version y paragraph with it's tag displayed. I should also mention that the editor should have the ability to roll back to a previous version and make it the current one.

Having built-in chat and internal and external email and other notification cabilities would be a great enhancement. While there may be a set workflow, the editor ultimately controls to whom a version gets directed when he/she submits it (back to writer, to editor, to production); and the reciever should get notification of that the story is in their queue. (others would be locked out presumably.

Live spell checking and regular expression search/replace capabilities as suggested previously by others would be highly desirable as well.

I see all these features as quite capable on the server side using something like Frontier. Doing a good editor would require some real skills. I'll skip any details beyond those mentioned already of the version management features, except to say they should provide a high level of control, communications between a story's team members, and access control to writers or others. I hope these thoughts are helpful.

Excellent comments, John, thanks!

>storing different projects and archiving of completed articles
Suggest change to:
storing different projects and archiving completed articles

>the showing of different text colors for different authors,
Suggest change to:
showing different text colors for different authors,

Regarding the color problem, how about a fixed color for each person, followed by a number to indicate which session by that person (or alternatively which "pass" -- by anyone -- through the document)?

It would be instructive to hear how well you (and others) think QuickTopic does this.

Columns, to see different versions of the same part of the text or to show comments or related links/references, and the ability to see 2 different parts of the same document simultaneously, are very useful tools to boost writing productivity.

Check in/out management sounds like a solid first step, while the reconciliation rules get hammered out.

By all means, include outlining features - the sooner the better!

QuickTopic is quite good at collecting and displaying a group's comments on an bit of text; the only problem is that it's a bit of a pain to set up for more than occasional documents. Ideally a program like GroupEdit would build in such functionality so it would be highly fluid.

RE: darcs -- there are easily available pre-compiled versions for Mac OS X. Don't get bogged down in implementation details too early.

Wassup? Where did the project go, is it stalled, being worked on furiously in secret?

I'm too busy until some time in 2007 to do other than indulge myself with an occasional peek but there's a lot of synergy between this project and other stuff I've been working on and thinking about with regards to storing and choosing variants of bits of a rich document.

Some thoughts so far:
1) I think settling on a version-control system as a backend is a huge rathole down which the entire project will disappear. The semantics of file-oriented revision control are not what you're discussing. In particular, you want more incoherent merging, picking bits out of a set of changes.

2) I am playing with a tablet (I know, we're all still waiting for iTablet). These things are made for editing!

Of late, not much has happened. I've been working on a spec and use cases, but have been bogged down by other projects for a while. I hope to get back to it soon.

Further to the angle of revision-control and undo being tightly integrated, there's some interesting stuff happening in "e for Windows" which started partly as a way to get a TextMate-compatible editor on Windows. It's wxWidgets-based so theoretically cross-platform although the author has said he won't do a Mac version out of respect for the TextMate author.

http://e-texteditor.com/blog/2006/making-undo-usable

I don't think his user interface is actually suitable for your goals but may help with the use cases.

Another interesting, albeit old, paper is http://www.ifi.uib.no/konf/nwper98/papers/persson.ps
on combining revision control with editing.

I suspect there is a lot of similarity between the chunking of textual lines of code into classes and methods and the natural chunking into paragraphs and tables of your editing environment.

In both cases, whilst merging, splitting and reordering of chunks may take place, edits within them are usefully treated as bounded by the chunk. Hence, discussions of programming-oriented editors for OO languages become relevant ;-)

The Digital Document Discourse Environment http://d3e.sourceforge.net/, has many of these capabilities, in particular the two pane method for commenting on user-specified fine to coarse grained sections of text. It also allows for comments on the comments, which is quite useful.
It's open source, so the feature set could be built-upon.

D3 does indeed look quite useful for commenting, though I'm not seeing if there is any real collaborative editing capability as well.

Using metaphorical straws helps prevent injuries to real camels. ,