Terminology: "selecting" is not enough!

I noticed in the chapters I'm working on that often various things, such as
all the items on the various pages of the Options dialog, it refers to
"selecting" an option. In one place it was more noticeable in the user was
directed to "select" something in the dialog.

In that case, the terminology is clearly wrong. Selecting is not the same
as operating on the widget. Selecting directs the attention to it, and
another operation may then be performed, such as toggling a check box.

I suppose in some context where the option itself is referred to in an
imperative sense, saying the option is selected is OK and in fact I didn't
notice initially. But you'd have to be careful about the wording of the
sentence: are you being imperative or directing the user's action? It's
more consistent and easier to just use a word that always works. To that
end, I'm changing whatever descriptive phrase was used to "enabled"
(antonym: "disabled"). That works for any type of control (check box, radio
box, combo-box).

I'm also trying to be more careful about wording things to reflect the
desired state, rather than the action. I.e. clicking on an option doesn't
necessarily enable it: it will toggle it, and you shouldn't click on it
unless it was off before. So don't (just) direct the user to click on
something to achieve an effect. Rather, the effect occurs when the option
is enabled. And of course this is the very case in which merely selecting
it doesn't do anything other than make the gui draw a selection rectangle
around that item.

From a programmer's POV, that's what "select" does. However, from an
ordinary USER's POV, "select" turns it on and "deselect" turns it off.

--Jean

From someone in BrOffice org i got this email ...

"
Tom could you be kind enough to post the following to the documentation list ?
- If I get further into this discussion don't worry, I'll re-join myself.

- To the Documentation Team / TDF:

We the Brazilian members of the TDF community are having a problem:

We believe that the NGO BrOffice.org and it's current directors DO NOT
represent our interests any-more. A group of us are in the verge of breaking
with this NGO and as so we would continue our work with the BrOffice Suite (the
Brazilian version/brand of LiO).

We are in the midst of a discussion on starting to translate the Guides. But
here is where things get a bit murky:

1) We want to know if we can start this enterprise with the blessing of the TDF
and specially the Docs Team.

2) Would the Docs Team consider to open a venue for us, even though we might be
breaking with one of the founders of TDF (and representative on LiO in Brazil)
?

3) As a possible "rogue" team could we have access to Alfresco and could we get
some help to format our workflow in this platform?

I will maintain myself out of the Docs list so you can discuss this within the
list without embarrassments, unless I am asked to return and resume discussion
on-list.

Thank you all
"

My feeling is that from our point-of-view it would be quite easy. They seem to
be worrying about things that are not a problem.

However, NGO status means a fully formed and registered organisation that can
deal with funding issues and maintain a bank-account and stuff. It is a shame
to lose that sort of status but these things do happen, as we well know (even
those of us that are new here).

Regards from
Tom :slight_smile:

Hi, :slight_smile:

There's absolutely no reason why they can't use Alfresco. Speaking
personally, I'll give all the help and cooperation I can, which
obviously includes setting up a working space for them.

David Nelson

Documentation and training material for USERS of GUIs specify it like that.
The distinction might be more noticeable if you are not using the mouse.
Like I said, in some contexts it is clear, and in other phrasing it is
wrong. I'd rather be consistent and avoid the problem.

Hi :slight_smile:

I can totally agree with both points of view. I think select and de-select are
probably easier to understand for more users although it is good to know why i
felt uncomfortable about it! Enabled as the opposite of disabled is more
uncomfortable politically since people in wheelchairs (a growing segment of
society) are often said to be "disabled" despite the fact that there might only
be a very limited number of things they can't do so well and many others they
may do better. So, for a lot of office users the words might be uncomfortable.
Select and de-select are safe even if i do still shudder a bit when de-select is
used.

Generally it is better to stick with a word that is used a lot in documentation
even if it is blatantly wrong or used badly but consistently. Flagging it up by
emailing the list but not changing the documentation is the best way of handling
that sort of thing. My pet hate is the use of , before "and" or "but". It is
bad English but good American so i have to try to stop myself from correcting it
if i ever get around to doing any work. Oddly i prefer lower-case i to
distinguish it from 1 or l and because i think it look friendlier despite it
being wrong.

Regards from
Tom :slight_smile:

I have another problem with the enabled/disabled terminology -- I think it can easily be misunderstood as modifiable/unmodifiable (available/"grayed out"). This terminology is not in common use and I think it would be more confusing than helpful. Often "click" would be a reasonable substitute, but I have no problem with "select" and definitely prefer it for options in a list, for example.

Hi, :slight_smile:

I often use "activate" or "deactivate". Or, speaking more loosely,
"switch on" and "switch off".

David Nelson

