[Usability]Controls, widgets, and UI learning.

[Daniel F Moisset <dmoisset arnet com ar>]

J. Ramsey already did a good work getting together the points for and
against widget and controls, but I wouuld like to add a few things, some
of them specific to this problem, and some other more general.

Widget is very clear and precise... once you know what it refers about.
OTOH, someone reading "controls" might think about what we call widgets,
bot might also think about things absolutely unrelated; for example,
control center applets comes to my mind. Or a close button in the window
frame... hey, they are buttons, aren't they widgets?  (and a window's
close button is definitely a "control").

I think part of the problem here is that we're trying to describe a part
of the internal workings of the UI to the user, no matter if we use
"widget", or "control". The user shouln't need to know that buttons,
menubars, and scrollbars are all some part of some abstract category
(call it "widgets", "controls" or whatever you like).

An appearence dialog should let the user control the appearence in terms
a user thinks about the UI. The user (usually) doesn't know that the
window frame and the widgets are drawn by completely separate software
components (the wm and the toolkit). You're trying to get him to view
that, and to understand an abstract category, without telling him.

I think a possible solution (but I hope someone comes up with something
better, it doesn't convinces myself too much) is an apparence dialog
with the drawing of a window, some widgets inside, some way of
highlighting parts of the drawing (clicking on it, and/or an option menu
with options "window frame", "{widgets|controls}", "fonts"). That should
choose a tab, open another window, or something like that. It doesn't
sound very well, but I'm trying to use the idea of telling to the user
that the apearance of these components can be individually changed (and
perhaps in this same dialog you could have a metatheme selector that
changes all). Obvioulsy the image could be a preview to be more
effective.

The question being discussed shouldn't be widgets vs. controls; it
should be if it's worthing trying to teach the users about this
abstraction of "widget". If we decide we must teach them, then we should
think about what's the best term to use for that abstraction.

Most abstractions (or from the programmer's view, thing you put in
abstract classes, like GtkWidget) shouldn't probably appear named in the
UI, unless that abstraction has a lot of general visible properties that
are worth teaching together instead of teaching them for each particular
case; "Application" is one example of that abstractions that can be
exposed to the user. 

If the choice is made to teach the user about it: If it's something to
mention lightly, in one or two places in the documentation when it's
clear from context and from figures what are you talking about,
"controlls" is right. If not (i.e., you have to talk a lot about it, and
in the UI where you cannot afford to have figures and explanations), I
believe "widget" is better, because: a) you will explain it in several
places anyway b) the user will have to learn it anyway. In that case, a
precise term beats a vague term any day. The only point there for
controls, is that Windows users (and Mac?) already know what a "control"
is.

I was about to say more about usability and putting the user to learn
new things, but that's more general so I'll put it in another thread.

	Daniel

-- 
Knowledge, sir, should be free to all!
                -- Harry Mudd, "I, Mudd", stardate 4513.3