Closed Bug 154782 Opened 21 years ago Closed 13 years ago
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.
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 between sessions.
Attachment #89545 - Attachment is obsolete: true
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.
Ordered?! 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 sure.
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.
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.
Attachment #89549 - Attachment is obsolete: true
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 online at: http://bugzilla.gnome.org/query.cgi 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 logged in). 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 perspective. 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. :-)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.