179339 - Simplify and improve the stored query mechanism

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement, P2)

Description

[Gervase Markham [:gerv]]

Several things (e.g. bug 179281) have suggested to me that the UI associated
with named queries needs an overhaul. Here are my suggestions. The aims of this
change are as follows:

- Simplify the UI on the search page
- Reduce the number of links in the footer, which gets bloated with lots of
  queries
- Make manipulating stored queries easier to understand
- Avoid making them harder to use for an expert

As now, we need to be able to create them, run them, load them and forget them.

Creating and deleting them happens on buglist.cgi, at the bottom of the page:

( Remember ) this search as: [         ]
or instead, if you've just run a stored query:
_Forget_ | _Edit_ this search "AssignedToMe"

Running them is always done from a dropdown list in the footer:

... | ( Find ) bug # [      ] | ( Run ) search [ AssignedToMe |V] | ...

If JS is turned on, the search runs when you choose an option from the list, and
Run is not a button.

The word "search" could be hyperlinked, replacing the current "Query" link, if
that wasn't thought too confusing. The "edit" links would be a dropdown too.

query.cgi's knob would then be vastly simplified to:

( Search )
   [ ] and remember these as my default search options

Other changes:
"My Bugs" becomes a default entry in the stored queries table, inserted at
account creation time, instead of being hard-coded.

All queries appear in the footer, the links toolbar, and nowhere else, so
linkinfooter goes away, along with its UI on userprefs.cgi.

Results:
- No loss of function
- Confusion about doing an action _and_ running the search is avoided
- Queries are as easy to run as before (one click with JS)
- Footer is simpler
- Search page knob is much simpler
- User preferences are simpler
- Admin config is a bit simpler (mybugslink goes)
- You can refine a search, and then remember it on the results page when it's
  correct

Comments?
  
Gerv

Comment 1

[Myk Melez [:myk] [@mykmelez]]

>- Queries are as easy to run as before (one click with JS)

Well, almost as easy.  What's harder is that you don't see the names of your
defined queries until you activate the control and that you have to drag in
addition to clicking.

Still, I like this proposal a lot, and I think it does the right thing UI wise.

You may want to separate the backend-changes of making "My Bugs" be a regular
query into a different bug, and you need to find a way to run the default
(first) query, which is either to have the drop-down menu display nothing by
default or to leave the "Run" button enabled for users with JavaScript.  Of
these I think the latter option is better because it makes the menu's function
more obvious.

Comment 2

[Gervase Markham [:gerv]]

Myk's right. Let's make Run unconditionally a button - easier all round. 

Gerv

Comment 3

[Gervase Markham [:gerv]]

justdave: I need you to approve this idea before I start working on it :-)

Gerv

Comment 4

[Dave Miller [:justdave]]

I like it.  My only concern is how to edit a query without having to run it
first.  For example, if Bugzilla changes and breaks one of my queries (which
recently happened when Bugzilla changed from Attachment Statuses to Flags)
buglist.cgi spit out a nice red error message when running the bad query.  I'm
betting our error interface doesn't allow you to have the controls to edit or
forget the query on the error message, so I would have been stuck under this new
plan with a query I couldn't edit and couldn't delete.

Comment 5

[Gervase Markham [:gerv]]

Good point. We would need to make it so that if queries fail, they fail in a way
which includes the controls to manipulate that query. An annoying wrinkle, but
not insurmountable.

I'll start implementing at some point, then, bearing that in mind.

Gerv

Comment 6

[Gervase Markham [:gerv]]

Attachment: Patch v.1

OK, here's v1. It does what the spec says, basically. On the way I fixed a
quoting bug in an error call and a localisation bug with the "Bug List" title.

I had some issues involving the fact that <form> is a block level element, and
so needs to be in its own table cell unless you want breaks to appear. That's
why those new table cells have appeared for Find Bug and Run Search.

Phase 2 will involve fixing My Bugs to be a stored query, and removing
linkinfooter from the schema.

Known limitations:

