Rich Client Wiki User Interfaces
The Wiki is an editable webpage. Wikis allow users with the right permissions to alter the
contents, and viewers with the right permissions to see the alterations and/or the final state of the
content. To alter the contents, a user clicks on an edit link and is presented with a text area
containing a textual representation of the page. This textual representation could use simplified
markup that is later rendered as html. When a Wiki page is edited, the changes are versioned.
What characterizes a Wiki User Interface is the ability to change the content and layout of a Wiki
page using editing tools that use the same widget set as the page itself, thus creating the
impression that the page is inherently editable. In a Wiki, the editor uses the same widget set as
the contents, whereas when a webpage is edited in a content management tool that is not a Wiki,
the editor uses a different UI library and widget set from the webpage. Another feature that
characterizes a Wiki is the lifecycle that the editing of content entails and the self-contained nature
of this lifecycle. In a Wiki, there is a two-state lifecycle involving two states ‘Editable’ and ‘Fixed’.
A Wiki page starts with the default state ‘Fixed’ or non-editable until the user performs an action
on the page to make it editable. This action moves the page to the ‘Edit’ state wherein the editor
appears and allows the content to be edited until the user performs an action on the page again to
make the page non-editable. This moves the page to the state ‘Fixed’. The lifecycle remains
entirely within the Wiki page, or in other words, the Wiki page is self-contained for content
management. Non-Wiki content management tools use an Edit-Deploy lifecycle where the
optional deploy step is required if the content management tool cannot operate on the deployed
Wikis are thin client user interfaces because they were invented before the advent of
Asynchronous Java and XML. Thin clients expose the request-response model of HTTP to the
user by requiring a page submission whenever data persisted on the server has to be accessed or
modified. Page submissions cause a refresh of the whole UI. The core difference between a thin
and a rich client user interface is the granularity of change of the UI. For a thin client, the
granularity of a change/refresh is the whole display area whereas for a thick client, parts of the
user interface can be changed independently of others.
Many of the web backend programming models in use today take the request-response
constraints of HTTP for granted. For instance, servlets, JSPs, PHP and perl have
post/get/request handlers which operate on streams. Even when the backend models are totally
separated from the UI, as in EJBs, the front end still needs to be tied in to the backend using a
layer of servlets or JSPs which work on the basis of requests and responses.
Wikis reflect the thin client paradigm because editing pages requires the submission of the entire
page or of a subsection. The use of subsections or portlets does not really change anything
because editing a page causes the whole page to be submitted, though just a part of it may be
edited at any given time. Rich client applications have UIs that can alter and refresh parts of the
screen. In a rich client application, certain widgets on the screen can be selectively hidden, made
visible or altered without disturbing the rest of the UI real estate.
Thin client applications can be given rich interfaces using front end technologies like Ajax. Ajax
without the page having to be submitted. Supported on most browsers, it is used in portals like
google maps, google suggest, and expedia. However, there exists no technology similar to the
thin client Wiki that exploits Ajax. A rich client Wiki for Ajax could potentially bring to Ajax UIs the
same ease of use/creation/modification that Wikis bring to the thin client world-wide web.
It was in the course of our work on the Floranta project (http://floranta.sourceforge.net) that we
discovered that the UIs we had been using to simplify web embeddable collaboration tools could
also act as the basis of a Rich Client Wiki. We believe that the applications best served by the
technology would be document review and project management (applications for which thin client
Wikis are also eminently suited).
Rich Client Wiki
Here is a picture of a prototype rich client Wiki built using applets.
The cartoon board you see above is editable, just like a Wiki. To edit one of the notes, for
instance, you click it. In the example show below, the user has clicked on the note that says 'Why
are you staring at me like that?'
Once a note is in the edit mode, the contents of the note can be altered. The tooling needed to
change the contents of the note is all in the webpage itself, as is customer in Wikis. Once the
note has been edited, the user clicks outside the note to submit the change to the server. The
new note becomes part of the picture once again. Notes can not only be changed, they can also
be moved or resized. The pictures can also be altered. For instance, the url of the picture of the
girl is changed to the url of the picture of the boy below.
The result is
as one would expect. The card saying 'Why are you staring at me like that?' has also been
moved from its position (it has been moved a little to the right).
This example has demonstrated just a little of the flexibility, granularity and richness of user
interaction made possible with a rich-client wiki. Following are tables that compare thin client and
rich client Wikis.
Thin Client Wiki Rich Client Wiki
1. Content is editable Content is editable
2. The editor is in the web page The editor is in the web page
3. Changes are visible to all viewers Changes are visible to all users
4. Changes to the content are versioned Changes can be versioned
5. Wiki states can be tagged and rolled back to The same is possible here as well
6. It makes web content modification easy It makes content modification easy
7. Used for content & project management Used for content & project management
8. Great for asynchronous collaboration Great for asynchronous collaboration
Thin Client Wiki Rich Client Wiki
1. Page submitted to edit the wiki No page submission is required to edit it
2. A relatively large portion of the page is edited A small portion of the page is edited.
3. Size cannot be accurately specified Size and shape of the edited portion can
be accurately specified
4. Links are an important part of the Wiki Links are not as important
Project Management Tools
A rich client wiki is a great UI for eXtreme Programming planning and can be used to represent
requirement trees elegantly. Each node in the tree would map neatly to a note or grouping UI
element in the wiki. In the example below, a number of cards are seen with numbers representing
estimated effort. The total effort is automatically tallied at the top. This UI lends itself to task
negotiation and prioritization in a collaborative setting.
The cards can be moved to different states to track the progress of the work effort. This
additional functionality is not really part of the wiki infrastructure. It is created by embedding
content in the rich client wiki just as it is embedding into portlets.
Customer Relationship Management Tools
Customer relationship management tools focus on the creation of content for display to users.
This would consist of regular thin client webpages or rich client webpages marked up with triggers
for the display of popups. The popups themselves are invisible elements of the Wiki which are
made visible by the triggers set around the Wiki. The following screen taken from google maps
Also possible is the insertion of collaborative applications into the wiki. What is interesting in this
instance is that the collaborative tool (the chat tool) is located right where the user's attention is
directed. There is no need for the user to shift his/her attention away from where the work is
Document Management Tools
The rich client wiki can be used to facilitate document management as follows. Documents that
are stored in notes or on the web become rather static entities. The comments and the contents
of the documents become separated. With a rich wiki, it becomes possible to leave comments on
the documents. The documents could be scanned to gifs or stored in some more amenable
What makes the possibilities of this technology more exciting is the fact that free form markup
becomes possible as well. When the user draws on the document, the lines are congealed into
notes just as with any other marking on the document. The document with the markings would be
shareable on the web or on notes, and folks would read comments on the document and leave
their own in a very natural and easy manner.
Imagine books with readers' markings, lecture notes, and putting the fun back into document
The cleanest approach to building a rich client wiki backend is the association of wiki data with a
'location' which is any unique string, in this case, a URI. The problem then becomes one of
building a distributed database with the following operations - READ, WRITE, CHANGE, DELETE
- that operate on a location and in the case of CHANGE and DELETE, the record identifier.
The CHANGE operation is analogous to the thin client Wiki save operation (the culmination of the
edit). The READ operation is analogous to displaying the Wiki page. The DELETE operation is
analogous to removing a page from a Wiki. The WRITE operation is like adding a page to the
These operations are often used in whiteboard architectures as well, and therefore are ideal for a
collaborative system (a collaboration server).