Re: [Usability] Gnome HIG suggestion: search box clear buttons
- From: Shaun McCance <shaunm gnome org>
- To: Matt Fellows <matt fellows onegeek com au>
- Cc: GNOME Usability List <usability gnome org>, Alan Horkan <horkana maths tcd ie>
- Subject: Re: [Usability] Gnome HIG suggestion: search box clear buttons
- Date: Tue, 12 Jun 2007 09:41:18 -0500
On Tue, 2007-06-12 at 21:44 +1000, Matt Fellows wrote:
> On Sun, 2007-06-03 at 14:15 -0700, Kirk Bridger wrote:
> > I think Firefox used to do the pre-select in the URL field and I
> > always found it difficult to use. Or is it IE that currently does
> > this?
>
> FYI Firefox and IE on Windows automatically select the text on first
> click, the latest version of Firefox and Opera on Linux lets you click
> wherever you want.
>
> >From what i can tell just by clicking in every possible text box, this
> is standard behaviour in Gnome (anyone who knows better feel free to
> shut me down on this one). This fact alone would be a compelling reason
> to have a clear button, or at the very least to not automatically select
> text with one click.
>
> I'm not sure if using colours as an indicator of search state would
> suffice, especially for those with vision impairments. Red and green are
> probably the most recognised colors in terms of meaning (bad/no/error vs
> good/yes/success) but obviously can't be used. Any other pairing of
> colors would be arbitrary. There needs to be redundancy in another
> mechanism to provide a sense of search state. That will have to wait for
> another email however as right not I'm stumped for something clean and
> simple.
I sent a mockup[1] using yellow for "active search" and red for
"error", as well as a striped yellow pattern for "inconsistent".
We frequently rely on nothing more than changes in background or
foreground color to indicate state in our interfaces (selections,
insensitive widgets, etc.)
What would not be feasible is showing about four or more different
states using nothing more than color. Even if you found a set of
colors that work for both red-green (common) and blue-yellow (less
common) color blindness, you'll still create a problem for the rare
black-and-white color-blind users.
You also have to consider your low-vision users, which constitutes
a large percentage of older folks. For these people, patterns like
my striped background could be problematic.
A quick test for this stuff is to take a screenshot (or mockup),
open it in the Gimp, convert it to grayscale, and give it about
a 5 pixel blur. If you can't tell what's what, then there are
going to be accessibility problems.
And, by the way, in my previous email I also advocated having an
API in GTK+ for this. Ross responded that the new named colors
would work, if we could agree on some standard color names. I
believe we need a higher-level API like:
gtk_entry_set_state (GtkEntry *entry,
GtkEntryState state);
typedef enum {
GTK_ENTRY_STATE_ACTIVE,
GTK_ENTRY_STATE_INCONSISTENT,
GTK_ENTRY_STATE_ERROR
} GtkEntryState;
The colors/patterns/whatever then become a side effect of this.
This will help our blind users considerably, because their screen
readers will be able to tell them exactly what's going on. With
just colors, they'll have to infer some meaning from a textual
description of visual cues that they may have never even learned.
[1] http://mail.gnome.org/archives/usability/2007-June/msg00025.html
--
Shaun
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]