The new design for the query page is a lot nicer to use (with all the most used
fields at the top), but I still find some people complaining about the number of
fields (even though they can ignore them).
As an experiment, I tried adding support for hiding some of the fields on the
query page. I added a button that can be used to show and hide the more
advanced options. At the moment, it leaves everything visible to start with,
but it could be extended to get/set a cookie to make the show/hide state persistant.
Will attach a mockup based on the new query page soon.
Created attachment 89545 [details]
mockup of "show/hide advanced options" button
<input type="button" id="advanced_toggle" onclick="toggleAdvanced()"
value="Hide Advanced Options <<">
I then added name="advanced" attribute to the elements containing advanced
Created attachment 89549 [details]
New version of mockup
Here is a new mockup. This one hides the submit options at the bottom of the
form (including the second submit button -- in simple mode, the one at the top
should be enough).
It also sets a cookie so that the show/hide advanced options state is preserved
This might be an acceptable answer for fast client-side simplification of the
query form (there are bugs that propose simple forms, but i think your approach
is quite nice).
I suppose this doesn't break in Non-JS browsers? Issues I see
a) The HRs don't disappear when button clicked here (moz 2002061908)
b) The placement of the button might need some work.
Anybody +1/-1 the proposal?
With JS disabled, all fields will remain visible in my mockups. There will
still be a "hide advanced options" button which doesn't do anything, but this
could be solved by generating the button with document.write().
Kiko ordered me to comment in this bug, so here goes: At the moment, the button
doesn't do anything in MSIE 5.0 for Windows, so I (being at work) can't see
what it does.
Actually, I think it can be solved by either using a <BUTTON> tag or placing it
inside a <SCRIPT> section, if I'm not mistaken. Let's get caillon to tell us for
Just checked it with IE 5.5sp2 on windows, and I see the same results as mpt.
It looks like the document.getElementsByName() method is returning an empty node
list. I will see if I can find a workaround.
Created attachment 89663 [details]
new version. This one tested with IE
Okay. Here is a version that I have tested on Mozilla 1.0 and Internet
Explorer 5.5sp2. It adds a findElementsByName() function that attempts to use
document.getElementsByName() but falls back to walking the DOM tree (this way
we use the faster getElementsByName() if it is available).
Also, I was previously setting the elements to visible again with
"element.style.display = null;" which IE didn't like, so I have changed to to
"element.style.display = '';" which both browsers seem to like.
Created attachment 90197 [details] [diff] [review]
A patch to the templates to add the advanced options button.
This patch against form.html.tmpl and search.html.tmpl implements the advanced
options button, as demonstrated in the mockups attached to this bug. It seems
to run quite well on a local copy of bugzilla (CVS checkout from 2.16 branch).
It might be better to implement this with a user preference, rather than a
cookie as it is at the moment (I did it with a cookie, as it was quick, and
limited how much bugzilla code I had to read :). Having it implemented as a
user preference (stored server side) would mean that the setting would follow
the user around.
This could be done by adding a hidden form field that stores this value. On
query page load, set the advanced options state based on this field. When the
state is toggled, change the value of the hidden field. When the form is
submitted, update the user's preferences based on the value of the field. I
don't know if I will have time to do anything like that though ...
Anyone had a chance to look at this since I put up the patch? Seems to run fine
on our local 2.16 install.
James: think you can update this and check it in to the new b.g.o? If nothing
else it'll get testing there :)
Okay. I adjusted the patch for the bugzilla.gnome.org templates, and it is now
Seems to work okay.
Fair enough; but shouldn't the advanced options be *hidden* by default?
I just realised that it wasn't remembering the setting of "show advanced
options" on bugzilla.gnome.org. This seems to be due to a change in the Gnome
bugzilla templates (global/header.html.tmpl wasn't setting onload on the <body>
element). I fixed this in CVS, but it will have to be updated on the web server.
Christian: that would be trivial to do once the global/header.html.tmpl problem
is fixed. I'll ask the gnome bug squad if it is desirable first though.
My point is: if by default all the fields are displayed, then the first time a
new users sees the form he will still be overwhelmed by the fields (and he'll
have to discover the button to hide them between all those option selects). If
it's hidden by default, it becomes a bit more obvious because there are simply
less controls for the user to stare at.
Sure. Hiding it is probably the correct default for Gnome. However when I
submitted this bug there seemed to be a fair bit of hostility against patches
that hid options if the user didn't have cookies enabled (and hence wasn't
Has the philosophy changed since then?
I don't understand the great need to hide stuff. Yes, there is a bit of an
aversion to having things work differently for different users from a support
What is wrong with just moving all of the advanced/optional stuff to an
"advanced" section below, kind of like the query page. It lets users access the
fields if they want, but it also lets beginners ignore the entire section.
Whaddaya know, we actually ended up doing this. :-)
*** This bug has been marked as a duplicate of bug 450301 ***