On Fri, 15 Jul 2016 12:51:11 +0000 (UTC)
Go Linux <golinux@???> wrote:

>
>
> Obviously, I didn't try what was suggested in the readme . . . don't
> like to reboot or even logout. I'm hoping that someone with more
> chops than I have should be able to get those commands working.

Last night I took my Devuan VM, and into the login screen typed special
usernames "halt" and "reboot" each with the **root** password. Halt
halted the VM, reboot rebooted it. I typed in special username
"console", which put a little tiny graphical console on the
screen, asking my username and password, and allowing no other work
than console work. So the key information in this case is special users
"reboot" and "halt" work only if when queried for the password, you
type in the root password.

>
> I suggest you file an issue under the slim package and assign it to
> hellekin.
>
> And I totally agree that there should be some text suggestions on the
> login screen perhaps to a revised README if nothing else.

Yes! This is a must. The way I see it, if the user ever gets to a place
where he says "where the hell do I go from here?" or "so what do I do
now?", it's a big developer fail.

A few minutes ago, while using the Audacious music player, I noticed
that a button with two crossed curvy arrows was depressed. I suspected
that meant "shuffle", but didn't know for sure, so I hovered the cursor
over the button. Nothing happened. I guess the developer was just too
busy to put any tooltip text, and figured if I didn't care enough to
web-research the meaning of the crossed curvy arrow hieroglyphic, I
didn't care enough to use his program.

Back in the day there was at least some excuse for lack of
discoverability. You had only 24 rows of 80 characters for your
prompts, your input fields, your form title, etc. Sometimes it was
difficult to find the space to include "Ctrl+Enter"=Transmit,
"Esc=Cancel", "F5=List". With today's scrollbars, there's no excuse at
all other than laziness or elitism for lack of discoverability.

Some might argue that "we bend over backward to coddle the user,
thereby complicating the programming." That's not what I'm talking
about. I'm not talking about a fuzzy logic routine to guess what the
user wants, or a particularly ingenious widget for the user to use. I'm
simply advocating that the programmer be presented with his possible
actions at this point. That's not coddling: I was doing that in 1984 on
VT-52s and VT-100s.

As long as I'm on a rant, let me include the somewhat related subject
of feedback. When the user clicks a button and nothing changes, that's
a big developer fail. Did the app "hear" the click? Should the
user click it again? Are we hung? We just don't know.

The VERY FIRST command executed in response to any user action should
be to very visibly change something, so the user knows he's been heard.
Don't depend on the cursor changing: That doesn't always work. Change
the screen in an obvious and informative way. Check out the way I wrote
the compile script for the 2nd edition of "Manager's Guide to Technical
Troubleshooting":

=====================================================================
inform_begin   $mainname.pdf
rm $mainname.tex
rm $mainname.aux
rm $mainname.pdf
rm $mainname.log
rm $mainname.dvi
lyx --export pdf4 $mainname.lyx
if [ -f $mainname.pdf ]; then
    inform_success $mainname.pdf
else
    inform_failure $mainname.pdf
fi
=====================================================================

The book's compile script is hotkeyed to run when I press Ctrl+Shift+G.
The very first thing it does is perform function inform_begin, which
throws a 2 second timeout little dialog on the screen saying "I heard
you." If I were coding this for release, I'd have also put the text
"this dialog disappears in 2 seconds" to prevent user confusion. And
because the dialog box is run in the background, other processing
continues without regard to the dialog box.

The microsecond I press Ctrl+Shift+G, this dialog appears. Even if I
have 27 Firefox windows open, each with its own script. Even if
something later in the script will fail. The user will never wonder
whether he didn't click hard enough, or whether the focus was wrong. He
*knows* his click got heard.

Back in the 24x80 days, or heaven forbid the days of repeatedly looping
questions displayed by printf(), it was difficult to prevent user
confusion. Today only the laziest and most elitist developers confuse
the user.


SteveT

Steve Litt 
July 2016 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques