A number of fields in the database are probably not universally applicable and
we should allow users to hide them These are:
Anything in bug #24789 that gets implemented.
Probably more ...
Notice how none of these are needed on the enter_bug screen.
So when do we hide them? Firstly, on the show_bug screen. Secondly, allow all
of these fields on the enter_bug screen, but allow them to be hidden.
Novice users should start with some of these fields off. Basically the same
configuration we have now on enter_bug, possibly without CC. Show_bug will then
be more simple for these users.
This will then allow you to make enter_bug more powerful for advanced users.
Bugs #25521 and bug #5179 could come as a part of this!
Now how much would you expect to pay? But wait, there's more!
Extend this to queries and you a simple query page for newbies (bug #16775), but
it is all still one query page, and people can define their own page somewhere
between easy and hard!
An implementation of this could really solve a lot of our problems.
This sounds like a good idea. Now the question is how to implement it. We would
need some sort of way to store this in the user's preferences. Ideally it would
be expansible for the future. How many fields are there now? If there's
significantly less than 64, we could use something similar to the groupsets that
are used now (64-bit bitfield). Also, how much should be visible to the user
that hasn't logged in yet? We have to remember also that not everyone has
cookies turned on. With the amount of personalization happening in Bugzilla now,
it's almost impossible for anything to work correctly without being logged in
yet. Probably what should happen is a GoAheadAndLogIn tag be added to each of
the pages that change based on what your user access is, and the Log In link at
the bottom should always point to the page you're already viewing ("Log in and
view this page again"). This is almost a subject for another bug, but it has an
affect on how this idea would get implemented, so I'm mentioning it here.
Whoa, slow down.
I don't really like the idea of having bugs appear differently to different
people. That will just lead to lots of confusion. (Person A says "why does
this bug have the foo keyword on", and person B says "hey, I don't see that,
what are you talking about?")
As far as letting more advanced people do things on the query screen, that's not
a bad idea, and is already covered somewhat by bug 25521.
It sounds to me almost like you are proposing an infinitely customizable query
screen, with tons of pieces you can add or subtract at will. I'm not sure I
like this idea at all. I don't like it because 1) It will mean TONS of new
preference settings to remember, and 2) If you REALLY want things to be simpler,
I say that also means keeping the number of complicated/confusing preferences
down. It is NOT much help to simplify the query screen for immediate use if it
only means people will now have to select lots of new/confusing preferences on
the matter later.
For these reasons, I would rather see a simple query screen, which has only just
enough functionality to cover what (I think) about 90% of all newbies want to
enter for queries: namely keywords, be it in the summary field, or the
description field. Someone correct me if I'm wrong, but it sounds to me like
the proposal made in the second attachment of bug 16775 should be able to cover
that 90% of newbies. I favor using that as a basis for the simple query screen,
then having simply ONE preference, to allow the user to select whether he wants
to use that or the advanced query screen, where we can put things like the
boolean charts, the keyword, status whiteboard, assigned to fields, etc.
Um, this bug was proposing hiding things in the show_bug page, not in the query
Rereading the original description, it looks like it was proposing both... After
seeing the other comments here and thinking about it some more, I do agree that
the number of preferences required for doing this would ultimately wind up more
confusing to a newbie than the simplified form it would result in would. I would
perhaps opt for 2 or 3 predefined layouts with a preference to choose one of
those, rather than having it "infinitely customizable" as proposed.
Yes, it applies to all pages. You could have a different preference for each
page, but that would be going overboard.
It's not going overboard to have 20 (for example) different fields you can turn
on or off. Not at all. People seem to be confusing 20 similar preferences with
20 different preferences.
Adding 20 different preferences for 20 different features can be a preference
overload. But these 20 preferences all _do the same thing_, add or remove a
field. There is only one thing to understand here for a user.
Sure, they'd need to understand each field, but it's simple enough to explain
what each field does on the preference page, and simple enough for a user to
decide whether they want it. This would pretty much be a once off thing.
You could have a set of field profiles, but I don't see that we're going to be
able to get a set that fits everyone. Of course, a set of profiles plus a
custom profile option is always a choice.
Not logged on users should see the default set of information for a new user.
> I don't really like the idea of having bugs appear differently to
> different people. That will just lead to lots of confusion. (Person
> A says "why does this bug have the foo keyword on", and person B says
> "hey, I don't see that, what are you talking about?")
If you believe this is going to happen, the simple thing to do is explain it to
new users when they register. This is a small price to pay in my opinion. If
someone actually cared about the keywords they would likely have them on, and
that's the point of this bug.
So, yeah, this will happen, but it happens with every feature. Will it happen
enough to warrant not implementing it? I don't think so. If this does start
happening regularly we can ask people why they didn't read the docs and go from
> As far as letting more advanced people do things on the query screen,
> that's not a bad idea, and is already covered somewhat by bug 25521.
I guess this could make the query screen more complex if the user desires, but
it's mainly about simplifying it.
Just a thought, if there was a wizard for setting preferences including this at
account creation time, that would let users know more about the features of
Bugzilla, including this.
No. 20 similar preferences are still 20 preferences. Big preference screens
are a nightmare. I'm not going there.
Also, 20 boolean preferences mean 2^20 = 1048576 different possible settings.
QA people hate that kind of thing.
This whole thing is not likely to happen anyway, for reasons I've already
For a good example of what Terry just described, just look at edituser.cgi. :)
The list of available access bit checkboxes is getting pretty big, and it already
looks cumbersome. :) And there's only 10 or so of those by default. (I'll file
another bug for an idea I have to clean that up a little)
Just wanted to say that although I do not agree with the solution Matthew Tuck
proposed here, I do think the original problem he aimed to solve is a very valid
one. Correct me if I am mistaken anyone, but my impression is that everyone
here pretty much agrees with the original problem raised, namely that some
simplification of the simple query screen is necessary.
I still personally favor the idea of adopting a simple "90% of all simple
queries" query screen, and then having a single preference to allow the choice
of this or an advanced query screen, where we could put things like the "boolean
charts" feature (an *outstanding* innovation, which also originally came from
the mind of Matthew, I might add, and brought to life by Terry once he figured
out a way of implementing Matthew's idea). Reason I am writing this is because
I just wanted to make clear that I am not meaning to shoot Matthew down flat out
here. I do NOT want to do that at all... I am only saying that I do NOT agree
with this *particular idea* of his. It is an *interesting* idea, but I think
there are some very good reasons (which I have already stated) why this idea
would only make things worse.
Another possibility, maybe, would be to have 2 different layouts for the query
screen, the way the Mozilla Mail & News client currently has (2-pane or 3-pane
view). This would be a compromise on Matthew's original idea. However, I still
favor having a pref to choose between simple & advanced query screens. The
reason I favor this is because I still think there is some functionality in the
query screen which "newbies" (as we were originally discussing) do not need, and
don't want, as it simply makes things confusing. I say, let us "divide and
conquer" the two different camps of Bugzilla users, namely the newbies, who want
a simple query screen for their first queries, and an advanced screen, for those
who want to do more advanced stuff, and who aren't as easily put off by
complexity, and/or who have mastered the basics of Bugzilla.
I think we're starting to stray from the topic of this bug report, but I think
zuperdee's got something here. What if we created a "Most Common Searches" page,
and add a button to the advanced query page for anyone with a certain superuser
priv to "Add this query to the Canned Queries page"?
An interesting idea... But there are 3 problems I see with that: 1) How many
"most common queries" will there be? Bugzilla is a dynamic thing, and bugs
change all the time. The bugs that are open/active now might not be active a
year from now. If we simply let the "most common queries" build up infinitely,
we've got yet another problem on our hands: namely, lots of outdated queries
that simply keep building up. 2) Creating a "superuser," as you say, IMHO,
would only create a further division among Bugzilla users. Since all Bugzilla
users are essentially in the same boat with regards to the fundamental purpose
(to report, document, and help diagnose/fix bugs), I think creating an
upper-class and lower-class bug reporter like this would simply tick off some
people. I for one do NOT like the idea of creating a user that has further
privileges with Bugzilla that I do not have. For Bugzilla to be of maximum
utility, EVERYBODY needs to have equal chance of using all of its features.
Granted, not everyone is as experienced with Bugzilla, but I think everyone
should have an equal OPPORTUNITY to use its features. Creating a superuser like
this does not further that goal. 3) Further to #2, just what would the criteria
be for admitting "superusers?" I think it a very dangerous idea to start
categorizing Bugzilla users according to how well they post bugs, for example.
This would open the door for censorship, which IMHO, is not in ANYONE's best
By 'superuser' I meant the person who maintains bugzilla, or someone he's
designated to help out. Hate to burst your bubble, but bugzilla already does
this and has for quite some time. Only people with the correct privs set can
edit user accounts, and change the system preferences, etc. This is what I
meant. The ability to add/remove things from the canned query page would be
restricted to someone with one of those maintenance bits set.
That seems to me like it would create a lot of extra work for the maintainer of
Bugzilla, especially since as I say, common queries might change from
day-to-day. IMHO, another problem with this idea is: how do you display such a
list? I think it would be quite impractical to show each possible query if it
followed the form of the current query screen, for example. For this reason, I
favor the idea of cleaning up the query screen first.
Well, for example, I have a couple canned queries on my site. In this case,
they're hard-coded in the index page, but a simple description of what is being
searched is all that need be placed on the "canned queries" page. You don't need
a complete list of all the parameters. For a good example, take a look at this
page: <http://www.intrec.com/bugs> and look at the links on the right-hand side
of the page. I have no argument against cleaning up the query page however.
firstname.lastname@example.org is the new owner of Bugzilla and Bonsai. (For details,
see my posting in netscape.public.mozilla.webtools,
moving to real milestones...
-> Bugzilla product, trying User Interface component, reassigning.
my .02 cents.
Getting back to the core of the summary which I think we can all agree on. The
pages both Show bug and Report a bug are both busier than they need to be for
the novices (end users outside of pure development/qa folks).
Here is my solution:
1. Take the current 2.17 query screen, move Status up to the top fold (above the
2. Put a button called "ADVANCED" that hides all the stuff below that fold.
3. Apply something very similar for the report bug screen.
4. Global or per-screen would be fine, everything else like multiple bug edit
and such just falls under advanced.
The simple truth is that too many form elements simply SCARE novice users. Give
then enough to get their feet wet, then they can just turn on advanced. I'll
leave mine on advanced.
The User Interface component now belongs to Gerv. Reassigning all UNCONFIRMED
and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component
owner) to Gerv.
Reassigning back to Myk. That stuff about Gerv taking over the User Interface
component turned out to be short-lived. Please pardon our confusion, and I'm
very sorry about the spam.
Ok, so there are three pages in question (query, enter bug, show bug) and two
basic approaches (views by user type, user-specific field preferences).
Regarding views, we already have them (a.k.a. template formats), so the fix is
simple: just create additional user type-specific templates for each field, and
have a single preference for saying what type of user we are. Unfortunately I
don't think we can come up with sets that satisfy enough people enough of the
time, and even one missing field can be a serious impediment to a user.
As for the latter, as Terry said tons of preferences are annoying, but we could
use DHTML to embed the UI into each page (f.e. via + or - toggles) so the user
never has to see a "preferences page" to configure their UI, they just delete
the fields they don't want to see and add back the ones about which they change
*** Bug 301814 has been marked as a duplicate of this bug. ***
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).