Open Bug 31144 Opened 25 years ago Updated 13 years ago

Let user hide some fields.

Categories

(Bugzilla :: User Interface, enhancement, P3)

Product:
Bugzilla
Component:
User Interface
Type:
enhancement

Tracking

()

People

(Reporter: CodeMachine, Unassigned)

References

Details

A number of fields in the database are probably not universally applicable and we should allow users to hide them These are: Keywords Dependencies Priority Assigned To QA Contact Target Milestone Status Whiteboard CC Anything in bug #24789 that gets implemented. Attachment facilities. 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 page.
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 there. > 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 stated.
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 interest.
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.
tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Whiteboard: Future-Target
moving to real milestones...
Target Milestone: --- → Future
-> Bugzilla product, trying User Interface component, reassigning.
Assignee: tara → myk
Component: Bugzilla → User Interface
Product: Webtools → Bugzilla
Version: other → unspecified
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 <HR>) 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.
Assignee: myk → 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.
Assignee: gerv → myk
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 their minds.
Whiteboard: Future-Target
Target Milestone: Future → Bugzilla 2.22
*** 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).
Target Milestone: Bugzilla 2.22 → ---
QA Contact: mattyt-bugzilla → default-qa
Assignee: myk → ui
You need to log in before you can comment on or make changes to this bug.