Garo Garabedyan- a private blog

Wikis are even so powerful because it mimics the way we work in real life in order to produce content. When we work in collaboration the aim is the same. Wikis help to keep the aim and to avoid any other misunderstandings and waste of time in communication between the team members.

http://www.commoncraft.com/video-wikis-plain-english
Common Craft Show about wiki as a coordination mechanism between people.

Saving the data in one lace is not a revolution of Wikis. This is a known technique, which wikis share.

Data Immunity (opposite of Data integrity)
Free to make a change which will be applied until someone changes it
While editing wiki page there is no any conversation between you and the other collaborators. This is a good characteristic in order to do what you really want, to reach the main goal of the project. If the collaborators are many it is hard to get into a some consensus about something, sometimes the other collaborators have no opinion about your change. But when you apply your change directly, only people who have arguments against this change will talk to you (or just erase your change).

People were scared at first look at wiki. They all have been thinking that people will be like vandals and will mass delete and change whatever they see. They think that collaboration between unknown people have to be first in talks and later when everything is set down, it to be applied in homogeneous final work.

This process as described above is only in real life. By IT we can save all the revisions which in real life is too heavy to be done (revisions are sometimes so much and so small in their change). We can provide a continuously edit and update of wiki article which is too hard in real life process of collaboration.

Express your opinion independant
Blogs and Forums are competitors of Wiki only when there is a discrete topic on which all members want to express their independent opinions. At this case blogs and forum present editing capability only to the author of the concrete post. At this case the saving all the revisions is not needed.

Wiki is useful in Enterprise
Wiki enables full and dynamic collaboration on the topic of the job and lets executives to see who and how much work have done.

Commenting (or expressing independant (not mass editable) view)
Because of the mass editing nature, expressing independant opinion should be protected by the revision history engine in the wiki. In other words to inherit the motionless nature of the pure revision and this way ignore the dynamic behaviour of the wiki content at all in order to save the independent view not changed.
Making comment like a chronologically presented opinions is too motionless technique for the virtual enterprise collaboration. Everything in virtual world is dynamic, especially about the enterprise where things must be dynamic. So making comments have to be tied with something static (the revision itself is a good candidate in example).

Making comments in Wiki articles have to be tied to a concrete piece(s) from the last current revision. This means that a comment is related to the revision and to a piece from the document. This comment must not be presented to revisions older than the current. This comment have to be presented to newer revisions until the linked piece of the document is not changed, at such a case the author of the comment is alerted and he or she has the right to republish the same comment if he/she things it is needed.

New Office Packets with Wikis
When we collaborate in real life in order to finish a particular job we behave like we are in an on-line forum. Usually our colleagues calls us with some request about some work, if we thought that we need some additional information in order to finish the job, we call our colleagues and ask them about the needed information.

We all use paper folders in our real life jobs. We trust our colleagues that they will not replace of steal some document from this folders.

Now, let me describe you the future Office Pack which will have this capability in itself.

You will be working not with a single document, but with a hole bunch of many documents stored into one secure archived Office file. This file will be secure and nobody can replace a document from it. To this archive wil be added a default wiki which will coordinate the editors about the TODO list and so on. Every piece from the content of every document can be addressed and referenced from the wiki article.

Document revisions would be a statutory to the new way documents are going to be edited
In future bosses will use document revisions in order to review the work of every editor (worker) in collaborative on-line jobs. No matter is the document a Solid Works model of an engine or a brochure for a piano concert. This will be all inspired from the mass usage of document revisions within Wikis.

http://garabedyan.wordpress.com/2007/11/18/ajax-wiki-editing/
Ajax is useful to wikis because it can make fast editing and with a special JS code Document Revision recognition can be done while the article is editing.

This kind of editing would be a little bit advanced.

Editors will be able to mark with special tags the content (piece of the document) which they are not sure about while they edit content relative to the first one. We talk about a parallel work on one document and in usual people who work on it are not specialist in what the other person is doing. It is something important because in default people thing that when you edit (fix) something you try to make it true, but if something on which the last thing is based on is not true (I have written a post about how to technologically present such relations), you are responsible only for your work. When your work is closely related to something which you can’t predict, something that you don’t know, you need to claim that you don’t want to be responsible for it while doing your job.

Idea: Document revision for a concrete piece from a document
Imagine you want to trace all changes of a piece of document, not the whole document. How a piece of document is firstly too small, then is getting bigger with a lot of information in it. In this period of grow it is sometimes deleted without any pieces left.

I haven’t done in my life any Office application. Everything that I have done in this field is just reading and watching how the big players develop big packages of products.

http://googledocs.blogspot.com/2008/02/stop-sharing-spreadsheets-start.html

I think that the next step is to enable users to create their own forms by a spreadsheet tool pallet and every input data to be saved in the spreadsheet, which of course can not be shared. This way design a small form app easily.
It seems a useful stuff for a small business to have this fast communication with its community.

IBM’ s DevEngage and Zoho Creator are applications which first lets you to design the form and then creates the DB, but the letter is too function less, if you let the user to start from its DB, you can enable him to create a powerful form(s) application.