SemiOT: Article on User Interface Design

[Fairlight]

This public service announcement was brought to you by Bill Campbell:
> My first reaction when I unziped the file was ``spaces in file
> names! Gack!!!'' :-).

Ya know...*nix does handle that. :) I do it over samba all the time.  In
fact, I uploaded it from linux with ncftp over samba from my Win2k.  I
dunno, I got used to it way back when, even before I touched Win95 or
before it even existed.  People would make files with spaces on systems at
university.  Go figure.  When you can sneak control characters and things
like ^H into filenames for hiding them in anon ftp directories, you really
don't think much about spaces.  :)

> As for the content, it sounds like something I would write as I've bitched
> for years about developers who write systems where it's painfully obvious
> that they haven't a clue about how people actually use them in real work
> environments (I like the term heads-down data entry).

I'll take that as high compliment.  Thanks.  :)

I like that term, too.  It's quite accurate.  There's really nothing quite
so annoying as -waiting- on someone at the doctor's office, for example,
and they're inputting data from a form you've just filled in, and they're
looking up at the screen every field or every other field, can't keep their
hands of the mouse, and you're in a hurry.  <old_man_voice>When I was
your age, we typed by touch...and we LIKED it!</old_man_voice>

And you just get tempted to blame the actual operator, but that's really
not even the case.  It's really poor design many times.  I'm all for
flexibility, but there are points where it's actually smarter to force
someone down a certain path than to give them the option.  If you have a
Windows app and -let- people use the mouse, they probably will unless
they've been doing hardcore entry for a while.  Forcing them to be
efficient by depriving them of the crutch that slows them down can be a
good thing.  That's one reason I think fPGI was such a terrible idea--it's
a step in 180 degrees the wrong direction.

Not-so-Secret:  I don't even use my mouse to navigate in a GUI browser
unless I -have- to.  I rely 99% of the time on tab navigation and keyboard
shortcuts even in Firefox.  The only times I use the mouse to navigate are
when sites pretty much mandate it for things like Flash.  Well, that and
-really- poorly designed sites with like 70 links on one page where it's
just ridiculous to even try tab navigation because then it obviously is
less efficient.  But that's also a poorly designed web site, IMNSHO.

> When I wrote my first accounting applications about 40 years ago, the input

Eesh.  I'm not even 40 yet.  :)

> media was 80-column punch cards, and I would generally do all the entry for
> the first month or so to make sure everything worked properly.  I got
> pretty good at laying out the input formats to minimize the amount of
> effort required, and to do things like make drum cards that would auto-dup
> appropriate fields say when entering time card data for employees.

What they'd now at least partly call "ergonomics" is nothing more than
common sense and motion waste reduction.  And you know, if you want to get
something done quickly and efficiently, hire a lazy person to do it.  Me
doing something like you did would be going one step further--hire someone
lazy to -design- it.  :)  Seriously, though, it's one way to make something
more efficient.

> >> The black text on cloudy gray background is distasteful to the eye.
> 
> I have to agree with JP on this.  I find it hard to read when the contrast
> isn't good, and have been known to let my subscription lapse on otherwise
> excellent magazines (e.g. Omni) because they had lots of articles printed
> on colored backgrounds.

Is this a contrast issue, or colour blindness, or preference?  I can see
any of them being valid points.

I guess you'd have to know my penchant for cool POVray stuff to appreciate
why I thought it was cool.  :)  It works for me, but I'm starting to see
why it wouldn't for everyone.

Next layout I'll shoot for something...not spartan, but more distinctly
delineated between format and content.  There's a fair amount you can
do with what (*eyeroll, please*) architects or artists call "negative
space".  (I'm obligated to roll my eyes, my wife is a civil engineer, and
architectural terms are...if not verboten, surely a call for derisive
laughter.) :) But seriously, one could lay it out with the majority of the
text on white, and do only graphics and "pull out quotes" on top of shaped
colour backdrops.  I'll play with it.  I mean, I just got the thing on the
18th. :)

There's got to be a line between the ultra-drab/plain stuff MS Publisher
would let me do, and the sheer amount of goodies I can tack in with this.
I'll shoot for less transparency, too.  That's what killed the speed.
There are literally...well each text frame has two elements...the frame
with the text itself, which is partly transparent, and a rectangle under it
that's the milky glass part, also transparent.  The marble texture laying
on top of the stain is semi-transparent.  There's something else I'm
forgetting that's transparent.  And there's a lot of dropshadow
calculation.  Actually, had I dropped the text dropshadows it might have
sped up as well, but it looked too cool at the time.

Overall, some bumps in the road of progress.  One could consider it, as JP
partly did, an example of one way not do design things, just as I was
trying to illustrate how not to design things.  :)  So it's DTP and not
user interfaces--there's still a human element, a medium, and a task to
accomplish (reading).  So yeah...it's a learning process there, and I'm
less familiar with DTP than with interface design.

Now had I been designing an -interface- that looked like that, I'd have
shot myself squarely in the head before ever releasing it.  *laugh*

Still, I'll readjust next time I do one, with all this stuff in mind.  It's
good feedback, and I appreciate it.

> I read it using the Mac Preview program, and while it show the transparency
> properly, it was still sluggish on my Mac Mini with 1GB RAM and a 1.42GHz
> PowerPC processor.

Like I said, it's sluggish on a P4-3GHz/2GB.  If you want the -real-
kicker, originally it wasn't 49.9MB, it was 180MB.  I had to use Flatten in
actual production to get it to work right at one point until I figured out
how to dodge that, which was last night.  The article's been done for like
3 days.  I was working the kinks out of what I -wanted- for design (not
necessarily what was brightest...we've established that).

But Flatten expands the file size by over 3x.  It would also make form
fields unusable if one had them.  Which is one reason I took half a night
to figure out how to get around the issue.

Ah well.  I've learned a lot, and the .doc is available for those that
don't dig the PDF.  Didn't mean to turn anything into a thread on PDF or
DTP publishing, but the feedback is very good, and I appreciate it.  Just
wanted folks to know it will help me for the future.  Thanks!

For those that may not want to try their hand at the PDF, the .doc is
locate at:

http://media.fairlite.com/pdf/uidesigndoc.zip

(And the internal file doesn't have any spaces, Bill!)

mark->
-- 
The latest synth mixdown...
http://media.fairlite.com/Isolation_Voiceless_Cry_Mix.mp3