Garo Garabedyan- a private blog

I have got a conversation with Luis Suarez, Knowledge Manager, Community Builder & Social Computing Evangelist in the IBM Software Group division (www.elsua.net/), through ITToolBox network.
I have received the right to publish it in my blog.

TO Luis Suarez FROM Garo Garabedyan
http://garabedyan.wordpress.com/2008/05/26/migrate-e-mail-conversation-to-a-wiki/
Above is a blog post, where I try to dream about a new automatic way to migrate from long e-mail conversations to a Wiki.
Based on a service, which creates a wiki page for every conversation (by default recognizes a bunch of e-mails as a part of a conversation) and automatically gives rights of Read&Write or only Read to the collaborators according the TO, FROM and CC tags.

I have downloaded your presentation: Тhinking out of the inbox more collaboration through less email.

4th slide- a map of people in a collaboration. I think that in IBM was a social tool which tries to present the relations in a such graphical diagram.

15th slide- e-mail and wiki. Using attached documents in e-mails is not very well presented in wiki. Which particular engine you picture, is there a such engine which provides Document revisions (like the Wiki) for Office files. I will
be very interested in such a service.

I am a student and I will be happy to hear advise from you. Do you share some of my views?

Garo Garabedyan
Sofia, Bulgaria

TO Garo Garabedyan FROM Luis Suarez
Hi Garo,

Thanks a lot for the feedback comments and for the information details! Very insightful, indeed, and glad I am not the only one thinking along these terms as well. Very very good!

I think your idea of an automated process that would convert e-mails into wiki pages with the right level of access and interactions is something that would prove really really useful and I hope to be able to see it at some point in time. Alas, we are not there yet, at least, from what I know of the various wiki engines that I have been exposed to so far, but, like I said, it would be really nice to see it at some point! Because it clearly indicates the way we would need to follow!

With regards to your comments on the slide deck, yes, inside IBM we do have that tool that provides such visualisations and it surely provides a really nice functionality of identifying your experts from a specific community, as well as the weak links from that social network, which will prove to be very handy, specially when you are looking for the right people for the right job!

On the slide of the e-mail and the wiki, I must say that the slide is not from me, the graphic is from Wikinomics and it doesn’t represent a specific wiki engine that supports extremely well attachments, in fact, very few wiki engines do. Wikis are more down to earth towards building content on top of each other’s content but more down to text and hyperlinks than attachments, so I doubt they would ever provide such excellence of support for attachments that you are asking for. If you look into Wikimatrix you will see how not many of them place the focus on attachments, which I think is the right approach. It is more about building the content linearly and in a single interface, instead of having to force people to attach, detach, download, upload, that specific file. I think that was not the purpose wikis were designed for in the first place, I am afraid.

Thanks again for the really nice feedback! Greatly appreciated!

Cheers!
Luis Suarez

TO Luis Suarez FROM Garo Garabedyan
Hello,

Thank you for your answer and that you have spent time reading my message.
I want to keep a conversation with you and with a project manager of a close to this topic product of IBM.

I think that Wiki pages over E-mail conversations is possible. I can give you short examples of some conversations which will look beautiful if are processed over Wiki.

