launchpad's search interfaces are confusing

Bug #182014 reported by Louis-Dominique Dubeau
2
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Matthew Paul Thomas

Bug Description

When navigating launchpad, the user is presented with multiple search fields. It is usually not clear what the scope of each search field is. (By scope, I mean what data precisely the search engine will search through, once I press the "search" button.) I will illustrate with two cases.

First Case
======

The project-specific page for bug searches has two fields:

1. One at the top right which is not labeled in any way to indicate the scope of the search.

2. One at the top left (somewhat lower vertically than the first field), which appears under the label "Bugs in <Project Name>".

Number 2 is labeled well enough but number 1 is not. If I do a search with that field, the results page informs me that I was searching for projects. (Which probably means that it searches for project names *and* descriptions.) Why does it search only projects and not the entirety of launchpad? The GUI provides no evident clue as to what the user should be expecting. On most sites I visit, the topmost or bottommost search field presented by the site, unless otherwise labeled, is usually a site-wide search. That's what users come to expect given that it is pretty much the de facto standard in web site design on the web.

Then there's the problem of widening the bug search. Ok, so I searched in project X for bug Y and the results I found there were not satisfactory. Now I want to do the same search in all projects in Launchpad or all the projects in Launchpad that have Ubuntu packages. I have to navigate out of the "Bugs in <Project Name>" page and hunt down which search field will have the functionality I want. After a lot of frustration, I found that I need to go to the main page for the "Ubuntu" distribution and perform my bug search there.

Widening the search is not a theoretical problem but one I have to perform on a regular basis. If I encounter a display problem in Gnome, for instance, the list of possible culprits can be pretty long. Is it the application itself which is at fault? Gnome? Xorg? nVidia's driver? I try to narrow down which package is the likely culprit and then expand my search if I don't find a bug report corresponding to my problem.

Second Case
========

1. Go here:

https://launchpad.net/ubuntu

2. Search for "linux-image-2.6.24" in the search field under the "Ubuntu" label.

3. I get one result to the source package "scribus" in Ubuntu. I'm not sure what the search scope is... it looks like maybe it is searching through the *contents* of packages or *description* rather than package names since the results page says:

>> Search results
>> Show Ubuntu packages containing:

4. Go to:

https://launchpad.net/ubuntu/hardy

5. Search for "linux-image-2.6.24" in the search field under the "Hardy" label. This is the *very same* input as in step 2.

6. Ah, now we're talking. I get a list of binary packages for Hardy which all contain linux-image-2.6.24 in their name. The result pages tells me that I was searching for package names:

>> Binary package search results
>> Find packages with names containing:

Consider this: we're talking about two search fields which appear in the *same* position on the screen, which have the *same* button labeled "Find a Package". The only difference a normal user would expect is that one would presumably search in all of Ubuntu (i.e. all releases of Ubuntu) whereas the other should search in Hardy only. However, one search field searches the *contents* of packages whereas the other searches the package *names*. There is absolutely nothing in the GUI which clearly indicates such difference between the two search fields. From the perspective of a normal user, the difference makes no sense at all.

Conclusion
======

Those are only two examples of a larger problem: search fields in Launchpad are confusing and frustrating to use. The whole search paradigm needs to be rethought from the ground up so that users have a clear indication from the GUI *before performing a search* as to what results they can expect (a problem illustrated by both cases above). And there need to be consistency among the various search fields presented to the user (a problem illustrated by the second case above). I've seen discussion about implementing site-wide search functions. While I think site-wide searching would be a very desirable feature, I think the issue I am raising here is orthogonal to whether site-wide search is available. Even with site-wide searches, it would presumably be desirable to keep quick search fields of the type I am referring to in this report. These quick search fields need to provide clear indications of their functionality and should allow the user to quickly switch gears when they want to change their search rather than have to find whichever other page in launchpad presents a search field with the needed functionality.

Changed in launchpad:
assignee: nobody → mpt
importance: Undecided → High
milestone: none → 1.2.6
status: New → Confirmed
Changed in launchpad:
milestone: 1.2.6 → none
status: Confirmed → In Progress
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Fixed in mainline, r6629. The global search field is far away from any application-specific search fields, and it is clearly labelled "Search Launchpad".

Changed in launchpad:
status: In Progress → Fix Committed
Changed in launchpad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.