Talk:Online document services

Linked to existing article

This seems a good application to list in Convergence of communications. Let me know if you think it fits.

I also had collaborative document writing in mind. Do you see that as part of this service (e.g., where one participant can literally mark up a draft and circulate the change), or should collaborative applications such as wikis be a separate line item? Howard C. Berkowitz 22:22, 27 July 2008 (CDT)

Yes, its appropriate to be listed in Convergence of communications.

Although both are collaborative tools, I feel that wikis are a different category. Wikis involves editing and publishing content on web pages whereas Online document service is collaborating by allowing users to edit documents in various formats(like doc,ppt,xls,html etc.). Google docs, ThinkFree etc are different from wikis. They are using a different approach to achieve somewhat similar goals. Gaurav Banga 03:18, 30 July 2008 (CDT)

I agree with you. These would be good points to have in the intoduction of this article. Often, I find that it is important, in using the introduction to an article to set the context, to define what the topic is not, because unless the reader is "forced" to see what is unique about the topic, it's too easy for the reader to fall into assumptions and not see your point.

For a very different topic, you can look at something I just wrote on infantry fighting vehicles that established what they are not.

One thing I still don't understand about ODS is how change control works. Is there a change control method assumed, such as programmers use with sccs, rcs, etc.? Otherwise, at least with wikis, unless the articles are quite small, active collaboration leads to lots of edit conflicts.

I don't know if you consider it part of ODS, but I have found it very useful for several people, audioconferenced together, to be able to mark up PPT on on desktop to which all can have. It's long enough ago that I don't remember the tool, but it might have been NetMeeting. There were no edit conflicts, because only one copy of the PPT was open (always save before starting a markup collaboration, and then save frequently)Howard C. Berkowitz 04:44, 30 July 2008 (CDT)

You're right. The distinction is a good thing to have. I have included it now. Thanks.

Some of the ODS providers allow only one person to edit a document at a time. For those who allow multiple people to edit at the same time, I believe there is a document version control method that they assume which allows users to keep track of changes and revert back at any time,if desired. Also, conflicts are minimized by notifying the collaborators in real time that someone else is also working on that document (or on that particular section of the document)

I remember NetMeeting. Indeed, its a very useful tool. We can actually share screens and see what others are doing. But, it is much more than ODS. It may fit in various other fields: video conferencing, voice chat etc. Gaurav Banga 04:02, 4 August 2008 (CDT)

General and editorial comments

I think I'm getting a better idea what you have in mind, which might be closer, in some definitions, to "collaborative markup." It's easy enough to share a document in read-only mode, but to be able to mark it up is much more of a challenge. In the past, one of the hard parts of such an application was change control: only one user at a time can mark up a document, or you get some very confused copies, or the equivalent of a WikiMedia "edit conflict". The original UNIX application that made this happen was sccs: source code control system, although there are many newer versions.

It would help if you could include a section with a representative use case: assume Bob creates the document and wants Carol, Ted and Alice to comment on it. Ted and Alice's comments are independent, but Carol would comment only after seeing Alice's changes. How would this work? How does the application keep Ted and Alice having an edit conflict?

