154782 - use javascript to provide "simple" query form.

Status: RESOLVED DUPLICATE of bug 450301

(Bugzilla :: Query/Bug List, enhancement)

Description

[James Henstridge]

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.

Comment 1

[James Henstridge]

Attachment: mockup of "show/hide advanced options" button

I added a javascript function called toggleAdvanced(), and a button like the
following:
  <input type="button" id="advanced_toggle" onclick="toggleAdvanced()"
	 value="Hide Advanced Options <<">

I then added name="advanced" attribute to the elements containing advanced
fields.

Comment 2

[James Henstridge]

Attachment: 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
between sessions.

Comment 3

[Christian Reis]

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?

Comment 4

[James Henstridge]

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().

Comment 5

[Matthew T (active 1999-2002)]

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.

Comment 6

[Christian Reis]

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.

Comment 7

[James Henstridge]

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.

Comment 8

[James Henstridge]

Attachment: 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.

Comment 9

[James Henstridge]

Attachment: 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 ...

Comment 10

[James Henstridge]

Anyone had a chance to look at this since I put up the patch?  Seems to run fine
on our local 2.16 install.

Comment 11

[Luis Villa]

James: think you can update this and check it in to the new b.g.o? If nothing
else it'll get testing there :)

Comment 12

[James Henstridge]

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.

Comment 13

[Christian Reis]

Fair enough; but shouldn't the advanced options be *hidden* by default?

Comment 14

[James Henstridge]

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.

Comment 15

[Christian Reis]

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.

Comment 16

[James Henstridge]

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?

Comment 17

[Matthew Tuck [:CodeMachine]]

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.

Comment 18

[Max Kanat-Alexander]

Whaddaya know, we actually ended up doing this. :-)