Created Advanced (More Than Now) & Basic Query Screens

VERIFIED FIXED in Bugzilla old

Status

()

Bugzilla
Bugzilla-General
P2
enhancement
VERIFIED FIXED
19 years ago
5 years ago

People

(Reporter: CodeMachine, Assigned: Terry Weissman)

Tracking

unspecified
Bugzilla old

Details

(Reporter)

Description

19 years ago
I'm not necessarily advocating removing the old query screen, but I think it is
too complex.

I think it would be better to support a sort of table based query mechanism,
where you insert rows, which might look something like.

 /     Days      <       3
 \ AND Component Is      {Bugzilla, MailNews}
OR     Reporter  Is      Me

You get the picture - similar to the filter conditions in N4.x.  It would not be
so cluttered and in fact most queries would be quite small.

You could achieve things you can't with the current screen, and also could do
more complex queries than A OR B OR C or A AND B AND C, like A OR (B AND C).

This being said, the original paradigm for a query screen could be simplified
for newbies - get rid of the more complex less often used machinery - I've often
heard people say it's too complex.

This probably requires some sort of DOM or something - I'm not hugely familiar
with this so I don't know.
(Reporter)

Comment 1

19 years ago
BTW, don't get distressed over all the bugs I'm submitting to you Terry, I just
like to get things off my chest and they're good placeholders for letting
people to know what to do.

Speaking of which, it's probably a good idea to join the [HELP WANTED] effort
and mark some of Bugzilla enhancements as such.
(Assignee)

Comment 2

19 years ago
The problem is that I know of no way of doing this without using JavaScript.
I'm not even sure if it is possible with JavaScript; you may have to use Java.

I am religiously opposed to requiring JavaScript (or Java) for any vital
Bugzilla operation.  I don't mind JavaScript being used to quietly enhance a
page, but I don't want any real functionality to depend on it.
(Reporter)

Comment 3

19 years ago
Yes, I assumed it would need JavaScript too.  That's part of the reason I said
to leave the old page.

The current bug page will never be as powerful as people might like.
Continually adding to it should not be an option, as it's already too big IMHO.
 I understand the tradeoffs and why these decisions were made.

For example, there's only two name tests, only one test for "Where the
field(s)", etc.  Some regexps could be easier specified as AND of two
substrings, etc.

Even adding new fields is not going to let you get full functionality.  You need
boolean expressions for this.  Maybe an adequate fallback would just be a place
where you could enter an expression in a text field.  This would give a fallback
for non-JS users.  For this to work, you'd want a button on the simple
query to convert this to an advanced query, and possibly in the opposite
direction to if possible for the query.

If you did this, so ALL users had access to this advanced functionality, you
could then safely remove some machinery from the simple screen.  This trick is
to find what is used least often by the least number of people.  =)
(Reporter)

Comment 4

19 years ago
Sorry, forgot to mention I added to CC someone who might be interested ...
(Reporter)

Updated

19 years ago
Summary: Table-Based Query Screen → Created Advanced (More Than Now) & Basic Query Screens
(Reporter)

Comment 5

19 years ago
I imagine the text language would be something along the lines of:

language ::= open_expression

open_expression ::= and_expression | or_expression | xor_expression |
impl_expression | closed_expression

closed_expression ::= ( open_expression1 ) | simple_expression | NOT
closed_expression

and_expression ::= closed_expression AND and_expression
or_expression ::= closed_expression OR or_expression
xor_expression ::= closed_expression XOR closed_expression
impl_expression ::= closed_expression IMPLIES closed_expression

simple_expression ::= field operator value
value ::= simple_value | set

in a pseudo-BNF.  The precedence is NOT, binary boolean, binary comparison.
The first of these is quite easy to remember, and the second is the only
possible way to do it.

It's also intended to be totally interchangeable with the table, the only
difficulties in writing the table version being the necessity to indent to show
bracketing and requiring links at the same level to use the same operator.  This
is fairly similar to NN4x's Mail Filter dialog, except this would allow A AND (B
OR C).

Some fields you might have that you don't have now includes BUGNUM (now you
can't query on a range of numbers), NAMES (union of all the names fields to keep
some of the current combined field functionality), DEPENDSON, etc.  You could
also do something like:

( Platform = PC And OpSys = Linux ) Or ( Platform = Macintosh And OpSys =
FreeBSD )

But I think the main benefit is to get a really basic query screen.

Improved description of bug.

Comment 6

19 years ago
Hmm...  Sorry I've taken so long to say anything.  Anyway, this is indeed an
interesting problem.  And I agree with Matty that the current query screen will
never be able to support all the various enhancements that people are
requesting, without becoming more and more complex and unwieldy.

