Assistant program?

John Richard Moser nigelenki at comcast.net
Fri Aug 19 22:55:19 CDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In a paper (''work in progress'') entitled "Designing a Secure and
Friendly Operating System," I wrote a section about an "assistant" to
help the user with the system, primarily to deliver security concerns
through.

Following, I drew up a client-side header for the library used to
interface with the assistant to see how simple the API could be made.  I
did the folowing:

 - 1 initializer function
 - 9 configuration functions
 - 3 message control functions
 - 1 structure
 - 26 constants

I believe this may be a viable interface with one minor change to one
message control function to make it more robust.

This looks like it'd be simple to implement if I had time.  The question
is, would anyone actually care?  The basic idea is to give applications
an interface to a daemon to have it supply assistive support to new
users; primary function of course is to deliver security concerns.

Following is a cut-out of the section of my paper.

==================
Inline Information Delivery

Many attempts have been made to supply an “assistant” or “helper” for
guidance through cectain programs.  These have ranged from the
simplistic “Click here to begin” message sliding across the Windows 95
start menu to the Microsoft Office “Office Assistant”[61] constantly
suggesting help based on user activity.  While all of these have been
unsucessful, the concept itself may be useful if implemented properly.

The major visible flaw of these assistants was that they were only
coarsely configurable.  The available settings were typically “on,”
“off,” and “go away for a minute”[62].  They would either offer help on
everything the developers foresaw, or nothing at all; and they would
repetedly offer help on the same thing[62] after the user successfully
followed or declined the offer for help.  This design fails to provide
for learning as a process, priority or skill level information, or
requested help.

A better assistant would give multiple classes and levels of
information, allowing the user to essentially set the verbosity of the
assistant in a fine-grained manner.  The available classes could include
using the operating system, basic feature explainations in new programs,
or security considerations.  With the level being set lower, the
assistant would bring itself to the user's attention more often under
the assumption that the user is less experienced and desires more
guidance.  Furthermore, the assistant should be tunable per-application
as well, with each starting set to follow the global settings.

An assistant would need to allow for automated learning as a process.
Each time something is brought to the user's attention, it should be
noted that the user saw it and followed or dismissed it.  Depending on
the action taken, the same informational alert may or may not reappear
when triggered again.  In this way, the user would encounter the
assistant less frequently as he continued to use the system.
Furthermore, if a new version of a program has a new feature or other
change, it would be able to alert the user with only the relavent
information to teach him about the new functionality.

A proper assistant would need to allow the user to dismiss, queue,
recall, and revisit alerts that were no longer active.  By pressing a
hotkey such as F1, currently active but not shown alerts would become
available.  In this way, the user may dismiss or otherwise cause the
hiding of any given alert, but still recall the assistant at any time to
access alerts relavent to the current context but not shown at the moment.

An assistant would have to give unintrusive visual cues to the user, but
still be attention grabbing.  A small, floating icon with non-linear
physics, subject to acceleration and deceleration, would be sufficient.
 It would have to “stick” to the mouse when the cursor reaches it, but
be able to break free if the mouse is moved suddenly, allowing the user
to manipulate it to move it out of the way; of course, clicking and
dismissing would need to be possible as well.  It would also be good for
the icon to move slowly away from the mouse cursor, but not fast enough
that it would be difficult to get the pointer over and entrap.

The text provided by the assistant should be brief, explaining in most
basic terms the alert being raised.  This will ensure that the user does
not have to spend large amounts of time reading any given alert; a half
screen of text will easily signal a user to not bother reading.  Still,
a full explaination is often useful; the assistant should be capable of
allowing a user to request a deeper explaination if he really wishes to
learn.  Linking to other documentation in these deeper explainations
would also be advised, as interested users would likely want to find
further reading on the subject; those who request more than the minimum
of necessary knowledge should be given every opportunity to broaden
their understanding.

The assistant should be capable of producing interesting visual effects,
such as moving to a specific menu or button, highlighting text and
widgets independent of the application, and producing word bubbles.
With careful communication between the application and the assistant, it
would not only be possible for the assistant to guide the user through
certain tasks such as configuring e-mail encryption or learning about an
extension he installed in Firefox; but also to give visual cues about
what the alert wants to teach the user.

The assistant itself would need to be designed as a daemon run by a
user.  While multiple instances would be unacceptable for any given
user, the daemon would be run by and as the user, and one would be
allowed to run for each user.  This would allow central management of
the assistant by a single program.  The programming interface would be
handled by a library supplying API calls to ship information to the
daemon; while the user interface would be handled by the front-end on
the daemon, allowing for various desktop environments such as GNOME and
KDE to match visually with the assistant.

