Scenarios

TextFlow: Sharing a Document with Others

This is the fifth post on TextFlow in my research into collaborative document co-authoring products and services.

Sharing a Document With Others
One of the main reasons for using TextFlow is to gain a better way of working on documents with other people. Here’s how it works:

  1. Mark writes the first draft of a document in TextFlow.
  2. Mark wants to share it with Belinda, and get her feedback and edits.
  3. Mark clicks “Send”, and can enter her email address in the “To”, “CC”, or “BCC” field, and enter a cover note, as in an email message.
  4. Mark enters her address in “To”, and sends it off.
  5. When Belinda gets the email message, she sees Mark’s cover note, and a link to the document in TextFlow. She clicks the link, and opens the document in a browser window.
  6. Belinda makes her edits and changes within TextFlow. When she’s finished, she sends a copy back to Mark.
  7. Mark receives her copy of the document in his TextFlow account. It shows up within the window for the shared document.

In other words, this isn’t a co-authoring service at all. In my overview post on TextFlow, I wrote:

TextFlow from Nordic River Software in Sweden is a document co-authoring service, or what the Nordic River people describe as a “parallel word processor”. That means that multiple people can work on the same document at the same time, without requiring a manual process for bringing the different versions back together to a single master copy.

What’s “interesting” is that the above paragraph conveys the wrong picture of TextFlow, even though I wrote it after carefully reading what TextFlow says about themselves on their Web site. Perhaps I projected onto TextFlow what I thought they were saying, but having tried to use the service for working with other people on the same document, my ultimate conclusion is that TextFlow is merely an attempt to create “a better Word and email” approach. As in:

  • To share a document with others, you send them a copy that they work on.
  • You can’t “share” a TextFlow document with other people per se, as in giving them access to your copy of the document (through a document access control list). You “send” them a copy within TextFlow that they work on, and then when they send it back, you merge it into your master copy.
  • You still have the problem of tracking who has and who hasn’t returned their edits (“Did Belinda send her comments back yet?”). As currently implemented, you have to remember who has outstanding copies of the document.
  • TextFlow is better in two ways than Word and email: (1) you aren’t creating multiple copies of the document in email systems and stored on the desktop, and (2) edits to your document show up automagically on the right hand side of your document. They get routed there immediately; you don’t have to put them together manually.
  • Given the need to merge different copies to compare and contrast, TextFlow will have to deliver a superior merging process than Word. I’ll talk about my concerns with the current implementation of merge in a subsequent post.

So what we come to from trying TextFlow out is the realization that it’s just an alternative to Word and email, rather than a paradigm change to allow multiple people to work on one document at the same time, and to see each other’s changes in real time.

“Email” as a Paradigm for Sharing
In a recent blog post (April 28, 2009), Mark at TextFlow described the April 2009 release of TextFlow, and announced a “subtle, but profound” change to the user interface for document sharing. He wrote:

Share documents just as you would by email with the standard “To:” “CC:” “BCC:” fields.

This change from the previous version is subtle, but profound. Why is mail still the most used collaboration tool? One reason is that it’s so easy with mail to decide exactly who sees what, when sharing a work process. Sometimes you choose to CC:. You might go first for feedback to one group of people (say your colleagues), then to another group (maybe your customer). Maybe you want a lawyer’s opinion, or an accountant’s, before making a suggestion that others would hold you to. Email is great for this, because it’s decentralised. It also can be confusing, for the same reason. The new sharing interface in TextFlow supports the de-centralized approach of email — anyone can invite and exclude anyone — yet gives an overview of the different versions and easy collation of them.

I am not convinced that this is the right paradigm for sharing within an online tool, particularly in the way that it has been implemented by TextFlow. It’s doesn’t “do” anything! Being sent the document via “To:”, “CC:” or “BCC:” makes no difference to the actions that the recipient can take inside the document — regardless of whether you were a “To:”, “CC:” or “BCC:”, you can still mark the document up and send changes back to the author. I guess you could argue that “To:”, “CC:” and “BCC:” play an important human / social signaling role within the document co-authoring lifecycle, but I’m still unconvinced that it’s the right paradigm for TextFlow. The social signaling only exists within the email message that alerts each individual to the shared document, but is invisible within the context of the document itself.

One alternative would be a different set of language tags when sharing the document: Edit, Comment, and Read.
– with “Edit”, the recipient is able to change the text directly inside the document.
– with “Comment”, the recipient is able to leave comments on the document as a whole, but not change the text inline. This would require a new set of capabilities from TextFlow.
– with “Read”, the recipient could read the document, but not make any changes to the text directly or to the document through a commenting function.

Categories: Scenarios