Date: Tue, 2 Feb 1999 20:03:58 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: sue@welearn.com.au (Sue Blake) Cc: freebsd-chat@FreeBSD.ORG Subject: Re: desktop stupidity Message-ID: <199902022003.NAA15607@usr06.primenet.com> In-Reply-To: <19990202185713.43112@welearn.com.au> from "Sue Blake" at Feb 2, 99 06:57:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Now wait a minute! Most of you people don't know what newbies need, you
> haven't asked them, won't listen or believe or sit down with them to
> help them work it out for themselves, you're so set with your
> comfortable little stereotypes that you really think you know the Great
> Truth and have all the solutions and nobody can tell you different,
> least of all a loathsome newbie. You think you can just dish something
> up and they'll love it. What if you're wrong? Oh, yes, newbies fault.
I don't think that a GUI desktop necessarily targets newbies.
It targets the segment of the population that's interested in
doing software developement on non-Microsoft platforms, but is
not interested in developing the platforms themselves.
I also think that it can allay the fears of what you call "newbies"
sufficiently to get people, who would otherwise not get involved,
into the game in the first place.
Neither of these should be discounted, merely because there isn't
mass usability testing in throwing out something that has mass
appeal. Yes, you may not get the best implementation you could
have possibly gotten out of the deal, but a suboptimal desktop
beats no desktop.
I don't know of any serious developer that doesn't have X installed,
with one or more screens full of xterms.
A desktop doesn't "hide" the ability to get a command line any more
than you can get away from the MS-DOS prompt in Microsoft Windows.
I also think that you haven't thought this through from a disability
perspective.
If the install process is to put in the CDROM, select "whole disk",
and kick "express install", and that leaves you at a graphical
login, that's a definite win.
>From a graphical console, you have the option of displaying larger
fonts, text-to-speech, etc..
>From a key-down/key-up keyboard, you have the option of starting
from nothing and kicking into a disability mode -- in a way that
people with disabilities can activate it.
All this on verbal/written/braille/whatever instructions simple
enough to recall from memory.
One of Windows 9x's strengths is the ability to hold down a shift
key for a long time to activate a disability mode. How do you do
this with the normal console? How do you display the normal console
text?
Try typing with a pencil in your mouth, or a vibro-massager on
your hand.
Here's some examples:
Sticky keys CTRL, ALT, and SHIFT latch on and
reset on code generating keys, instead
of having to be held down at the same
time as another key. Turn modifier
latch off and/or toggle on repeat
modifier keystroke
Filter keys Ignore brief or repeated keystrokes
Key Beep Beep when a modifier key is latched
(or toggled).
Visual bell Visual notification for hearing impaired
Captioning Programs that would make noise put up
a caption ("tooltip") instead.
High Contrast Use a high contrast "theme". Required
for devices like optically coupled
"pinreaders"
Keyboard Mouse Use num-lock to latch numeric keypad
as mouse motion control
Magnify Magnify the display contents; either
the virtual display size is reduced, or
the display goes pan-and-scan
Idle Reset Turn off features (need shift hold to
reenable) to allow for multiuser
computers
Warn {en|dis}able Visual or audio warning on feature
enable/disable
Status bar Show feature status (modifier key states,
etc.) on a status bar
Serial keyboard Standard input device on serial port;
select port, baud rate
Serial display Many pinreaders support serial input
as well as optical; better resoloution
and control, when wired into the mouse
pointer (imagine having two mice you
had to switch between, neither of which
you could see.
Sure, you could offer maybe 1/10th of these and other capabilities in a
revised text mode console driver. But to do the job right *requires* a
*standard* GUI.
> We have a few hundred newbies here who constantly try to do the right
> thing, who want to learn, and are largely ignored because, not fitting
> the stereotype, they're not fun to pick on or you can't get warm
> fuzzies and the occasional sucked toe from having fun "helping" them
> the way you see fit. Throwing GUI at them is like telling them to eat
> cake. All they want is the bloody recipe and a bit of human respect.
Different problem set, othrogonal to the existance or nonexistance
of a GUI, IMO.
> The newbies I see are put off or held back by:
> - lack of reliable advice as to what to do/learn first, second, third ...
> - lack of suitable documentation at the right pace and starting point
> - misunderstanding of their learning needs by others
> - inaccessibility of many of the tools they need to use during the
> first few hours, before being able to execute a learning plan
> - misguided attempts to "help" them which only hold them back
> - a constant trickle of put-downs and resultant lack of confidence
> - inability to create what they need for themselves or communicate
> needs to developers
A lot of this can be addressed by creating a larger developer base,
so that there is a higher developer/newbie ratio, if nothing else.
I think that the majority of the work to be done is in getting
disciplines other than computer science involved.
For example, take your items, in order:
1) Offer less choices in the express install, so that there
is an implicit order to what to do
2) Implement a common desktop, such that a documentor can use
the system as a documentation workbench instead of becoming
a system admin (seeing a theme here?)
3) Involve the CS 101 folks in teching about FreeBSD, instead
of Windows. That means that it has to be accessible at
less depth than is currently possible.
4) Put the tools up front, and in their face.
5) Increase the quality and applicability of various levels of
help by growing the community to sufficient size to be able
to break help into a strata, instead of a binary "newbie"/"guru"
switch, as is currently the case.
6) Seperate the forums by strata to avoid "level of question"
related problems.
7) Create a larger community that can respond to requests (as
far as the "communicate needs" issue goes... this is an issue
of socialization, and beyond the scope of the project).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902022003.NAA15607>