So the solution to make the advanced search page less complicated is a multi-parter as always in the Bugzilla world. Here are the steps which may or may not happen in the order they appear.
Step 1. Make the big summary box at the top of the page use quicksearch instead of a summary search.
Step 2. Make the other boxes on the advanced search page work as a helper to the quicksearch
Step 3. Make the advanced search page less complicated.
1 and 2 are more or less out of my area expertise so I'll leave those to mkanat and jjclark. But making the advanced search page less complicated, I can help with.
The approach I took was inspired by the redesign we did at work, basically apply a grid and hide the stuff that doesn't matter most of the time.
I've posted mocks up on bug 450301 but since I'm sure no one wants to read through the bug I'll post the images here:
and the expanded version
What do you all think?
i like, except for "record id".
ReplyDeletei have no idea what this is.. a bug number?
Abstracting out information until requested: Good.
ReplyDeleteI use the advanced search quite often, so here my comments on why it's hard:
ReplyDeleteThe search button is never where I expect it (I often hit the "or" button, for example).
The preselected fields for the people stuff don't match my use case. I quite often want to restrict by who filed a bug.
Searching for flags is a nightmare, just because you need to know someone that knows so that you find out what to put in there.
Definitely an improvement over the existing advanced-search page.
ReplyDeleteI'd move classification/product/component into bug details. And rename "classification" to "product group" or "product type".
I'd combine "bug details" and "bug metadata". It's a confusing distinction, especially in products like Firefox where "target milestone" and "priority" are both developer-owned fields.
I'd kill the fields for searching keywords, whiteboard, url, and comments. Boolean charts work just fine for that, especially if boolean charts are made to default to "contains the string" rather than "---".
It would be awesome if the box at the top were a quicksearch box rather than a summary-only box. This would let users learn about quicksearch features slowly, rather than having to switch all at once from advanced search to quicksearch. And it would make it much easier to combine quicksearch with boolean charts. (In the rare case that you want to search only the summary, there's always "summary:" or search-by-field.)
If you used the quicksearch on top, couldn't you use tab completion instead of all those option boxes?
ReplyDeleteFor example:
1. Type "product:" and hit tab
2. The product box with all its options appear (as seen in blog post picture)
3. Select "AUS,Bespin,Bugzilla" and hit "Enter"
4. "product:AUS,Bespin,Bugzilla" is now in search bar, so product option box is no longer needed
@anonymous that's basically what bug 544404 is about
ReplyDeleteIt seems like you’re trying to dumb down the Advanced UI to make it suitable for normal users, and in the process making it more difficult for heavy Bugzilla users who regularly construct advanced queries.
ReplyDeleteIn addition, the proposed mockup requires much more space to be able to use than the existing page; you’ve lost all the benefits of information density (the mockup reminds me of the Windows Phone 7 Series screenshot in http://www.lukew.com/ff/entry.asp?1002, whereas the current UI is much closer to the iPhone in terms of being usable).
@smokey Lots of good points. I agree we're losing the information density that the current UI has in favor of a grid layout. We could and should work on getting a lot of it back, especially with the vertical real estate. We could also go for a layout that is elastic to the horizontal real-estate.
ReplyDeleteI do think a grid layout is the way to go in terms of field layout to make it more organized and approachable.
Mkanat and Ruderman have also both suggested that we reduce the number of expand widgets. And of course we'd want the UI to remember what was expanded so that advanced users are not constantly expanding and collapsing.
I'll work on another mock up that does a better job of maximizing the information density on the page while still increasing the organization.
Definitely better :-)
ReplyDeleteI think it's misleading to label the top box "Summary" if it searches other fields too.
One big thing is whether or not to include resolved bugs. Perhaps the top bar could have a checkbox for that?
Why not just kick off with:
( ) (Search)
[ ] include resolved bugs
and then have the expanded fields below that?
Sorting: now that sorting is easier and client-side, it would be better if we just always reused the same sort as last time, and let the user adjust the sort after load if they wanted something different. One less widget.
We would need to have the default search be empty, _or_ auto-expand those sections which had non-empty selections onload.
Don't call it Record ID; we have a customizable field for the name of the objects in templates anyway. :-)
Having all the titles start "search by" just makes them harder to scan. I think it would be OK to remove that. And change "Change" to "History".
Gerv
@gerv I like your resolved bugs idea. I'll see where i can include that in my next mock. Some of the other things you mentioned are basically caused by me being lazy in photoshopping an existing version of this page.
ReplyDeleteOk, Hopefully this weekend I'll get V2 of this mock up and posted to the blog, and if I'm REALLY lucky I'll get started developing it.
Thanks for all the great feedback everyone!
While Advanced Search is a hard page to make fantastically usable, this mockup feels a little more like taking the existing content and shifting it around a bunch and hiding it underneath expand-o-widgets instead of thinking about what sort of task someone has that can't be satisfied by a standard search.
ReplyDeleteSo, instead, I think we should re-analyze this screen from a perspective of what users are trying to do, and recasting the tools so they're more helpful. For example, you're proposing date widgets to help people understand how they can input dates. That's great. Should perhaps also indicate that you can do things like relative dates (ex: "-1d") and times. Instead of expand-o-widgets, maybe the advanced search could act more like a query builder, where the user enters additional matching rules. Basically turn everything into boolean charts, but add prettier UI where available.
Finally, I think that the advanced search page should show a sample set of results, always updating in an iframe. Limit to 40 results or something, but a frequent pattern on this page is tweaking the queries to get back the data you want.
@Beltzner Thanks for the great feedback. And I couldn't agree with you more (about most of it). Your analysis of the UI tweak being just hiding stuff is totally correct, and the preference for a query builder is the direction we want to go in. But the question in my mind was do we make the search page slightly better with the hiding scary fields for 3.8 and make it better in future versions with much better query builder abilities or just wait for later versions and not bother with the middle thing.
ReplyDeleteMy hope was first get people used to the page not being an explosion of fields via the hiding widgets and then in future releases, we'd add what I often describe as the mac finder query builder, but I think Thunderbird has something similar.
Your idea requires a lot more infrastructure and iteration, I was hoping for something quick for 3.8 that would be a step in the right direction but not a final step. But maybe I should take your suggestion, aim higher and make the big patch that redoes the whole page, we did it with show_bug and maybe advanced search deserves the same amount of attention.
This weekend I'm going to crack open this egg and hopefully I end up with an omelet and not a giant pile of stink!
Still trying to understand. New to this...
ReplyDeletePeter
Great blog but needs careful thinking!
ReplyDeletePeter