Terminology: app, window, workspace, part of the window, file, folder

Hi guys,

Shaun and I discussed some terminology recommendations at the developer
docs/tools hackfest in Berlin. We managed to get a few finished, but I
think we should push to get some reasonably complete guidelines together
soon-ish, since they're a prerequisite for the new Desktop Help. Now is
also a good time to fix UI string recommendations before the GNOME Shell
hits the mainstream.

I think we should apply the following principles when choosing terms:
They should be simple (non-technical, simple language), unambiguous (it
should be obvious what they refer to), recognisable (users should be
instantly familiar with them, i.e. everyday words), and not
overly-specific (no need to distinguish between different types of
window, for example). Technical correctness should *not* be a primary
concern! Asking users what an object is called is a good way of testing

Here are a few random suggestions (possibly overlapping with previous
suggestions, sorry), some of which may or may not be controversial...

Term: APP (n.)
Replaces: application, program, software (pl.)
Rationale: People are familiar with the term "app" thanks to Apple's ad
campaigns etc. and will associate it with software. "Application" is
overly formal and sounds technical. One problem is that "app" is quite
short and might sound terse.
Usage: Generic name of a piece of software. "Close the app.", "You need
to install a chat app."

Term: WINDOW (n.)
Replaces: dialog, dialog box, user interface (certain cases),
assistant/druid/wizard, capplet, preference tool (some cases)
Rationale: Most users are unfamiliar with the distinction between
different types of windows. They're all types of windows, so let's just
call them that.
Usage: Name or clearly describe the window where necessary to prevent
ambiguity. Use constructs like "In the same window, click..." to avoid
unnecessary repetition of the window's title. For an assistant window's
title, you should still use the term "assistant".

Term: WORKSPACE (n.)
Replaces: viewport, virtual desktop
Rationale: Ties in with Apple's "spaces". The least technical of the
available options.
Usage: A workspace is a single area where certain windows are
grouped/displayed and other open windows are out of sight (i.e. one
viewport). In documentation, provide a link to the DH conceptual
overview of workspaces on first usage in a document. "Switch to a
different workspace."

Replaces: pane
Rationale: "Pane" is a bit like a "window pane", which is a subdivision
of a window, but I'm not sure users get this. Maybe I'm wrong? We don't
use "pane" often enough that the more verbose "part of the window" would
be awkward, though.
Usage: Refers to an area in a window that is visually distinct from
other areas, e.g. "The message will be displayed in the main part of the
window". Provide enough information that the user can locate the part of
the window. If trying to replace "pane" in a UI label, think of a more
descriptive specific name for the object, e.g. "list", "picture",

Term: FILE (n.)
Replaces: document (certain cases)
Rationale: Users don't treat files as generic objects - they are more
likely to use a specific file-type name, like "photo". Using "document"
to refer to generic file objects is confusing, since a document is more
commonly associated specifically with a text document.
Usage: Prefer using a specific document-type name if possible, since
this matches better with how users think about files. Where a generic
term is needed, use "file", e.g. "Recent files".
[Should we take this to its logical conclusion, e.g. save dialogs have
"Photo name:" rather than "File name:"?]

Term: FOLDER (n.)
Replaces: directory
Rationale: Directory sounds technical.
Usage: "Choose which folder to save the photo in."


Phil Bull
Book - http://nostarch.com/ubuntu4.htm

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]