When I have saw that diagram about sending e-mails with attachments I thought that it is already implemented to have a Document revisions of Office Docs (which I am passioned of). I think that there are a lot of things to be done in this approach. Recognizing the user behavior with Ajax in order to conclude if the user is Adding, Erasing or Editing content, and on the base of this analysis to form a very successful diagram of revisions of every piece from the document and for the whole document. [ http://garabedyan.wordpress.com/2007/11/18/ajax-wiki-editing/ # Document revisions]. This way solving a big problem of IT theory, recognizing document revisions.

I believe that my dream of a wiki over e-mail conversation is possible and I think that eventBased Algorithms and Data ( http://garabedyan.wordpress.com/2008/03/04/data-flow-processing-eventbased-algorithms-and-data/ , http://garabedyan.wordpress.com/2008/04/27/event-based-content-editor/ ) are able to do this job.

I truly thank you and I ask you to contact me with a specialist in the practice field, I want to share my thoughts with both of you.
You as a philosopher with a wide range of ideas.
He/She as a practical implementor.

PS: Social networking can truly change the nowadays web, turning it into more safer and healthy world (http://garabedyan.wordpress.com/2008/03/08/virtual-world-as-a-place-to-meet-and-interact-with-people-on-web-page/).
A lot of my friends are becoming zombies while using their computers, I think that by presenting social connections while (i.e.) browsing web page surfers will be protected by this modern disease of IT workers.

Would you be so kind to paste some pieces from your message as comments to the blog post ( http://garabedyan.wordpress.com/2008/05/26/migrate-e-mail-conversation-to-a-wiki/ ). Now I am studying in Bachelor program in Technical University of Sofia- Bulgaria for 1st year. I work on the blog in order to find valuable remarks and use them in order to continue my education in Europe.

Garo Garabedyan

TO Garo Garabedyan FROM Luis Suarez
Hi Garo,

Thanks for the follow up and for the feedback comments. Appreciated. RE: “I think that Wiki pages over E-mail conversations is possible. I can give you short examples of some conversations which will look beautiful if are processed over Wiki.” > Oh yeah, I know PLENTY of those, too! Starting with this one! As far as I can see almost everything that would not be consider a one-on-one conversation discussing a subject of a sensitive or confidential nature would be considered possible to go into a wiki. And even in the latter example, it could still go into it, if it would be a fully protected wiki, which I have seen far too many. So from what I can see plenty of e-mails could have their space in the wiki-sphere. What I am just trying to say is that as soon as you work with attachments in e-mail that becomes more difficult to manage in a wiki, since wikis have not been built to store attachments, but more to build content ad-hoc amongst a group of people. That’s all what I meant.

With regards to document revisions, I am thinking that a similar thing is what you would get with Recent Changes, right? I mean, they are not as fancy and sophisticated as Office documents, but they surely get the job telling you who made those updates, when, and what content changed, which for the basic purposes of document revisioning may be good enough to get things going. Nothing fancy, nothing more complex. Just gets the job done. And you can syndicate that content, something Office documents don’t offer. So I would find them to have a bit of an advantage in that space, for sure.

Hummm, interesting that you say that e-mail is a collaboration tool, when it is not. Don’t confuse communication vs. collaboration. There are two completely different things. The fact that all of us have abused e-mail as a way to spread information does not mean it will make it as a collaboration tool. In fact, it doesn’t. It does such a poor job at helping collaboration flow in a natural way that it becomes a nightmare, after a few instances, so let’s just try to consider how wikis vs. e-mail, as collaboration tools just don’t compare. Issues like openness, public, awareness, co-creation, co-authorship, etc. etc. just won’t happen in e-mail whereas they really thrive in wiki systems.

With regards to your final comments on contacting a specialist in the practice field, I am sorry to disappoint you, but you won’t find any, main reason being that distinction I mentioned above where e-mail and wiki are two completely different beasts, one to communicate and the other to collaborate, so doubt you would ever find anyone out there in this area. And I think if you are trying to move forward in that direction to make that distinction as well, it would help you save a few headaches along the way.

And with regards to your comments about quoting some of the interactions through e-mail into your blog, I would be more than happy, in fact, I would be more than happy to carry out the conversation through the blog as it would help everyone else out there benefit from such exchange. So, by all means, go ahead and quote those bits and pieces and use a link to my main blog: http://www.elsua.net (I can’t track the links to ITtoolbox’s blog at the moment, trying to fix it as we speak) and will be chiming in accordingly.

Hope that helps and thanks again for the helpful comments and insightful feedback!

Regards
Luis Suarez

TO Luis Suarez FROM Garo Garabedyan
About Document Revisions:

http://alumni.media.mit.edu/~fviegas/papers/history_flow.pdf
Studying Cooperation and Conflict between Authors with history flow Visualizations
by
Fernanda B. Viégas
MIT Media Lab
Cambridge, MA 02139 USA
fviegas@media.mit.edu

Martin Wattenberg
IBM Research
Cambridge, MA 02142 USA
mwatten@us.ibm.com

Kushal Dave
IBM Research
Cambridge, MA 02142 USA
kdave@us.ibm.com

eventBased Content Editor, + eventBased Philosophy
http://garabedyan.wordpress.com/2008/04/27/event-based-content-editor/
http://garabedyan.wordpress.com/2008/03/04/data-flow-processing-eventbased-algorithms-and-data/
By using a declarative approach about the relations between pieces of the content which are fast (and asynchronously) edited by many authors (in example wiki, no one can know how many authors what exactly will edit) to: a) trace changes and inform the interested readers (authors), b) present an excellent data flow diagram of document revisions

Scenario about a):
You add an information about some event and present the needed stuff and declare relations of this stuff to the content about the weather forecast. Some people declare interest of the event.
If this forecast changes, the system traces which content is related to the changed one and informs the authors of the related content about the change.
Next, the authors update the related content by applying the change in the forecast.
You have two choices, to update the information or to not, depending what you think about the importance of the change in the forecast.
System informs the interested readers that a change occurs in the page about the event, if you have updated it.

Garo Garabedyan

TO Garo Garabedyan FROM Luis Suarez
Hi Garo, and me thinking that every single change that you do to most wiki engines would get registered into the system and therefore easy to track. Your comments below suggest otherwise. I am thinking as well that apart from Wikipedia I doubt there would be other wikis at that level and with level of complexity that you are mentioning and as such I doubt it would be even worth while tracking all of that activity. For what purpose, to track active contributors? Wouldn’t that be obvious already? To track doc revisioning? Hummm… interesting but I thought that doc revisioning would be done for documents, in most cases, considered critical or essential to the project or business, and for that I bet there are better tools than wikis, specially when you get involved with Intellectual Capital, Intellectual Property and IP Law.

I am certainly not disagreeing here with your point of view. I think it is a fascinating interesting new aspect of the complexity aspects of a wiki. I am just saying that perhaps a good majority of the folks who regularly use wikis don’t care, and therefore would not want to complicate their user experience.

Thanks for sending the links along! Will keep digging into your research, although with the travelling I am doing at the moment, I am not sure I would be able to get much done before end of June, but will try in between now and then and see how much I can get through.

Thanks again for very enlightening conversation. Take care and have a good one!

(Need to catch a flight to Munich)
Regards
Luis Suarez 

TO Luis Suarez FROM Garo Garabedyan
Hello,

I was busy this month with the final exams in my university.
I want to ask you about your opinion on using ontology in wiki pages.

You know how Wikipedia presents a lot of tags which indicates to the visitors that the information presented here can be a little bit old and not complete. If calling this as an ontology mechanism where people are free to write their opinions in natural language, but are free to mark some pieces of it as related somehow to something out there. Is this kind of collaboration commercially interesting.

I want to give you an example. Imagine a business application which handles all the tasks of the workers and keeps tracking what percent of the work they have done according their own reports. Is this replaceable by a custom designed ontology Wiki. Such a wiki which has tags (like XML) which lets editors to edit task page wikis by setting the percent of the done work.

Is the common application user interface tag presentable (with all the calls up to the database about types in check boxes and list boxes) and in this sense is editing a wiki page become more powerful? Editors can be free to bind this discrete values in such a way like they are in one DataBase and use them around the all wiki pages, when the letter is aimed to a business tasks.

I respect your professional view. What you thing?

Garo Garabedyan,
Sofia, Bulgaria 

TO Garo Garabedyan FROM Luis Suarez
Hi Garo,

Thanks a lot for the message and for the feedback details. I think you are on to something when you are proposing to put together a tagging / folksonomy infrastructure added further add to the contributions of a wiki. More than anything else because you are making the content of the wiki itself much easier to search & find it at the same time that you give people the opportunity to build a second entry of knowledge based on such tagclouds, as well as the overall content from the wiki itself. If you combine that with a potential fixed taxonomy, a limited, but original one, that a wiki may well have you are putting together some really good advantages towards encouraging knowledge workers to collaborate further having that massive index, or tagcloud, of key terms spread around the wiki.

Interesting challenge would be though how to put such folksonomy to the test of proving useful to the business and not just the knowledge workers. I can imagine that the business would be interested, but it would need to see the buy-in. It would work on an individual basis for each of the knowledge workers contributing, but not sure the business will buy it. In fact, there aren’t many businesses out there exploting the power of the tag in a business context to create dynamic taxonomies combining them with folksonomies and I guess that’s mostly due to the fact that people who have been managing those taxonomies in the past may not feel very comfortable with letting that control go.

Not sure whether you would be aware of this or not, but Thomas van der Wal, the guy who coined the term folksonomy, has done some fascinating research around the world of tagging and how it can improve the way people share information as well as find it at a later time. You may want to contact him and see if he would have some other ideas he could throw on the table on the kind of impact it could have on a wiki…

Hope that helps get some discussion going…
Thanks!
Luis Suarez

Yahoo! Answers is a service of Yahoo! which helps people to ask questions and receive answers from real people. At this post I will try to compare Yahoo! Answers, Forums and Wikis. Yahoo! engineers created this tool which characteristics are taken from famous to us services.

People use forums to ask questions and not so often to search for answers. The same users use wikis to search for answers (knowledge) and share knowledge. Yahoo! Answers enables people to search for answers and give answers in a more productive way than in Wikis and Forums.

Forums:

• Conversations like in chat rooms. People express independent views which are presented chronologically in respect of the time of publication, most publications are an answer to the last posted opinion

• There is no discrete topic in the forum posts. People talk about a lot of thinks not directly related to the topic of the forum discussion

• There is a social relation factor. People see each others’ opinions

Forums are not able to be searched for previous answers, this is a place for discussion where a conclusion is let in the hands of the hard writing attenders.

Wikis:

• Work is co-authored. People collaborate and produce a paper which fully represent their views, even if the letter are opposite (in such cases the both opinions are presented as parallel)

• There is a discrete topic of every wiki page and every piece of a page can be kept on the topic by every visitor with edit rights

• Wikis aren’t social services, people collaborate indirectly by document (article) revisions

Wikis are not able to store chronological events, document revision engine inside the service is not enough powerful to present the changes in such a way in order to understand the growth (development) of the ideas expressed in the page.

Yahoo! Answers:

• Every registered user is free to answer a question, to comment an answer (comments are attached to the answer and are chronological)

• Off topic answers aren’t boring the visitors. A policy for voting the best answer is presented to every visitor

• Yahoo! Answers is a social service. People earn ranks and points about better answers, they see each others profiles

Yahoo! Answers are too bound to the concrete question, there is no linking of topics like in the wiki. This makes answers to be only authored by only one user and no collaboration which in one good implementation can provide a more deep knowledge.

Yahoo! Answers and all its competitor Answer services are a powerful new Knowledge Management Services.

E-mail conversations as wiki pages are able to be edited by every collaborator in the discussion (mailing). Avoid long conversations kept in many messages, but keep all the important things in one place, and in the same time save all the revisions (every expression of though during the process of collaboration) in a more accessible and easy (user-friendly) way.

Initiator of a collaboration
TO:
FROM:
can Read&Write (R&W) the wiki
can give R&W access, can take back R&W or W only access

CC:
can only Read
as everyone else can receive Write access by someone who has such access

People can invite themselves to collaborate. But only the initiator has an administrative rights to kick someone out from the wiki.

A new way to migrate from the old mail style to the new Enterprise 2.0 with all the additional social networking tools based on this new way.
Installed onto a web based mail system, which can connect to your old mail message box and present its content to you as a conversation wikis.

Mail conversation consists of 2 /two/ atoms:

1. Revision of a mail message (negotiation). Adding, erasing, editing mail content. A concrete discussion on the work

2. General conclusion, advise, mark, note. Mostly used by bosses and leaders which present the future of the project.

1-> collaboration is made by repeating, declaring agreement or disagreement, not commenting (passive) (often by a boss who says which are the next steps to take only)

Agreement is an independent view of the user and is related to revision of the agreement content. Like a post in a forum.

A new wiki feature:

• Comment tag. Behaves like a forum post, is not editable by anyone else except the owner (its setter) of the tag. When the content in the tag is changed, the owner of the tag is informed. (examined in http://garabedyan.wordpress.com/2008/04/27/wikis/ and http://garabedyan.wordpress.com/2008/04/27/event-based-content-editor/)

Added on 25 Aug 2008: SocialText.com provides wiki in dashboard creation from e-mails. There is a deeply thinked policy behind this product feature. You receive an e-mail and if you want to share it with your team, just e-mail it on the dashboard (custom created mail address which automatically transmits the received data to the dashboard) and a new wiki page is created in it presenting collaborators in the team ability to edit and comment on this newly created wiki page. After the work is done you collect their work where and by whatever technology it have to be send.

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.

Editing wiki content with Ajax is more easy and fast. Special JS code can make a big step in recognizing Document Revisions of a wiki article.

Have you got enough time to press “[Edit]” and go to the editing page of the wiki site and find (recognize) what you have just wanted to edit. Here I draw the steps that you take when you want to edit a wiki-like page:

• find something or some things that you want to edit. (information that you want to precise, fix it)
• find and press the edit button for the page (in general the edit button for the area of text which you want to edit)
• new page with editing area is loaded in the browser on the place (in general when you don’t open it in a new tab) of the already red text (at which you remember the formatting and placing of the text and the places you want to edit)
• try to find place(s) of text which you want to change. Notice that now the content seems extremely different- the previous formatting of the content is lost- it has been converted into a plain text; to the previous content are added many special symbols (its important to notice that an array of symbols is forming a special symbol, so special symbols are a heavy weight visualization content) and the size of the content is increased extremely.
• editing (its important in some way to be familiar with some special symbols)

I believe that there is a better, easier way and more user-friendly to provide editing of a wiki page. Using Ajax you can let the user to edit concrete part of text and do it dynamicly without reloading the page, even you can keep the formating of the text and to not convert it (the formating) into special symbols.

What is the scenario (use-case) in the users view in this better way:

• find something you want to edit
• mark it (no matter is it a paragraph, sentence or few words)
• press special combination of button(s) or press a special button
• the selected content is turned into a textarea and according to the type of the selected content to the user are present special editing tools for the concrete aim
• edit
• press “Save” (or maybe “Update” is a better name of this button) or “Cancel” in order to save the changes or to ignore them
• getting the previous view of the page (not needed reloading it, just refreshing the edited text, for efficiency you can skip the last step is the content wasn’t changed- if it was pressed skip button, you can skip to check for changes if the user has pressed “save” and ask the server for the content).

In point 4 of the last scenario I was talking about this: Many wiki pages content special areas for adding notations, editing/ automatic creating of contents of a page, picture, table, part of an other wiki page, notes, references.

When this areas of content (or areas containing this kind of content) are edited its useful to present to the user specific tools for the concrete area (to make this tools visible). Else you can just let the user with a minimum amount of editing tools and provide way of choosing viewing some extra tools.

The text area is supposed to not present in general the content by special symbols, but like the content should look like. The user can be provided with an additional button (or tab) in order to get a plain text and special symbols of the content- the source code of the concrete text.

Many times people browse wiki pages while they are finding information. When they see some small mistake or not complete truth, they really don’t have the time to go to the edit page and fix the problem. I think that it is supposed to be more easy for them to use this kind of editing and this way to keep wiki content in a high quality.

May be it is hard to keep the same pixel place of the text which has to be edited you can enable something like this:

• user marks text which he wants to edit
• user presses Ajax powered button (or in TiddlyWiki double-clicks on the tiddler (text post))
• text turns into a textarea but the marked characters are again marked (in order the user to find what he was just reading) (with or without the special formating symbols)
  • There are web based word processors using html (of course not the all amount of tags, but limited one) as content of documents. In example Google Docs, WordPress.Com

Document revisions
There is a big field in Information Technologies which tries to point the differences between many revisions of one text. With an intelligent Ajax application, a wiki editing can be separated into 3 /three/ operations: Add, Erase and Change content. This way it will be clear what is the user doing and on which particular piece from the document. Google Docs do the same thing- tracing the user actions and concluding in Documents, Spreadsheets and Presentations and what are their intentions, but Wiki Ajax app can be better.

2 /two/ actions: Add content, Erase content can be recognized by a JS function which is called every time a change is made in the document. This way we can work not with paragraphs, sentences and words… just working with every symbol and knowing that it is possible after it (next change in time period) to be added another next to the previous added on (in the content). Or to recognize when a piece of text is erased and another symbol is added on its place or that there is no symbol added on the erased text.