It may also be important to introduce the user to the assistant as part
of the assistant's daemon.  Luke Swartz' paper, “Why People Hate the
Paperclip”[62], notes that many inexperienced users did not understand
what exactly the Microsoft Office Assistant was supposed to do; one even
commented, “I don't know what the hell it was for.  There's no manual
that tells you what it does.  The only thing I'm sure it does is it
wiggles when the computer's working.”  Providing a brief introduction to
the assistant on its initial load would serve at least to inform the
user about what it is for and indicate how to disable or configure it.

As with all alerts, the initial introduction of the assistant should be
brief, but complete.  It should explain the function and importance of
the assistant, for example with security alerts.  It should also notify
the user of initial innundation so that he will not simply switch it off
after a few minutes.  A potential description for a theoretical
assistant called “SOMOSIS” is shown below.  Note the brieverity and the
use of “hot topics” such as identity theft and viruses in the second
paragraph.


  Welcome to your new Linux system!

  Please read this introduction carefully to prevent identity theft and
  viruses and to protect your privacy.

  While we have done our best to protect your system from worms and
  malicious hackers, we cannot protect the system from the user in
  control of it.  Therefore, to protect you from identity theft scams
  and viruses, we have created SOMOSIS, Simple Online Memoranda
  Offloading Secure Information Strategy, to help protect you from
  common scams and help you make security-conscious decisions.

  SOMOSIS appears when a security concern is first raised.  It is
  designed to appear less frequently as you use your system by not
  displaying the same messages repeatedly; however, the first few
  alerts, mainly explaining anti-phishing tools and encrypted e-mail,
  may be seen rather quickly.  By explaining such tools as they are
  first needed, we hope to help you to protect yourself from those
  dangers we could not handle automatically.

  SOMOSIS may also be configured to act as an assistant and teach you
  about the general use of your system and your applications.  This
  functionality is configurable to a large degree.  Would you like to
  learn more about the SOMOSIS system?


During the delivery of the initial introduction, the assistant itself
must be visible.  The icon used for security messages should be the form
of the assistant at this point, as this will be what the assistant will
use.  Functionality not related to security should be disabled by
default; if the user choses to follow the advice of learning more about
the assistant, then the other forms should be shown and explained.

The most important part of the assistant is the application-level
support.  The assistant itself should not be able to monitor the system
and attempt to discern when certain events should happen; rather, the
application itself would request to the assistant that the user be given
an alert in a certain class at a certain level with a certain
identifier.  Logs of previous activity would be stored by and accessed
through the application utilizing instrumented communication between it
and the assistant; the assistant should abstract itself away from
application-level assistance as far as possible.

To clarify, the final form the assistant would take would be a simple
user daemon communicating with applications interested in providing
assistance to the user.  The assistant daemon itself would request lists
of logged, active, and inactive alerts from the connected applications
when necessary using an interprocess communication mechanism, such as
Unix domain sockets; and otherwise would handle requests sent to it
through such interprocess communication from applications capable of
providing user assistance.  In this way, the management of alerts is
handled by each application; while the display of them is handled by the
daemon.  As a result, not only is information about previous alerts
stored in a decentralized manner; but such information is only
accessible for currently running applications.

To summarize the theory behind the assistant as described here, each
application can supply to the user a set of alerts delivering different
classes and levels of information as a learning process.  As the user
accepts or dismisses the alerts, the application notes this change in
status and refrains from displaying them in the future.  Thus, the
assistant brings alerts to the user's attention less frequently as he
uses and gains experience with the system.  It is theorized here that
previous assistants in various systems failed because of their lack of
granularity and failure to implement learning as a process.


[61] http://en.wikipedia.org/wiki/Clippy
[62] Swartz, Luke.  Why People Hate the Paperclip.  Stanford University,
June 12, 2003.
==================

Picture of Thunderbird with a theoretical assistant displayed (use a
LOCK icon instead of an ! for security alerts?) attempting to teach the
user about encrypted/signed e-mail and help them generate a gpg key is at:

http://i2.photobucket.com/albums/y10/bluefoxicy/doctored_tbird_osmosis.png

(I didn't want to propagate a 112k image and cause gigabytes of
bandwidth usage)

Attached is a diagram of the assistant application/daemon communication
structure.

Also attached are the header and consts.c (which would become part of
the theoretical library) that I created to explore what kind of an API
such an assistant would need.  There is no supporting code as of yet.


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDBqmlhDd4aOud5P8RAqP9AJ9jemMOjcuc75OGf/7jR1KM2CyUcACeIiOW
wW7qhr5Hj0OecvwTy/uHH90=
=JVdK
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assistant_daemon_dia.png
Type: image/png
Size: 6439 bytes
Desc: not available
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20050819/80541b73/assistant_daemon_dia-0001.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: consts.c
Type: text/x-csrc
Size: 2715 bytes
Desc: not available
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20050819/80541b73/consts-0001.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: somosis.h
Type: text/x-chdr
Size: 9579 bytes
Desc: not available
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20050819/80541b73/somosis-0001.h


More information about the ubuntu-devel mailing list