[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Old article about GUI design and usability
From:       Jacob Beauregard <jake13jake () comcast ! net>
Date:       2007-04-24 19:56:17
Message-ID: 200704241556.17728.jake13jake () comcast ! net
[Download RAW message or body]

I know Firefox uses blinking. However, it doesn't always get the users 
attention. Perhaps the blinking area is too small, and perhaps motion could 
be introduced to help it. Of course this is the KDE usability list and not 
the Mozilla usability list, but we could call this is a step back and look at 
things kind of discussion. I'll take this opportunity to share a bit of 
knowledge.

First, this is strictly a learnability issue. Once the user knows where the 
search bar appears, they can expect that behavior. However, if the person is 
expecting a popup in the middle of the screen, that's another factor 
preventing them from noticing the change in the GUI.

Assuming the user goes to the menus along the top of the screen to activate 
the search feature, their field of vision is at the top of the window. 
Therefore it would probably be easier for them to notice a change around the 
top of the window. This is because most English users have a top-down 
left-right when they look for something. However, the search bar is more 
intrusive at the top of the GUI. Showing it at the bottom also reinforces the 
web navigation concept along the top of the GUI.

Here's something that might interest everyone:
http://en.wikipedia.org/wiki/Change_blindness

This woman working for some company that contracts to the US Army or some 
other military institution came to my HCI class around the beginning of the 
semester. They worked on systems for marking changes in different photos (for 
espionage). A computer cannot do this because it isn't a pixel by pixel 
change. In fact, the perspective of the image can change, the amount of 
lighting can change, the weather can change, etc. They use the flicker method 
to overcome most change blindness. However, there is another factor they had 
to overcome in which larger changes mask smaller changes from the user. They 
used eye-tracking systems because the eyes will pick up the smaller changes 
even if the user does not recognize them or is unable to mark them.

Still, I took away from this that the smaller changes are masked by larger 
changes in the human mind. Having a window that pops up is a larger change 
than a bar that goes along the bottom of the GUI. Also, if a user goes to the 
edit menu in Firefox and clicks Find, the context menu disappearing is a 
larger change than the search bar appearing. In this case, the context menu 
disappearing is an intrusion to the search bar appearing.

So pretty much factors against the user learning the location of the Firefox 
search bar:
Expectations (a popup in the middle)
Search bias (top-down, left-right... esp. for Ctrl+F users)
Change blindness (larger change masking smaller change, not so much for Ctrl+F 
users)

The blinking will help the user recover from their change blindness, but only 
after a period of time, and if the blinking covered a larger area, say the 
entire bar, they'd have an easier time picking it up (larger change). Eyes 
are also good at tracking motion, so if the search bar was animated, this 
could also help the user.

On Tuesday 24 April 2007 12:23:16 pm Matthias Lechner wrote:
> Hi Jacob,
>
> well, firefox basically implements those techniques since the search result
> is incrementally marked when typing the search term (motion) and the search
> field is colored red when the term cannot be found on the page (flashing).
>
> Maybe the search bar itself should be colored differently when calling it
> or should be blinking on first use...
>
> Matthias
>
> On Monday 23 April 2007 14:26:31 Jacob Beauregard wrote:
> > How to make something visible to the user without opening a new window?
> > There are some ways to do that. Motion and flashing, those are the two
> > big ones.
> >
> > On Monday 23 April 2007 07:44:46 am Matthias Lechner wrote:
> > > On Sunday 22 April 2007 19:48:56 Esben Mose Hansen wrote:
> > > > I press search. Then I get confused that no dialog box appears, like
> > > > it does in every other application that can search. After hitting
> > > > ctrl-f a few more times, I realize that this is because the search
> > > > bar is that unobtrusive small textfield in the lower left. Then when 
> > > > I search, I have the hardest time spotting the term I found.. it just
> > > > doesn't stand out. And the hint that no occuraces was found is quite
> > > > subtle too (the search text turns red, as I recall). Which is all
> > > > very fine for advanced users (and a nice supplement), but too subtle
> > > > for casual use, in my humble opinion.
> > > >
> > > > If you meant konqueror, just try pressing / and type a few letters in
> > > > a web page.
> > >
> > > Hi,
> > >
> > > that striked me too when I used firefox for the first time.. But as a
> > > long-time user I'm very happy with this kind of search since it's
> > > faster
> > >
> > > :-)
> > >
> > > What you can do to avoid searching for the search result is to use the
> > > highlight function that is next to the search field. It marks the
> > > search results yellow and makes it easier to spot the search terms.
> > >
> > > Best regards
> > > Matthias
> > > _______________________________________________
> > > kde-usability mailing list
> > > kde-usability@kde.org
> > > https://mail.kde.org/mailman/listinfo/kde-usability
> >
> > _______________________________________________
> > kde-usability mailing list
> > kde-usability@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-usability
>
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]