Assistant program?

Matthew Paul Thomas mpt at canonical.com
Sun Aug 21 02:32:31 CDT 2005


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

On 20 Aug, 2005, at 12:55 AM, John Richard Moser wrote:
> ...
> 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.
> ...
> This looks like it'd be simple to implement if I had time.  The  
> question is, would anyone actually care?

Previous assistance systems seem to have failed for a combination of  
reasons.

1.  People assume (often correctly) that if the software isn't smart
     enough to be easy to use in the first place, it's not going to be
     smart enough to help them use it either, so they don't invoke the
     assistance function voluntarily. Example: anything in a "Help" menu
     or behind a "Help" button.

2.  Exacerbated by the previous problem, writing assistive text is
     unrewarding, so it gets done mainly by people motivated by either
     money or the mere satisfaction of authorship. These people, while
     well-meaning, often aim for word count at the direct expense of
     helpfulness. Example: much of the help in Gnome.

3.  The assistance is too difficult to author. Example: the Apple Guide
     in classic Mac OS -- Apple used it, but very few other vendors did.

4.  Useful assistance needs to be written by people who are (a) good at
     writing, (b) good at guessing/measuring the problems people have,
     and (c) knowledgable enough to give solutions to those problems.
     These people are rare. Example: most Free Software.

Your proposed system would solve problem 1, and if the interface design  
encouraged short text, it would solve problem 2 as well. This is a good  
start. Problems 3 and 4 are still open, though.

> 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.

I don't understand the "of course" part. The help system in the Grand  
Theft Auto games is an excellent example of the kind of just-in-time  
help you are talking about, but its prompts aren't "security concerns"  
(at least, not in the sense of computer security).

> ...
> 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.

I disagree. The usual answer to "How much help do you want?" would be  
"How am I supposed to know, I haven't tried doing anything yet".

> ...
> 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.

This is good (though belied by your example below).

> ...
> 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,

This is what the coach marks did in Apple Guide from Mac OS 7.5 to 8.1.
<http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/ 
AppleGuideCoachMarks.html>
<http://mactech.com/articles/mactech/Vol.11/11.03/AppleGuideIntro/>

> and producing word bubbles.

It would be great to see sophisticated assistance functions like this  
in Ubuntu, if they avoided the mistakes of the past  
<http://en.wikipedia.org/wiki/Balloon_help>.

> ...
> 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?

Here's an approximation of how this intro would read to a typical human:

   Welcome to your new Linux system!

   Please read this introduction carefully to prevent identity theft and
   xxxxxxx xxx xx protect your privacy.

   While we have xxxx xxx xxxx xx xxxxxxx xxxx xxxxxx xxxx xxxxx xxx
   xxxxxxxxx xxxxxxx, xx xxxxxx xxxxxxx xxx xxxxxx xxxx xxx xxxx xx
   xxxxxxx xx xx.  Txxxxxxxx, xx xxxxxxx xxx xxxx xxxxxxxx xxxxx xxxxx
   xxx xxxxxxx, xx xxxx xxxxxxx SOMOSIS, Sxxxxx Oxxxxx Mxxxxxxxx
   Oxxxxxxxxx Sxxxxx Ixxxxxxxxxx Sxxxxxxx, xx xxxx xxxxxxx xxx xxxx
   xxxxxx xxxxx xxx xxxx xxx xxxx xxxxxxxx-xxxxxxxxx xxxxxxxxx.

   SOMOSIS xxxxxxx xxxx x xxxxxxxx xxxxxxx xx xxxxx xxxxxx.  Ix xx
   xxxxxxxx xx xxxxxx xxxx xxxxxxxxxx xx xxx xxx xxxx xxxxxx xx xxx
   xxxxxxxxxx xxx xxxx xxxxxxxx xxxxxxxxxx; xxxxxxx, xxx xxxxx xxx
   xxxxxx, xxxxxx xxxxxxxxxx xxxx-xxxxxxxx xxxxx xxx xxxxxxxxx x-xxxx,
   xxx xx xxxx xxxxxx xxxxxxx.  Bx xxxxxxxxxx xxxx xxxxx xx xxxx xxx
   xxxxx xxxxxx, xx xxxx xx xxxx xxx xx xxxxxxx xxxxxxxx xxxx xxxxx
   xxxxxxx xx xxxxx xxx xxxxxx xxxxxxxxxxxxx.

   SOMOSIS xxx xxxx xx xxxxxxxxxx xx xxx xx xx xxxxxxxxx xxx xxxxx xxx
   xxxxx xxx xxxxxxx xxx xx xxxx xxxxxx xxx xxxx xxxxxxxxxxxx.  Txxx
   xxxxxxxxxxxxx xx xxxxxxxxxxxx xx x xxxxx xxxxxx.  Wxxxx xxx xxxx xx
   xxxxx xxxx xxxxx xxx SOMOSIS xxxxxx?

Saying "Please read this introduction carefully" will not protect you  
from the relentless human intolerance for text that is Getting In Their  
Way. Fortunately, that whole intro is unnecessary.

Your basic idea is great, but on Ubuntu-specific mailing lists, it  
would probably meet with more success if developed into a working  
Debian package. If you're capable of implementing it yourself, one  
possible approach would be to draft a spec on the Ubuntu wiki  
<https://wiki.ubuntu.com/>, and see if you can get someone to sponsor  
it as a bounty. Let me know off-list if you need help drafting a spec.

Regards
- -- 
Matthew Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDCC4X6PUxNfU6ecoRAoYjAJ49HzzRzQw6bka1xPGDwIT6CdhChwCZAciW
LqSKeIXYsJUwPEa2XXmODfY=
=lTd4
-----END PGP SIGNATURE-----




More information about the ubuntu-devel mailing list