Re: Word-a-Day: button, command button, toggle button
- From: Shaun McCance <shaunm gnome org>
- To: gnome-doc-list gnome org
- Subject: Re: Word-a-Day: button, command button, toggle button
- Date: Wed, 30 Apr 2008 11:18:21 -0500
On Sun, 2008-04-27 at 18:44 +0100, Matthew Paul Thomas wrote:
> Shaun McCance wrote on 26/04/08 19:28:
> >> And while I remember: there should be a guideline somewhere that when a
> >> control's label ends in an ellipsis, help text referring to that
> >> control's label should omit the ellipsis. (The ellipsis confuses any
> >> following punctuation, and its normal job -- hinting at further steps
> >> required -- is obviated by the visibility of further help text.)
> >
> > I don't think I've ever seen a button with an ellipsis.
> > I was going to make this recommendation for menu items.
>
> Ellipses are a site of rampant confusion in Gnome, thanks to
> inconsistency in the HIG. But examples of buttons that correctly have
> ellipses can be found in F-Spot's Add-in Manager ("Install Add-ins...",
> "Repositories...", "Uninstall..."), Inkscape's "Export Bitmap" window
> ("Browse...") and its "Fill and Stroke" palette ("Edit..."), and
> Epiphany's Personal Data window ("Clear All..."), to name just three.
All right, we'll add this recommendations for buttons
as well then. Are there any other controls people are
button ellipses on these days?
> >>> Click the 'Attach a file' (#) button on the toolbar.
> >>
> >> Shorter would be "Click the # button in the toolbar", marked up such
> >> that the icon has the same accessible text in the help as it does in
> >> the GUI itself. It would also be less confusing, in that people
> >> wouldn't look for a label that didn't exist.
> >
> > As I wrote this, I was thinking that perhaps the tooltip
> > or accessible name should be used as a description, but
> > not actually marked up as a label, to avoid the problem
> > of causing the user to look for that label. But it may
> > be hard to construct sentences that don't sound dumb.
> >
> > Anyway, here are three concerns I have with only using
> > the image:
> >
> > 1) We need to make some recommendation on what to do
> > in text-only environments.
>
> If the application is being used in a text-only environment, then so is
> the help, and vice versa. So if the image is "marked up such that the
> icon has the same accessible text in the help as it does in the GUI
> itself", there will be no mismatch.
You are I are using a text-only communications medium
right now to discuss graphical interfaces. People use
email all the time as support forums.
A text-only might also be used on web forums. Inline
images may be technically possible, but it's too much
of a hassle for a poster to find the icon (possibly
by creating a cropping a screenshot), upload it, link
it, etc.
> The only exception to this will be referring to printed help, so the
> style sheet for printing should include both the icon and the label.
Printed help, while certainly no longer the primary
concern, is definitely something we should keep in
mind in the recommendations. The "label (image)"
format has the advantage of not losing information
in print, without any sort of special print filters.
> > 3) Icon themes make it difficult for us to show exactly the right
> > icon.
>
> I doubt there's anything you can do about this. (I think icon themes
> will turn out to be a hoax, because third-party applications will often
> need to include icons that are unique to them, and it's unreasonable to
> expect them to include variations of that icon to match any possible
> theme you might have chosen.)
True, although I suspect that 90+% of what we write
within Gnome will be referring to standard icons.
Themes, generally, are a huge pain for documentation.
Since many of the big distros use a custom default
theme, basically all of our screenshots fail to match
what many of our users actually see.
Of course, other systems have at least some concept
of themes, even if it's just custom color schemes.
The difference is that they have a default theme
that isn't changed by "distributions" or OEMs or
anybody else.
If a user explicitly changes her theme, I think
having screenshots in documentation not match her
interface isn't that jarring. But when it doesn't
match out of the box, that's just annoying.
Sorry, that was entirely tangential.
--
Shaun
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]