A brief comment on how the sharing physically works (i.e., with respect to protocols would help. If there is change control, I doubt it could be a distributed peer-to-peer protocol such as Torrent? Is it HTTP/HTML based as is MediaWiki?

Is there an option to send a message to all users of a document when a change is made, as there is email notification of changes to a monitored CZ article?

As to it being "absolutely free", there are costs with running the service. How are these handled? Paid advertising, as with many web sites? Sales of the markup software, such as Microsoft Office?

Just a writing suggestion -- the article sounds like a presentation, partially because it contains references to "we" and so forth. While the prose of an encyclopedia article need not be dull, it isn't written as if it is a conversation or presentation.

Howard C. Berkowitz 10:59, 28 July 2008 (CDT)

Trying to categorize a recent experience -- ODS, Wiki, or something else?

Not too long ago, I was doing some consulting for a company with which I've worked over the years, doing some early design documentation -- more specifically, it was developing both some architectural specicications, but also generating patent applications. Previously, we had used Word with "track changes", but, unless we put the Word documents into our source code management system, there was always the problem of making comments on the wrong version of the document. When only a few people were working on it, we coordinating who was updating via email, which was less than satisfactory.

As something of an experiment, we went to an in-house wiki, and that seemed to offer several advantages. Multiple versions were still an issue, but we made a practice of saving frequently so if there were an edit conflict, we'd detect it before too much conflict was created. Some of the advantages we found for using a private Wiki was separating discussion from actual document edits, and also to create links, stubs, etc., to things that occurred to authors as new ideas relevant to the project.

Eventually, the content stabilized, and a designated person transferred it into Word so it could go to the patent lawyers. It's still stuck there, but that's not the fault of the tools.

So, I have used several approaches, all with advantages and disadvantages;

• Word with track changes, no source document manager
• Wiki for the active work, manual editing of final from research team into Word.
• Word with track changes and also using a code management system so only one person could edit at a time. The code management was quite awkward, as it really was designed for programs, not documents.

Of the three, however, the Wiki turned out to be the most useful, mostly because it had a built-in area for discussion, and a way to add content as new articles, to be integrated later. The problem of change control and edit conflict remained.

Not having worked with a recent ODS, the questions I'd like to see the article answer include:

1. How does it handle version control and edit conflicts in a way these other tools did not?
2. Word has a "comment" feature, which I find almost completely unusable -- it really can be used online only, not on a paper document, and I find it hard to read even there. Does ODS have the equivalent of separable talk pages, and also the ability to create stubs for new ideas?

Or is ODS essentially what we did with people manually coordinating who was working on what version of the Word document? Can ODS handle several people working simultaneously?

Howard C. Berkowitz 08:31, 4 August 2008 (CDT)

Version control

Great! This was very much needed.

If you could even link to some examples, it would help greatly. My biggest question about ODS is how it is a better collaborative tool. SCCS is fine for source code, but its line-oriented output really doesn't work for documentation. Word's "track changes" feature is acceptable but not great, but has no strict version control, so it's very easy to wind up with several differently marked-up versions.

So far, the best collaborative writing tool I've used was a private wiki, but, after the discussion, I had to take the text and manually edit it into a deliverable Word document. Hopefully, there's a better way.

Howard C. Berkowitz 13:37, 12 August 2008 (CDT)

Comparison table

Good work!

A few questions. As a user of the service, why do I care about the backbone? Does the nature of the backbone imply that my desktop must run those services? Do I have restrictions on running other things?

In version control:

• Is there a mechanism that allows only one user at a time to update a document?
• If so, is there a reasonable sysadmin function that lets me put a forgotten document back?
• How are revisions presented? Line-by-line diffs? Marked-up text like track changes in Word? Something else?

Howard C. Berkowitz 09:24, 14 August 2008 (CDT)

Thanks ! We care about the backbone technology as it needs to be supported by the user's web browser. For example, Adobe Buzzword won't even display the login/sign in screen, if one has Flash disabled in the browser or is using some kind of ad/flash blocker which doesn't allow .swf files to play. Similarly, ThinkFree will encounter problems if Java is disabled in the web browser. And disabling Javascript will cause problems to all four ODS providers that are mentioned in the article.

About version control: once you invite collaborators as editors, I don't think any single user can have exclusive access to the article (unless the owner of the document decides to revoke the permissions of collaborators). Comparison between revisions is presented as Word-like marked-up text.Gaurav Banga 21:28, 15 August 2008 (CDT)

The usual IETF interpretation of "backbone" is the packet switched Internet. I think you have to define what you mean by "backbone", or perhaps find a closer term such as "middleware" or "application utilities". To me, backbones don't have screens; they don't even have human interfaces. They interconnect computers.

Speaking as a Computers Workgroup editor, I really don't have any idea what you mean, in this context, by "backbone". Java, Flash, and JavaScript are completely invisible to anything that I consider a backbone.

As far as version control, it is absolutely standard that a programming collaboration tool, such as the original UNIX SCCS, allows all to read, but one must "check out" the code to modify it, and then release control. It's not a question of an exclusive user, but enforcing serial change control. Howard C. Berkowitz 22:49, 15 August 2008 (CDT)