Linux and fonts and Firefox and human-factors design

[Paul Lussier]

"Ben Scott" <dragonhawk at gmail.com> writes:

>   Fair enough, but I actually think this topic is interesting and
> worth thinking about.  It actually leads to some fundamentally hard
> meta-issues.

I find it interesting as well.  Personally, I find the complaints of
this person slightly annoying, because he's extremely smart, and
should be able to figure this stuff out, but constantly rants at me
about this stuff.  Combine that with no coffee on a Monday morning and
a train that ran 1/2 hour late... :)

>   Well, one potential problem here is that there are about 9 brazilian
> options in about:config.  Putting those in the "Preferences" dialog
> box make it look like the under-street utility line map for New York
> City.  At which point, it becomes effectively unusable to the newbie
> anyway, just like about:config (which is why about:config isn't on a
> menu anywhere).

I certainly don't think all those options should be in Preferences,
but *some* should be, especially being able to configure how your
mouse behaves.  That's fundamental, and imo, ought to have *some*
amount of configurability in that UI.

>> Or expect them to understand what these settings, which seem to have no
>> documentation, do?
>
>   Ah, even better.  Do we put a knob in, and risk confusion and
> clutter?  Or do we leave it out, and piss off everyone who considers
> that particular knob essential?  If we put it in, do we spend
> time/effort/money/manpower drawing up a fancy preferences UI and
> documentation?  Or do we leave it hidden under the hood, which makes
> it hard to get to, hard to use, and hard to understand?

It depends.  One answer won't fit for all options.  Some should be
configurable in the basic Preferences panels, some shouldn't be.
Regardless, you should be able find some docs on the options.  There's
no reason the about:config UI can't have a single column for a brief
description of what the option does, and perhaps another for "related
knobs you might also want to tweak".

> From experience, I can say that, for the vast majority of possible
> knobs, no matter which way you go, you'll piss somebody off.

That's true.  However, as I said before, for those who hope to have
Linux/FOSS make in-roads on the desktop, they need to be addressing
the neophyte users and providing basic configuration options for
obvious things.  Especially fonts, which was the real thrust of my
original post.

>   Examples:
>
>   Emacs.  Famously customizable.  Infamously steep learning curve.

I wouldn't consider Emacs something you foist on neophyte user, nor
give to someone coming over from Windows.  Emacs is a software
development tool which is infinitely flexible, infinitely
customizable, and infinitely extensible.  There is no other tool to my
knowledge which compares equally with the capabilities of Emacs.  That
being said, Emacs can be used quite successfully "as just a basic
editor" and nothing else.

By the same token, vi falls into the camp of "tools I wouldn't give to
a newbie."  Not because it's overly difficult to use, but because it's
not something "the average" user needs.

All that being said, there is no reason why both Emacs and vi could't
be built against a common font lib so they too could leverage the
fonts available to firefox, OpenOffice, and Gnome/KDE.  Everything
under the sun seems to compile against glibc, can't we have glibf ?

>   GNOME 2.0.0.  Here, the developers consciously took the path of
> leaving out all but (what they considered) the most essential knobs,
> and that pissed off all sorts of people, who found the software often
> worked against them (since they were used to something that worked
> just a bit differently, and they didn't have a knob to change things).

Well, yeah, but they went to an extreme where even new users didn't
like the behavior.  And it's one thing to change the defaults, quite
another to not allow a reasonable means of changing them.

>   Without an extension, you are correct.  This was not considered
> "essential" when tabs were first added.  (Compare this to the
> task-list/window-list/task-bar/etc in most window managers/GUIs.  You
> generally cannot reorder things there.  Firefox followed suit.)

Yeah, but it's also not intuitive to think you can or should be able
to change those.  Tabs are screaming to be dragged :)

>   Mozilla will take a middle-click in a non-text-input-area and treat
> that as a URL you want to go to.  (It has done this since just about
> forever, possibly even when "Mozilla" was still "Mosiac".)  This lets
> you highlight a URL in some other program, then middle-click to
> "paste" the URL into an existing window, which will then open the URL.
>  If you're used to Unix style middle-click-to-paste, it makes sense.
> Personally, I use this *constantly*.

Yep, same here.  I love that feature (middle click that is).  I
personally never use the feature of searching for text that way, I've
got a search menu bar for that.  But that's a personal preference over
which I have control ;)

>   So, now, we face another interesting choice: Do we throw away ten
> years of UI history for people familiar with Mozilla?  Or do we
> disable functionality that newbies seem to expect works?

I personally, like you, see no problem with the default behavior.  But
it is something I think *should* be easily customizable, and isn't.

>   Should we generally disable middle-click-to-paste by default, since
> newbies generally don't understand *that*, either?

Again, I think it's a reasonable default, but can you even explain how
to turn this off?  I could probably figure it out after about 30
minutes of searching, tweaking, etc., but I certainly don't have a
clue off the top of my head how to do it.  Though I can certainly see
*why* someone would want to turn this off, especially if coming from
Windows or Mac, or changing the bindings over to C-x/c/v...

> These questions are hard to answer well.

No I don't think their hard questions to answer.  I think what's hard
is thinking about and implementing good usability features.  No one
*wants* to think about this stuff.  It's not hard to implement, it's
tedious and time consuming.  It's not an interesting problem.
Fundamentally, I think that's the problem.

-- 
Seeya,
Paul