If I am understanding everything correctly, then what it boils down to is this:
In order to create a more powerful query screen in a simpler, more
comprehensable format as Matty suggests, Java and/or JavaScript might be
needed.  So the major hurdle faced here is: Is there some way to move forward,
while remaining backwards-compatible with non-Java/JavaScript browsers?  I
believe this might be possible; why not use the <NOSCRIPT> tag in addition to
the <SCRIPT> tag, in order to make it possible to have an alternative display
for non Javascript-enabled browsers, and use the new HTML 4.0 <OBJECT> tag to
embed a Java applet if needed, since the <OBJECT> tag is designed in such a way
that again, an alternate display can be presented for non-Java enabled browsers?

I realize this will inevitably complicate the design underlying the query page,
but I still believe this may be the way to go, since it would solve the problem
of remaining backwards compatible while still allowing us to move forward.  Not
only this, but one could then remove the backwards-compatibility stuff cleanly
and simplify the underlying HTML if/when the backwards-compatibility is not a
concern anymore.

So what do you guys think of this idea?
(Assignee)

Comment 7

19 years ago
I will resist any and all attempts to make the primary query screen be Java or
Javascript based.  At best, that means we'll have two interfaces, and one of
them will always end up being second-class and lag behind.  I'd rather explore
other ways of making a better HTML based interface.
(Reporter)

Comment 8

19 years ago
Howso?  It would not be impossible to design a textual and table-based
alternative of the advanced query screen.

You would need to list the fields and what type of data they were.  From there,
both screens would work out what they accepted.  As far I can tell, fields would
be the main changes.

Comment 9

19 years ago
Interesting...  I am looking at the HTML of query.cgi right now, and it looks to
me like it already does employ some JavaScript--and for critical functions,
whats more.  I think we should all look at this thing a little more
carefully...  Since it does employ JavaScript already, I think all one would
really need to do is play with the layout of the thing a little; I like Matty's
idea of making it more like the filter conditions in NS 4.x.  Perhaps he should
create a sample, just to show what it might be like?

Comment 10

19 years ago
BTW Terry, if JavaScript/Java are not viable options, how about CSS, XUL, or
HTML 4.0 features?  Would ANY of these be viable options?
(Reporter)

Comment 11

19 years ago
I don't know JS, and I'm unlikely to have time to learn it soon.

I do however have a rudimentary understanding of what the DOM is and does, and I
doubt there's anyway to do my full proposal in HTML (unlimited size, indenting,
choosing operator choices depending on the field chosen, etc), although you
might be able to do a subset.  These all surely require DOM, since they all
involve changing the page's structure.
(Assignee)

Comment 12

