Google Wave was announced in May 2009, we received invites in few month and began to study it. As GoogleDocs GW has the possibility of collaborative text editing, which uses OT technology. There are also some advantages: you can transform document sections into the “structure”, and add gadgets and robots. We discussed our projects and worked on them in GW, and in general we liked this tool, and the presence of some nuisance gave us opportunity to creat many interesting ideas on improving the functionality and interface.Especially we felt the lack of shortcuts of folding and unfolding all the sections of the document. The idea of putting each task in appropriate context was also mentioned.
Vladimir Semenov, our web-developer, began researching the possibility of context task setting and handling the regular expressions by the robot. He shared his idea of creating the extention which allows to fold/unfold the parts of discussion by shortcut with his group-mate Sergei Khegai (Tomsk State University of Control Systems and Radioelectronics). Sergey got really interested in this idea and began working on it in his free from work and study time.
Two months later the extention for Google Chrome and robot (which could handle the tasks in the context) were ready. Now architecture of our tools based on Google Wave looks the following way:
ProjectVolna module scheme via Google Wave
More details about the Robot API.
Life in the scheme
Let’s consider the interaction scheme between the user and our system.
Tasks in the wave sre associated with a tasks list in the gadget as follows:
1. The user writes regular expression in the text (for example, the word “task” or “export” in parentheses).
2. The robot finds this expression in the text.
3. The robot put the necessary data into data base and generates a link.
4. TaskGadget finds that new task there and shows it in your list the next time.
The window of filling in form is necessary to be open near the regular expression in the wave, rather than in a separate page or tab. This was realised the following way:
1. The user clicks on a link which was generated by the robot at the 3rd step of the previous description.
2. Link clicking is intercepted by the extention.
3. Extention creates iframe (empty box), in which the source address (src) uses this link.
4. The browser receives the form from our base and loads it into the iframe.
The interaction with GoogleCalendar also takes place, but about it the information is further.
Photos of the robots work organizers:
Vladimir Semenov, Sergey Khegay
Dispute “GUI vs. Cmd” and other interfaces
“Which interface is more convinient – text command or GUI?” is the eternal question. We had a long holy war: how to organize more convenient user interaction between the “tasks in the text”, “waves search” and the “export as HTML” tools. We had two development variants:
— windows with GUI-forms: it is more understandable for beginning users and does not require remembering the command parameters (date format for example);
— direct commands input in the text of the wave: it will increase the speed of receiving the command by robot, and we all know that all computer geeks are ready to go into details for their own time saving.
The first version of the robot accepted text commands only. Later, when we decided to move to the GUI-form, the text commandsremained as a part of capabilities. Now we have two-ways tools as a result.
GUI vs. Cmd for tasks interface
The difference between usual users and geeks is in formulation of the task:
— Acquainted to window forms user begins with writing “task” in parentheses. The robot handles this word and converts it into the link. Then the user clicks the link and specifies the parameters of the task in the appeared window (iframe).
— Acquainted to command prompt user writes right in the command line “(John Smith task).” In other words he defines all the main parameters of the task: task performer, date, (and sometimes other parameters). Formulation of the task is over at this step.
A list of the tasks inside the wave
The text of the task is often presented by a few words only. Almost always it is necessary to understand some part of the contextwhich this task is referred.
The TaskGadget basic idea is to make the transition from the task list to the context:
TaskGadget. The transition from the task list to the “context”
Tasks are sorted by date on default. Each task in the gadget contains a link to a message where the task was set. By clicking on the task near the gadget the discussion (the context of the task) opens.
Aricle export interface
At first, we realised the export by the simpliest way: only one selected message could be exported from the wave. After the experiments, it became clear how to organize the structure in the article. In this case the publication is configured separately for each blip (the messages in GW are called like this). Here is the article in the folded form:
Example of article structure inside the wave
Each message can be included in or excluded from the export. If it is needed the robot marks each post with “+” or “-” which indicate if the the blip is exported or not.
Forms for export settings
Examples of the messages. Upper one with a “+” is included for export. The one below is marked with a ‘-’ and included for export.
Each “+” or “-” is a link and when you click it you can change the status of the blip’s export option. GUI-forms are used for this purpose:
Google Chrome Extension
WaveShortCuts extention performs actions which GW lacks. Here is the list of these actions:
WaveShortCuts Hotkeys
We often use two highlighted here shortcuts in our work. By their means we can highlight sentence or extract of the text on any website, press Alt + C, and then insert this fragment into the wave as a link to the website where the text was taken. It is awesome, isn’t it?
When using shortcut the extention generates a command for GW client. Accordingly, the extention needs the rights to send commands to GW from the user’s name. GW reacts cautiously in this situation, and users are often scared by such a notice (it appears when you install our extention).
Requesting access to Google account
To work with links insert the extention needs the access to the list of website which the user visits. So there will be one more chilling message during the installation of the extention:
Dear developers, try to avoid such messages while developing your extentions 
Extension published at Chrome WebStore
While working on reducing the entry threshold of new users we discovered that one of the difficulty is the extention installation. Many links and buttons confuse new users. We decided to move from Google’s code-hosting to WebStore.
This challenging quest is detailed in this wave. If we fold all blips in it, we can see the following structure:
Sections of the wave where we discussed the WaveShortCuts location at WebStore
Notification settings and work with Google Calendar
It was required to set all kinds of notifications and synchronization with different mobile devices to organize regular work.
Jabber notifications are realised by adding our own robot directly to the user’s contact list, texting and synchronization with mobile was realised via Google-calendar, because texting from GC is for free and it is more convenient to work with tasks using calendar.
The screenshot of the page: setting up notifications
The Google-calendar connecting
Firstly, we wanted to link the robot with a user’s personal calendar. But in this case the problem of synchronization appears: if the user changes or deletes a task in his own personal calendar, then these changes have to be handled and saved in the wave. This process is pretty difficult technically.
We make it different way: the robot creates the calendar, and shares access to the user.
We can’t share the calendar if the user has not activated the GoogleCalendar service. That’s why we could not avoid the bad repetition in the calendar activation interface (screenshot is above) : warning words and exclamation marks.
As a result, having learned a lot we unload all synchronization tasks to mobile Google. But there still was a problem, it was very difficult for the average user to understand how to comlete all the set ups. So we redesigned Google’s instructions and wrote our own instruction for setting up Google calendar on mobile devices.
Few words about the future of the Platform Odessa architecture
Everything wonderful what can be found in GW has not been developing for long time, even on the contrary. This year we understood that we need to develop the service. In order to develop it, we must find an alternative to GW. Google has handed over all the sources and knowledge on the GW project to Apache Foundation. The Apache project started WiaB — Wave in a Box (now there is an alpha version of this product). We began to research the condition of the project and made the following conclusions:
— the development direction of WiaB is not it is not clear;
— WiaB doesn’t suit for scaling;
— architecture of WiaB doesn’t support our business logic enough;
— there is a big problem with the documentation, it is more likely to be absent than to present;
— great coherence of the server and client code;
— in fact, the best advantage of WiaB at the moment is well implemented OT-editor, as for the rest – there are more disadvatages;
— finally, we have not many java-developers.
We asked ourselves the question: are we able to develop our own platform? One of the greatest challenges of the OT has already been realised in Share.js. Moreover, we have already has ready solutions for scalling. Because customers always keep the connection to the server, it is necessary to use server solutions for efficient use of resources, that will allow us to support long-lived multiple connections inexpensively. As a good solution in this case was the use of asynchronous (non-blocking) servers. And thet we decided that there are no unsolvable tasks in architecture.
So finally, we decided to create our own service Rizzoma based on own platform. Thinking on the certain technologies needed for each module we came to the following architecture vision:
Slide of our presentation on OdessaCamp
We have choosen Node.js or Tornado as non-blocking servers. The choice fell on Node.js, because:
— ShareJS was written for Node.js;
— the part of the software code can be used both on the server and the client. There is no need to switch the languages;
— platform is being actively developed and there many libraries are released for it, for example, Yandex has released its own framework.
CoffeeScript was chosen as development language due to the presence of syntactic sugar, especially compared with a simple Java-script.
We chose the CouchDB database:
— document-oriented database that best suits our business logic – a lot of hierarchical things, and it’s more easier for document-oriented database implementation;
— CouchDB requires fewer connections between items, which will facilitate scalability in the future.
We will support OpenSocial standards and all the gadgets which have worked in the Google Wave (Orkut, MySpace, etc.) will work on a Odessa platform.
We also plan to implement the federation. Our server should to communicate (exchange waves) within WiaB, Novel Vibe and other compatible servers.
Sphinx as a search engine. Simple scheme of working: the datas of the SouchDB changes will fall in the index, which had already come to be searched. All queries will be serve by Sphinx using tag, time, access levels, etc. In this way we obtain a high query performance and minimum db impact to server load.