Heh, I am not sure if there’s any more time… I just posted my proposal yesterday late at night. On the other hand, the webapp seems still active, so I may have the possibility of changing something. Here’s my proposal:
Abstract:
I propose to create a jabber help bot, as a module for ejabberd. It would give the user help relevant both for his client application (if this information was available) and for the server. The module would beeasily extensible to provide documentation for new client applications. This would create a jabber tuned method of letting the user reach the documentation. A good metaphor of my project would be to create a help system for XMPP/Jabber that would be as natural for it, as the man pages are for the Unix shell.
Description:
Motivation
==========
Good documentation is a factor which can decide whether a technology
will succeed or not. However, good documentation is not enough. Also
crucial is the way the documentation is made available to the end
user. Ideally, such medium should be naturally incorporated to the
environment, and it would increase user’s productivity and comfort.
An example of an exceptionally good (in my opinion) help system are
Unix shell’s man pages. For Unix users performing `man 1 foo’ is as
natural as for a philologist to check a word in the dictionary. Users
know what to expect from their man pages. Man pages don’t interfere
with the normal way of using the shell. Finally, man pages don’t get
in the way of power users.
On the other hand, a poorly designed help system can be very
distracting and irritating for the user. Think of Microsoft Bob [1] or
Clippy [2], the always-getting-in-the-way help assistant from
Microsoft Office 97 and 2000. It would fire itself in the most bogus
and unexpected moments, taking focus and greatly distracting the
user. Attacking the users with lots of irrelevant information caused
that users just didn’t believe that Clippy can be of any help.
There are two ways how the problem of helping the users is typically
solved in jabber client applications, help web pages and a special
help function in the program. Both have some serious drawbacks.
In order to browse web pages the user needs to run a web browser,
which is a completely separate program. As for help functions built in
client applications, they differ from program to program, so there’s
no intuitive and general way of asking for help. Secondly, this
functionality is replicated in every new client, which means lots of
unnecessary work. This is just not the best way of doing it (not to
mention that there’s nothing of the elegance characteristic for the
man pages).
Moreover, there’s a really serious XMPP-specific problem for these two
media. The functions available for the XMPP user depend not only of
the client he or she is using, but also on the server on which he or
she has his or her account. So, the client based help function (no
matter whether is integrated with it or on a web page) won’t ever be
able to help the user in all the situations he would want such help.
So, is there a really jabber way of making the documentation easily
available to the user? Is there a jabber equivalent of man pages?
XMPP is primarily designed for instant messaging. Sending and
receiving messages is the thing that users do most of the time. So, it
is clear that *this* is the right way of reaching jabber users with
help.
Method
======
My proposal consists of writing a help-bot module for ejabberd [3]. A
help bot exists for the OneTeam jabber client [4] (for a flash
demonstration of its operation see [5]). It displays help specific for
the mentioned jabber client. Taking this framework as basis, I would
introduce the following improvements:
1. The documentation would be organized in submodules. Each submodule
would contain documentation specific for one client program (that is,
OneTeam, gajim, tkabber, etc.). Apart from that, there would be two
special modules. The _generic_ module would contain the most general
help, which applies to practically any jabber module (this would
include some jabber tutorials, for users willing to explore the
possibilities of jabber). The _server_ module would contain
documentation specific the services available on that server (for
example, available transports).
2. Basing on the information from the client program, the bot would
decide which subset of the available documentation is relevant for the
user (that is, someone using gajim should be shown documentation from
the modules _gajim_, _generic_ and _server_). When no information about
the client is available, only the _generic_ and _server_ submodules
would be used.
3. A simple format (XML-based) for providing additional help modules
would be created.
4. If there’s enough time, I would try to enhance the bot’s
conversation abilities using some language engineering techniques
(that is, I would try to make it respond to questions instead of only
simple commands like “help discovery”.
Benefits for the Jabber/XMPP community
======================================
The Jabber/XMPP community would achieve a number of benefits from my
project. First of all, XMPP would get an elegant, natural, and
consistent providing its users with help. Secondly, these help would
be independent from the client software. Thirdly, the system would
make all the help the user would want available in one place.
References
==========
[1] http://en.wikipedia.org/wiki/Microsoft_Bob
[2] http://en.wikipedia.org/wiki/Clippy
[3] http://ejabberd.jabber.ru/
[4] http://www.process-one.net/en/oneteam/
[5] http://www.process-one.net/tutorials/demo_oneteam_bot_avatars_viewlet_swf.html
