Note: There are a few cases of duplicates in user autocompletion which are being worked on.

use javascript to provide "simple" query form.

RESOLVED DUPLICATE of bug 450301

Status

()

Bugzilla
Query/Bug List
--
enhancement
RESOLVED DUPLICATE of bug 450301
15 years ago
7 years ago

People

(Reporter: James Henstridge, Unassigned)

Tracking

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

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

Comment 1

15 years ago
Created attachment 89545 [details]
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.
(Reporter)

Comment 2

15 years ago
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
between sessions.
Attachment #89545 - Attachment is obsolete: true

Comment 3

15 years ago
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?
(Reporter)

Comment 4

15 years ago
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

15 years ago
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

15 years ago
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.
(Reporter)

Comment 7

15 years ago
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.
(Reporter)

Comment 8

15 years ago
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.
Attachment #89549 - Attachment is obsolete: true
(Reporter)

Comment 9

15 years ago
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 ...
(Reporter)

Comment 10

15 years ago
Anyone had a chance to look at this since I put up the patch?  Seems to run fine
on our local 2.16 install.
Assignee: endico → nobody

Comment 11

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

Comment 12

14 years ago
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

14 years ago
Fair enough; but shouldn't the advanced options be *hidden* by default?
(Reporter)

Comment 14

14 years ago
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

14 years ago
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.
(Reporter)

Comment 16

14 years ago
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.

Updated

11 years ago
QA Contact: mattyt-bugzilla → default-qa
Assignee: nobody → query-and-buglist

Comment 18

7 years ago
Whaddaya know, we actually ended up doing this. :-)
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 450301
You need to log in before you can comment on or make changes to this bug.