That's OK, too, for checkbox (tickbox?) items, and maybe radio buttons. I think our terminology list needs to be updated and reviewed for the preferred way/ways to express this for the different UI items. I doubt there's a one-size-fits-all solution, though for me select comes closest. I'll put something together. Until we've agreed on the way we want to go, I don't think there should be any blanket changes to the existing terminology.

Hi, :slight_smile:

I'll put something together. Until we've agreed on the way we want to go, I
don't think there should be any blanket changes to the existing terminology.

+1.

David Nelson

Activate/Deactivate works for me.

Barbara Duprey wrote:

I have another problem with the enabled/disabled terminology -- I think it
can easily be
misunderstood as modifiable/unmodifiable (available/"grayed out"). This
terminology is not in common
use and I think it would be more confusing than helpful. Often "click"
would be a reasonable
substitute, but I have no problem with "select" and definitely prefer it
for options in a list, for
example.

"select" is a synonym for "choose" and would be applicable for a drop-down
combo-box or a set of radio buttons. But for checking/unchecking a check
box, it is simply the wrong word. You are not selecting one option from all
of them on the page; you are individually turning each option on or off.

I agree, "disabled" is used for graying out a menu item, at least in the
Win32 API. Popular use is just "grayed out" though.

"clicking" a check box does not mean "ensure it is checked." The action of
clicking it will probably toggle it. It is correct to click a button,
though.

How about "check"? Well, as a verb it means "hinder or restrain" so
un-checking the Foo option will check the operation of Foo. Or it means
"inspect" which will find out what it is; so you want to check your margin
settings when setting up the page. So, don't use "check" to mean "mark" as
a verb, in this context.

The text in the document that you indicate by swiping the mouse is "The
Selection", and you select some text before hitting the "bold" tool, for
example. Selecting a named item from a combo-box is acceptable usage.

I think we should focus on explaining what the various options indicate,
rather than directing the user to click on them or saying that the effect
would happen if the user enabled them. That is to be understood: just
state the effect itself!

I just went to another program at random: the context help for the Options
page on Firefox reads, "When this option is enabled, Firefox will..."

On Notepad++, "Check the option to ..."

On XYplorer, some don't use a state or verb, just lists the meaning without
preamble. Others use check/uncheck.

7-zip: on the file manager options, most of the time doesn't use any
preamble. E.g. "Displays gridlines around items and subitems." Some uses
of "select". The rest use "enabled".

Foxit reader: on the printing help, "select" is followed by " from a list".
No preamble for options explanations, but they are mostly radio buttons.

So, I think there is lots of competition against "select" to mean "mark on".

--John

Good points, I'll incorporate this into the terminology document for us all to collaborate on. As I said, I don't expect a single answer here, it depends on the type of UI item involved, and sometimes on the behavior resulting from the choice.

What terms does the LibreOffice Help use? I thought that was our main
terminology selection criterion.

Hal

Hi :slight_smile:

Most documentation just confuses people so copying what they use probably wont
help us. If we are going to look at documentation then a community edited one
would be better, such as Ubuntu's but it would need to be regularly edited
bynoobs rather than by geeks so perhaps Ubuntu's might be the best one to look
at. Documentation for Windows apps tends to be the most confusing documentation
for most people.

"Greyed out" is a very geeky term. Admittedly low-level geeks but still not an
average user. "Check" is kinda American. In English it tends to mean a method
of payment or "to stop and look around" or as described. Tick the option might
be a good way to say it but "UNtick" confuses people. Select means to to choose
and that seems to make sense to people.

Regards from
Tom :slight_smile:

Yeah but it's a bit posh or sci-fi. I like it but then i also liked "Defying
Gravity" and that was so unpopular it only lasted 1 season. There are some
great suggestions in this thread so i think they should be in a glossary.
Perhaps we shouldn't try to be too consistent because people can always look
things up in the glossary. Activate might be good when there is an instant
highly visible spectacular result.

Regards from
Tom :slight_smile:

"Click" is good but it suggests toggling the value which is the original
problem at the beginning of this thread. "Mark" doesn't quite work (well he
does a huge amount like most of you). "Hit" is much like click but only covers
certain demographics. Although there are a lot of good options i don't think we
will find anything much more generic and useful than "select" as all the
alternatives also have problems. I also think this is a side-issue when there
are more important changes we need to focus on. It is great to have these
discussions early on before things get too established. The people in the
documentation team are great.

Regards from
Tom :slight_smile:

Hi Hal,

What terms does the LibreOffice Help use? I thought that was our main
terminology selection criterion.

I didn't read all the thread, what are the terms you're searching for?
- select
- mark
- check
- ??

are there others?

Kind regards
sophie

The things we're discussing here are, I think, too context-sensitive to be readily searchable.

There seems to have been a decision long ago to use US-English terminology and spelling in the English documents. "Tick" is not used in the USA, except when talking about the blood-sucking insect! I think "not available" is fine instead of "grayed out" but not often needed anyway.