- Until Phase 2 is implemented, there's now no way to hide (or show, if it's
hidden) the My Bugs link.

- This doesn't deal with the issue raised by Dave in comment #4. Which error
messages need to possibly have the deletion link? Any that could possibly be
raised by a bad query?

Gerv

Comment 7

[Gervase Markham [:gerv]]

Comment on attachment 115323 [details] [diff] [review]
Patch v.1

Myk - could you look at this one?

Gerv

Comment 8

[Dave Miller [:justdave]]

- "Edit Search" should be over on the right next to the "Remember this search"
or "forget this search".

- If you pick any search from the popup menu other than the default one, it
automatically runs...  if you pick the one that was selected by default when the
page loads, nothing happens.  I'm not sure of an easy way around that though...
 those darn pesky event things... :)

Comment 9

[Gervase Markham [:gerv]]

> - "Edit Search" should be over on the right next to the "Remember this search"
> or "forget this search".

It is, isn't it? I'll check.

> - I'm not sure of an easy way around that though... those darn pesky event 
> things... :)

That's what the "Run" button is for :-) Yes, it's somewhat inconsistent, but
using JS to fire the first one even when there's no change means that you could
never pull down the dropdown and change your mind.

Any other comments, Dave, or is that an r=? ;-)

Gerv

Comment 10

[Jacob Steenhagen]

> if you pick the one that was selected by default when the page loads, nothing 
> happens.  I'm not sure of an easy way around that though...

Sure there is, just add a menu option to the top that doesn't do anything w/text
similar to "Pick a Query"

Comment 11

[Gervase Markham [:gerv]]

I've always thought that dropdowns with that in are ugly. For a start, you have
to handle the error nicely (without being rude ;-) when someone submits it with
that value showing. Secondly, it removes one-click-run access to your top query,
which is a shame.

Yes, it's a trade-off. Yes, I think browsers should fire onselect events if the
person selects the same item again (as opposed to clicking somewhere else to
dismiss the select.) But they don't. 

I'd prefer the current solution, but I'm open to being swayed by a united front
of opposition.

Gerv

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 115323 [details] [diff] [review]
Patch v.1

Hmm, this seems to have rotted.  I managed to get it kind of working on my
machine and tried out the UI, which looks very good and much better than the
old UI, but could you update the patch?  Then I'll do a code-level review.

Comment 13

[Gervase Markham [:gerv]]

Attachment: Patch v.2

Unrotted version.

Gerv

Comment 14

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 122796 [details] [diff] [review]
Patch v.2

Sorry for the review delay.  I like almost everything about this patch; on a
code-level it's fine (not even any nits), and it works as expected, but I have
two UI nits and one more serious issue that needs to be thought about.

My nits are that "Saved Searches" now takes up even more space than "Preset
Queries" did and that the "Run" button is aligned with the "Find" button (and
"My Bugs" right-aligned) for no apparent reason.  It would make more sense for
"Saved Searches" to become just "Searches" or for its cell not to determine the
width of the "Actions" cell so actions links don't get pushed over to
accommodate it.  It also makes more sense to align "My Bugs" and the saved
searches form with their "Saved Searches" label rather than the unrelated form
above them.

My more serious issue is the one I brought up in comment 1, which is that this
patch makes saved searches harder to use without any significant compensatory
benefit.  Before this patch, you see all your searches at the bottom of the
screen and can click directly on one to run it.  With this patch your searches
are not visible, and you have to open a pull-down menu, scroll to one, and
click on it to run it.	The latter approach may seem "cleaner", but it's harder
to use, much like the Bookmarks menu in Mozilla is harder to use than the
Personal Toolbar.

The Bookmarks menu in Mozilla is still necessary, of course (as are folders in
the Personal Toolbar), since Mozilla users want to bookmark more links than can
fit on a toolbar, but in the case of Bugzilla it seems likely that the vast
majority of users have a very small set of saved searches, and even for the
prolific few a wrapping multi-line list of searches imposes minor pain at the
bottom of the page.

