Re: [Usability] Gnome HIG suggestion: search box clear buttons

[Shaun McCance <shaunm gnome org>]

On Thu, 2007-06-14 at 22:39 +1000, Matt Fellows wrote:
> > 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.
> 
> I agree with what you are saying, I never said that we didn't rely on
> colors as the only mechanism for discriminating between different states
> - I said that we shouldn't :)
> 
> I also agree with the idea that we shouldn't have one hundred different
> colours to represent state, I think we could get away with just two; the
> active search state, and the error state. If the program is smart enough
> to detect an inconsistent state couldn't we just prevent the state from
> occurring by clearing the search field? Or am I missing something
> important?

Right.  All I was saying was that we can get away with a small
number of colors.  And note that I'm red-green color blind, so
when I say colors are OK, it actually means something. :)

I think I didn't explain well enough what the inconsistent would
be for.  I'll explain by example.  Evolution has a search field
that filters what you see in the header list.  This search field
is not instant-apply.  So let's say I do a search for "Malard"
in Evolution.  I've misspelled "Mallard", and I don't get any
results.  I go to the search field and type "Mallard" instead,
but I forget to hit Enter.

In this scenario, there is text in the search field, and the
header list is being filtered according to some search text.
But those two are not the same.  The interface ought to convey
that to me.

> > 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 thm 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.
> 
> I'm not well acquainted with gory insides of the GTK+ API but if I
> understand what your suggesting correctly - that is that the search
> field will convey it's state to the user via the screen reader - then it
> seems we have our redundancy. It would be nice to have named colours
> though that could be re-used across apps.

I'm not at all arguing against having a common set of named
colors.  In fact, I've been arguing for that for years, as
there's some nice stuff I could do with it in Yelp.

But in this case, I also want the state set explicitly to
something that carries meaning, because it will be better
for accessibility, and it will encourage consistency.

--
Shaun