After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 672969 - Show the search field by default
Show the search field by default
Status: RESOLVED FIXED
Product: gnome-contacts
Classification: Core
Component: general
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Contacts maintainer(s)
GNOME Contacts maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-03-28 02:27 UTC by Jean-François Fortin Tam
Modified: 2012-09-05 09:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2012-03-28 02:27:52 UTC
Hi, you should not rely on users thinking "oh yeah, this app surely has a search function but the developers chose not to show it to me, I just need to start typing".

This is not discoverable and hurts usability. I know for sure that Joe Plumber or grandma is never going to think of this, and they are exactly the kind of people we should be designing for, not geeks who can "guess" how an app works.

Please show the search bar at all times, by default. You're not going to miss those 10 pixels of vertical height in the contact list, I promise :)
Comment 1 André Klapper 2012-03-28 08:32:13 UTC
+1 - We had the same problem at the documentation hackfest.
Comment 2 Allan Day 2012-04-22 21:33:12 UTC
The reason we hid the search field is to be consistent with the other application designs. The aim is to have search fields consistently hidden at the top of lists and grid views, so people learn where to find them (we're not there yet, obviously).

Search is particularly important to contacts though, so I'm open to showing search by default, at least for now.
Comment 3 Not Used 2012-05-18 18:55:24 UTC
A "trick" could be to show it at application start and hide it after a decent delay, it does learn the user that a search exist, though it does not solve the issue of teaching the user that typing in the middle of no where make it reappear. Any ideas ?
Comment 4 Jean-François Fortin Tam 2012-05-18 23:52:55 UTC
Personally, I really don't see why we should care about gaining 10 pixels of vertical space, versus all the advantages conferred (in terms of usability and accessibility) by an always-on, easily-discoverable widget.

It's not like that list view is really constrained for space...
Comment 5 Allan Day 2012-08-06 10:44:25 UTC
We discussed this issue at the recent UX hackfest, and agreed that the search bar should remain visible. It'd be great if someone wanted to fix this for 3.6. ;)