I could probably be convinced otherwise, but it seems to me that the "Run" form
is unnecessary and a change for the worse.  Thoughts?


>I'd prefer the current solution, but I'm open to being swayed by a united front
>of opposition.

I agree with you that the current solution is the best one (modulo my comments
above about the "Run" form as a whole).


> I had some issues involving the fact that <form> is a block level element

Have you tried style="display: inline"?

http://www.w3.org/TR/REC-CSS2/visuren.html#display-prop

Leaving the review request pending for discussion of "Run" form issue.

Comment 15

[Gervase Markham [:gerv]]

myk: fair enough. I'll remove the "Run" button changes to the footer and leave
that as-is. However, this patch is severely rotted, so it might take some time.

Gerv

Comment 16

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 122796 [details] [diff] [review]
Patch v.2

Removing review request in anticipation of updated patch.

Comment 17

[Gervase Markham [:gerv]]

Attachment: Patch v.3

Unrotted patch; without Run dropdown list changes (as discussed) but otherwise
identical, and with the same limitations outlined above.

Gerv

Comment 18

[Gervase Markham [:gerv]]

Attachment: Patch v.4

Slightly modified version which doesn't throw a warning in userprefs. Review
still applies. :-)

Gerv

Comment 19

[Gervase Markham [:gerv]]

(That is to say, of course, "review _request_ still applies".)

Gerv

Comment 20

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 131011 [details] [diff] [review]
Patch v.4

Looks good except some references to urlquerypart and one reference to
bugowners in template/en/default/list/list.html.tmpl need to be filtered.

Comment 21

[Gervase Markham [:gerv]]

Attachment: Patch v.5

Patch with requested tweaks. Hopefully, Myk should be able to rubber-stamp
this.

Gerv

Comment 22

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 135078 [details] [diff] [review]
Patch v.5

This fixes all filtration issues and introduces no others.  Looks good, r=myk

Comment 23

[Gervase Markham [:gerv]]

Fixed.

Checking in template/en/default/global/useful-links.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/useful-links.html.tmpl,v
 <--  useful-links.html.tmpl
new revision: 1.20; previous revision: 1.19
done
Checking in template/en/default/global/site-navigation.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/site-navigation.html.tmpl,v
 <--  site-navigation.html.tmpl
new revision: 1.9; previous revision: 1.8
done
Checking in template/en/default/search/knob.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/search/knob.html.tmpl,v 
<--  knob.html.tmpl
new revision: 1.13; previous revision: 1.12
done
Checking in userprefs.cgi;
/cvsroot/mozilla/webtools/bugzilla/userprefs.cgi,v  <--  userprefs.cgi
new revision: 1.51; previous revision: 1.50
done
Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.238; previous revision: 1.237
done
Checking in template/en/default/account/prefs/prefs.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/prefs/prefs.html.tmpl,v
 <--  prefs.html.tmpl
new revision: 1.11; previous revision: 1.10
done
Checking in template/en/default/list/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v 
<--  list.html.tmpl
new revision: 1.15; previous revision: 1.14
done

Gerv

Comment 24

[Hamid Tehrani]

If you run a Query that returns no bugs, you will not be able to save your 
query i.e. no "Remember search as" shows up. Although your query is valid and 
may return some results in future you are not able to save it.

Comment 25

[Gervase Markham [:gerv]]

Fair point. File a new bug, please :-)

Gerv

Comment 26

[victory <[e-mail]>]

Attachment: docs patch about 'Bugzilla Database Tables' section, for 2.18

Comment 27

[timeless]

Comment on attachment 214091 [details] [diff] [review]
docs patch about 'Bugzilla Database Tables' section, for 2.18

... whether show the
>+<quote>Saved Search</quote> in the user's footer or not,

whether _or not to_ show the .... footer ||,

Comment 28

[Frédéric Buclin]

Checked in on the 2.18 branch only:

Checking in docs/xml/customization.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/customization.xml,v  <--  customization.xml
new revision: 1.12.2.15; previous revision: 1.12.2.14
done

This part of the documentation no longer exists on newer branches.