1529362 - Implement a whole new search experience

Status: RESOLVED INCOMPLETE

(bugzilla.mozilla.org :: Search, enhancement)

Description

[Kohei Yoshino]

This bug implements an overhaul of the search results page (buglist.cgi) which is one of the big BMO Q1 goals. Basic ideas are written in the Bugzilla UX Wiki and my UX Analysis. I’m going to interview some people, create some mockups, and look for prerequisites before starting implementation.

Comment 1

[Mark Clements]

Just to pick up on a point in the UX analyis, as I can't comment there:

TIMESTAMP FIELD:
Issues: It’s always displayed at the top of the page, but it’s not an important piece of information.
Suggestions: Replace it as the tooltip of the new in-app reload button (see above).

The timestamp is vital for printed bug lists, so make sure that whatever happens on-screen, it is still prominently shown at the top of the page when you print it.

That's a general comment, I guess, about the UI/UX work - don't forget the print requirements!

Comment 2

[Kohei Yoshino]

Not sure how many people are printing bug lists, but it’s easy to show the timestamp only for print media 🙂

Comment 3

[Mark Clements]

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #2)

Not sure how many people are printing bug lists,

Well, anyone who uses Bugzilla in a business context, for a start. We may not print to paper so much any more, but printing to PDF is a regular occurrence for various different purposes (client comms, sprint planning, etc.).

but it’s easy to show the timestamp only for print media 🙂

Easy, but also easily forgotten, and the tone of your answer implies that printing hasn't been considered at all, yet.

Please, please, please don't neglect the print requirement as part of the redesign. It is vital. Sometimes contracts are based on Bugzilla lists!

This applies for other areas of the system too (e.g. the individual bugs and the history pages).

Comment 4

[Kohei Yoshino]

Great feedback. Thanks!

Comment 5

[Kohei Yoshino]

The performance of the API has greatly improved thanks to dylan’s optimization work in Bug 1512815, but there are apparently a couple of things to make the current search queries compatible with the API, like Bug 918443 and Bug 1294519. Will try to find and fix them.

Comment 6

[Kohei Yoshino]

I already have a simple Ajax-y bug list prototype created for Bug 1478011. I’m extending it, will send a pull request next week.

Comment 7

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

Hey Kohei, is it just me or this change that landed on Custom Search broke the existing queries? I had a lot of monthly queries to filter my team issues on specific features that involved custom searches with 8-12 email addresses. They seem to partially work cause they return the right numbers on past months, but the custom search area returns no list of emails when trying to edit the query, it's blank. Here is an example (http://tinyurl.com/y2sjzkoa).
Also, if I change the time period on that query for example, it no longer takes into consideration the list of emails. So I cannot update them either in this state.

Please tell me that I don't need to redo my queries, cause will take me a lot of time...

Comment 8

[Kohei Yoshino]

Sorry, that’s probably Bug 1562139.

Comment 9

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

Yes, seems like. I'll just wait for a fix then, before updating my June queries. Thanks for looking into it!

Comment 10

[Kohei Yoshino]

This is now unlikely to happen.

Comment 11

[Mark Clements]

This is now unlikely to happen.

Why not?