[205] in Athena User Interface

home help back first fref pref prev next nref lref last post

Re: Session mgmt, MOTDs, HOTDs

daemon@ATHENA.MIT.EDU (Richard Tibbetts)
Wed Jun 21 08:12:51 2000

Message-Id: <200006211212.IAA24909@hikari-no-ken.mit.edu>
To: "Christopher D. Beland" <beland@MIT.EDU>
cc: aui@MIT.EDU, tibbetts@MIT.EDU
In-reply-to: Your message of "Wed, 21 Jun 2000 04:17:51 EDT."
             <200006210817.EAA12255@No-Whammies.mit.edu> 
Date: Wed, 21 Jun 2000 08:12:47 -0400
From: Richard Tibbetts <tibbetts@MIT.EDU>

(Just addressing MOTD's and HOTD's)

On 6/21 "Christopher D. Beland" <beland@MIT.EDU> wrote:
> MOTD Design Choice
> 
> Usefully, Gnome already has a startup message mechanism that checks a
> file and displays the MOTD.  It should be easily modifyable to run a
> program instead, and we could have it call get_message by default.
> 
> The program pops up a window that can be dismissed with an "OK"
> button.  The window is a bit ugly, and I'd hope that we'd fix the
> aesthetics a bit, and send the changes upstream.  More importantly, is
> has a "don't show this dialog again" button which is easily clicked.
> I think this should be removed, so that the only way not to get the
> MOTD is to hack your dotfiles rather extensively.  Along with this,
> though, we might want to not call get_message with -login, so that
> each new MOTD is only displayed once.  I dunno.
> 
> The alternative would be to just run get_message at startup and have
> it send a zephyr as usual.  That seems somewhat less reliable, and
> also less Gnomey to me.

I think that we need more thought here, specifically about how we plan
to deal with zephyr. If we (and this is a valid option) plan to leave
zephyr untouched, then we should probably just stick with the current
MOTD system (if it ain't broke, don't fix it). "less Gnomey," while
good in principle, is not by itself enough reason to do something.

If we do change systems, then I support making is really hard to not
get MOTD's.

> HOTD Design Choice
> 
> The Discovery documents also mention startup "hints of the day" or
> somesuch, which Gnome has existing support for.
> 
> I don't think we should use them.  I think they are very cheesy, and
> they annoy me whenever I see a program that uses them.  I think that
> if a system needs to drop random hints at you in order to be able to
> use it well, then the responsible engineer should be thwapped, and the
> system redesigned until it doesn't need hints.  Also, there would be a
> resource commitment to writing all of the stupid messages and keepint
> them updated.

I personally like hints, at least for programs that I use a lot which
have a large number of features. I don't read manuals, and so I often
miss things that might be useful to me. For example, when dragging
items around on the panel, holding down shift, control or alt gets you
different dragging behavior. I learned this from the tips.

It is easy enough to turn the tips off if the user doesn't like
learning things this way. As long as tech writer types don't mind
coming up with tips I think we should have them.

> I think a much better solution would be to start up the Gnome help
> browser, set to an appropriate Athena-specific intro page, the first
> time (ever) a person uses Gnome-Athena.  They can then turn off this
> feature whenever they've finished reading the intro documentation and
> feel comfortable enough with the GUI to find standard online help
> later if they need it.  Writing this documentation properly and
concisely is critical, and should be a required part of our first
> public release.

I think that we should certainly do this.


-*- http://www.mit.edu/~tibbetts -*- finger tibbetts@monk.mit.edu -*-

home help back first fref pref prev next nref lref last post