19 years ago
Yes, there's a fair amount of javascript there.  But things are very carefully
constructed to work almost as well without javascript at all.  (The javascript
automatically trims down the versions and components list when you select a
product, but you don't really need that trimming to get stuff done.)

I am not interested in anything that seriously restricts what browser you can
use to run bugzilla.  (Yes, yes, I've had some Lynx bugs in the past, but there
was never fundamentally anything being done that busted Lynx.)  Bugzilla is a
pretty simple thing, and it should be useful with a pretty simple browser.  So,
yes, I think this means you can't use CSS or DOM or XUL.
(Reporter)

Comment 13

19 years ago
Terry, I'm not sure that I understand your comments.  I believe I've outlined a
way to do this that would fully work with Javascript turned off.
(Assignee)

Comment 14

19 years ago
If you're talking about a pure text language based mechanism, well, I'm not
really interested in that.  People want to do complicated queries without
learning a language.

I'm not sure what other proposal you've made that can be done in simple HTML.
You yourself said that the original one couldn't ("requires some sort of DOM or
something").
(Reporter)

Comment 15

19 years ago
Yes I am.  "Age < 3 And Reporter Is Me" is not a difficult sort of thing to
learn - it's not as if it's a programming language or anything remotely close to
it.

It's intended to be for advanced users anyway.  If they don't want to learn it
they have two alternatives - simple queries and turn javascript on.

I suggest that anyone who browses with javascript off is likely to be advanced
enough to learn the language quickly.  And further - the small size of the text
field to enter the query would leave plenty of space for a "quick language
reference".

Comment 16

19 years ago
I'm not sure I entirely agree that anyone advanced enough to turn JavaScript off
is likely to be advanced enough to pick up a new query language.  And I also
think in this day of GUI-based everything (whether good or bad), we should
probably be aiming to provide an improved GUI query screen, which is also
accessable by text-based user agents like Lynx.

If I am understanding things correctly now, I think Terry feels very strongly
that all of the functionality that the query screen offers should be accessable
to anyone--no additional functionality that is only accessable by a select few.
I can understand this.

While I do agree that it will be hard to overcome some of the main limitations
in the current design without the use of DOM features, I think we should
continue trying to find ways of improving it with simple HTML first.

Someone correct me if I'm wrong, but I think we all agree that there is
definitely room for improvement in the query screen as it currently stands.  The
example Terry gave of "acceptable" JavaScript use with the selective narrowing
of options now gives me a better idea of what would be acceptable on this front;
in particular, I think Terry is saying that aesthetic improvements are okay, but
no real functionality should depend on it.

As a result of Terry's example, some ideas are starting to come to mind here for
improvement of the query screen with simple HTML/limited JavaScript.

Incidently, I use Lynx occasionally too, so I can easily test for this.  Also, I
saw a bug here before about Bugzilla not working well with Lynx.  So I think
this is *definitely* a consideration.

I will attach a sample of what I have in mind a little later...  Beware--it has
been a while since I've done HTML or JavaScript, so I might be a little rusty,
but hopefully this will still give us some more ideas.
(Reporter)

Comment 17

19 years ago
I'm suspecting you're referring to having about 10 rows of 3 comboboxes and a
not checkbox?  It could work, but it certainly has problems.  You would
obviously have lots of blank rows at the bottom, and would have no way of
expressing A OR (B AND C), which I think is important.
(Reporter)

Comment 18

19 years ago
Some more useful query elements.

LastBugNum and NumBugs: useful for getting only the last x bugs.

Reports: Traverses duplicate links to work out how many times this bug was
reported.  When combined with general summary reports (bug #12282), could
provide an easy standard way to generate the most frequently reported bug list.
(Reporter)

Comment 19

19 years ago
One benefit of this to me is for my personal query, which shows those bugs I'm
cced on or reported.  I would like to be able to make a query that shows
resolved, etc bugs, but only if they haven't been changed in (say) 14 days.
ATM, I either have to remove the resolved bugs, restrict everything to the last
14 days, do two queries, or just let everything through, as I do.
(Reporter)

Comment 20

18 years ago
Also useful would be ResolvedBy, to see who resolved what.  In conjunction with
general summary reports (bug #12282), you could see who resolved the most bugs,
for example.  And further, ResolvedBy could probably be computed.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2
(Assignee)

Comment 21

18 years ago
So, I've been kicking an idea around in the back of my head for a while.  There
*is* a way to do a pretty cool UI, somewhat similar to the original proposal,
using only plain ol' HTML forms.

Please check out http://www.weissman.org/proto/chartprototype.cgi and give your
opinions here.
(Assignee)

Comment 22

18 years ago
I have implemented my above proposal.  I declare this bug FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 23

18 years ago
But the query screen looks the same to me as it always has.  Where's the
change?  It doesn't look anything like the prototype.  I liked the prototype--it
looked nice and clean.
Status: RESOLVED → REOPENED

Comment 24

18 years ago
Okay, I'm dumb.  I guess I do see it there.  But I'm confused--is this supposed
to be in addition to the old system, or what?
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago

Comment 25

18 years ago
It works!  I guess that verifies this bug fixed.  Any other comments, Matthew? 
I like this new query system--I think it has much more potential than the
"traditional" query system, not to mention quite a bit cleaner & simpler (I
think).  If it could be polished up a bit, I wonder if this wouldn't have a
fighting chance of replacing the old system altogether.  I think the old query
system was getting much too large and unwieldy, but then maybe it's just me.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 26

18 years ago
You can make a case that all the fields in the query page that have type-in
values could be replaced by this.

But I don't think it suffices to replace things that have menus of items.  It's
not nice to expect people to start typing things like "WORKSFORME" into their
queries.
(Reporter)

Comment 27

18 years ago
Sorry, I should have commented on this by now.  Overall, nice to have this in
place.  If any issues below are worthwhile submitting as other bugs, let me
know.

Good idea about including this beside the existing system.  Maybe we could have
a pref to allow a user to pick which one they want, or both, though.

There are still a few special conditions that would be nice to implement
(ResolvedBy, CreateDate, Age).  Another possibility is RowNum (row in the
resulting bug list, to prevent more than x bugs appearing for example), although
this could be considered to be outside of the selection mechanism (you're
unlikely to care about any other relation than "at most x bugs".

Also "Me" as a special name (allow a subjective yet prepackaged link).

It would be nice to augment the existing system with Javascript where available
to prevent a page reload when you click And or Or, as well as preventing insane
input, which the rest of the page does.

Here's a list of things I think could be nuked from simple query:

(a) The bug list by bug number feature, provided the 3rd field allows specifying
sets of bug numbers.
(b) One of the email boxes.
(c) Make the first email box substring only.

I'm still trying to think about a better way to deal with the boolean chart
conundrum too, I don't really like it as it is.  The obvious way is some sort of
variable specification, ie action A changed on date Y and action A/B changed by
person Z, but how that fits in to what is there already I don't know.

Comment 28

18 years ago
I like the idea of setting up a pref to allow the user to choose whether he

wants the old or the new query screen, too.  Terry, what do you think of this

idea?  I think it would at least enable those who want only the old or only the

new system to have a less cluttered query screen.

(Assignee)

Comment 29

18 years ago
Yes, I still want a simple query page; see bug 16775.
(Reporter)

Comment 30

18 years ago
I've finally got around to filing my supplemental bugs, see bug #41651, bug
#41652, bug #41653, bug #41654 and bug #41655.  Dupe count is already filed as
bug #38857.
Moving to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
QA Contact: matty
Target Milestone: --- → Bugzilla old
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.