VersionThreeDotO/Bugs/ExplicitSearchFilteringAndCleanURLs

Not logged in - Log In / Register

Explicit Search Filtering and Clean URLs

Preamble

There are three main issues here:

  1. Users can't see the filtering criteria when looking at search results.
    • When doing either a simple or advanced search, the search text and ordering are shown.
    • But, when doing an advanced search, none of the other criteria - like milestone, statuses, etc. - are shown.
  2. Users can't refine the criteria from the search results page.
    • After a simple search, there is no way to "upgrade" to an advanced search; the existing criteria are not carried through.
    • Similarly, for an advanced search, there is no way to refine the criteria without going back to the previous page.
  3. Search URLs are noisy and unwieldy. It's difficult to anticipate what will happen from looking at the URL.

Ideas for issues 1 & 2

  1. Include the full advanced search form on every search results page, hidden by a javascript expander.
    • Pro: Complete solution!
    • Con: This form can be huge (see bug 50970 for example), and it is not the best way to merely show what criteria are selected.

  2. Show the criteria selected where they aren't "None" (i.e. when something has been selected for a given field), with a Refine link nearby that takes the user to the advanced search page. This display could be hidden using a javascript expander if it's too large.

    • Pro: Concise, easy to see exactly what criteria are active.
    • Con: Extra page load to refine the search.
    • NB: The default search criteria is for all open bugs, so we should be showing the statuses that we're filtering for on all default searches.

Note: in all cases, search criteria should always be carried across search page loads; users should never lose their criteria while they are within the "search" part of the site or a project. However, this also means we should give them a means to reset their search criteria to the default.

Additionally, we should rename the "Hide duplicate bugs" field on the advanced search form, since it's the only field of this type called "Hide..." (everything else is "Show..."). Since our default action is to hide the dupes anyway, it should be up to the user to explicitly chose to show them rather than to chose to not hide them, which is just plain odd.

Ideas for issue 3

  1. Launchpad should rewrite the URL received, removing defaults, and redirect the user to the shorter URL.
  2. Remove the field. prefix from query parameters. Björn says this means upgrading Zope.

  3. Search query language. As an alternative to composing searches from a long list of query parameters, we could have a Google-esque language: (project:malone OR project:rosetta) assignee:jtv status:confirmed "Shiny shiny" (ANDs would be implicit).

    • Searches using query parameters would be rewritten to this mini-language, making this the default way to search Launchpad.
    • An advantage: the complete query would be described in the search box, meaning that the approach of adding drop-down boxes to show the criteria would be largely unnecessary.
      • However, for the cluebatting-needed crowd, we could have an Explain button that does much the same thing.

    • There should be a way to drop back to the advanced search form.
    • Allowing arbitrarily complex expressions could mean that we end up trying to execute arbitrarily complex queries against the database. We may need a way to assess the complexity of a search before trying to execute it.

What we shall do!

After brief but intense discussion, we think that the following is the best plan of action:

  1. Show the criteria selected where they differ from the default, with a Refine link nearby that takes the user to the advanced search page.

  2. Preserve search criteria across page loads within "search" areas of Launchpad, allowing users to reset too.
  3. Rewrite URLs to remove criteria where they match the default, and redirect the user.
  4. When Zope is upgraded: Remove the field. prefix from query parameters.

The search mini-language is a very interesting and appealing solution, but we also estimate that it would be a much bigger piece of work than the above. The above gives us a lot, but with much less work required.

VersionThreeDotO/Bugs/ExplicitSearchFilteringAndCleanURLs (last edited 2008-12-23 17:16:34 by allenap)