1 from TidBITS Electronic Publishing and Mac Publishing
2 To create an Internet-based collaborative text editing environment -- let's call it GroupEdit -- that small (and often geographically dispersed) workgroups can use to create, share, and edit documents.
3 We anticipate that GroupEdit will consist of two parts: an Internet-accessible server and a Mac OS X-compatible text editor. Windows compatibility may be important to others, but not to us.
4 We would prefer that GroupEdit made use of existing tools - particularly on the server side - rather than rely on custom solutions.
5 Because most distributed editorial operations involve a revolving door of outside writers, it's important that writers be able to use GroupEdit when it's necessary for them to interact with editors, respond to editorial comments, and the like. As a result, GroupEdit should be licensed under a reasonable site-license policy, so an editorial organization could freely distribute a copy of the tool to writers. Alternately, there could be a "lightweight" version of GroupEdit (with drastically reduced features, obviously) that would be free for external writers to use.
6 GroupEdit documents should be accessible via the Internet, protected by a username and password. The system should be able to create and manage groups, and assign files to groups with access settings at both group and file level where files inherit group permissions by default.
7 The current version of all the files should also be stored locally and automatically (using journaling), so that the user can save as they write without having to check in a new version. This local and journaled storage protects content in case of computer or network failure. However, GroupEdit should provide its own interface to the files rather than relying on the Finder, since the link between the Finder and independent applications is too weak for actions other than opening.
8 GroupEdit should be able to work entirely in offline mode as well, in cases where a writer can't connect to the server while out of the office. GroupEdit should have a carefully constructed and potentially modifiable set of rules for reconciling offline edits and revised live copies when discrepencies emerge if the offline file wasn't checked out or the organization using GroupEdit doesn't want check in/out management.
9 GroupEdit will need to provide a folder structure for storing different projects and archiving of completed articles. Users should be able to move files within the folder structure and rename and delete files as well (assuming they have write permissions, of course). GroupEdit should allow group ownership of folders as an option.
10 Permanent users of GroupEdit will need different permissions, so that they can perform only tasks appropriate for their role. Editors should also be able to grant access to individual files to guest users (i.e., outside writers), so that they can participate in the editorial process without gaining access to any other part of GroupEdit. Editors should be able to create groups, and be able to add and remove members of those groups. (All this said, finely grained permissions are less important than the collaboration features, and could be added in a later revision.)
11 To facilitate use by these outside authors, it should be possible to send someone a URL with a custom scheme that will enable the GroupEdit application to connect to the appropriate article.
12 GroupEdit should automatically track versions, partially to enable change tracking, and partially as a backup mechanism against catastrophic data loss.
13 The leading contender for revision tracking right now is Subversion, which benefits from being open source, but which has lousy front ends. GroupEdit would need to provide an easy-to-use setup mechanism (for both the server and clients) and an internal graphical interface to the folders, files, and versions maintained by Subversion. Subversion also supports locking, which can be helpful in an editing environment, much as programmers don't generally use it. Locking could take place automatically when opening a file for editing, with the lock being cleared when the editing window was closed.
14 A less plausible possibility is WebDAV, which also has open source implementations, although it's not clear how many of them might implement its versioning and locking capabilities.
15 GroupEdit should, using versioning, offer the capability to display the changes between any two arbitrary versions at a character level. The user should be able to edit the current version while changes from a previous version are being displayed, rather than merely being able to see the changes in one window while working in another.
16 Ideally, changes would be linked to particular authors. (This means that what we may really be asking for is not just the ability to show differences between two versions, but to look at all of the intervening versions and take into account when - and by whom - those changes were made. More complicated, but allows an editor to get the full flow of document changes.)
17 Users should be able to customize how changes are displayed. For example, the showing of different text colors for different authors, showing all changes in the same color regardless of author, showing all text in the same color regardless of changes, toggling display of deleted text. It should be possible to switch between different display methods quickly and easily, since many editors prefer to work with no change marks displayed, switching only to a view where they are displayed on occasion to tease out what's been done in a particular section.
18 Iterative passes by the same people should be separately identified, distinct from Microsoft Word's still broken method of showing changes. That is, the same person who performed an edit in pass 1 should be shown in a distinct manner if they edited the file again as pass 4.
19 GroupEdit should allow users to make comments at a particular location in the document or in relation to a piece of selected text. Display of these comments should be customizable: not only turning display on and off, but displaying them inline in a (user-definable) color, as icons with attached tool tips, as "footnotes" in a separate pane, or perhaps even as items in a second column off to the side of the main text.
20 It should also be possible to make comments on comments, and general comments that are not attached to a particular location. Often, comments in a document prompt a short back-and-forth conversation between editors; the system should facilitate that.
21 Rather than using styled text, GroupEdit should use plain text with a simple, human-readable markup language such as Markdown, Textpattern, or MediaWiki mark-up, or a modified version of same that allows for extra features. Ideally, the editor would support multiple markup languages through plug-ins.
22 Styles that will need to be supported include: italics/emphasis/citations, bold/strong, multiple levels of headings, hyperlinks, quotes, tables. Structural styles are preferred over presentation. Keyboard shortcuts should be available for stylizing selected text.
23 Optionally, GroupEdit could "hide" text style codes and instead display actual styles (e.g., italics and bold), to make documents easier to scan. In this case the native codes would still exist behind the scenes, so that the document could be human-readable in its standard form.
24 Although a reasonably capable text editor can be created quite easily, it would be good if GroupEdit could also pass documents off to other text editors, much as ecto and MarsEdit can do with BBEdit via ODB. It's possible that the LinkBack technology could be used to accomplish this as well. This feature would enable a writer to drop into BBEdit, for instance, to run a Text Factory or complicated grep search.
25 Ideally, GroupEdit would eventually provide the kind of advanced editing features that writers need, such as inline spell checking, extensive keyboard control, constantly updated word and character counts, easy-to-use grep search & replace, links to external reference tools, and possibly even outlining features to help structure a document.