Open Bug 1705315 Opened 4 years ago Updated 3 years ago

add usability checkbox

Categories

(Bugzilla :: User Interface, enhancement)

Product:
Bugzilla
Component:
User Interface
Platform:
x86_64
Linux
Type:
enhancement

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: Nick_Levinson, Unassigned)

Details

Attachments

(1 file)

Mockups for new-bug form, dialog about support, and unsuspension.
340.53 KB, image/png
Details

Steps to reproduce (STR):

  1. Find a bug tracker that uses Bugzilla.
  2. Start to enter a bug or feature request that is based on usability, not on technology.
  3. Look for a way to signal to readers that the basis is usability, other than nonstandard long-hand phrasing in the summary or description.

Actual result: There is no way.

Expected result:

A control, such as a checkbox.

Usability is about how a user interacts with a program. A program may be technically close enough to perfect and yet be misused because users misunderstand how to use it. A manual, help file, or user forum is not much good for people who don't use them but only ask someone a few feet away what to do or only guess and maybe fail. One solution is to improve the user interface (UI) to fit users' expectations. UIs are usually already very good, because thought already went into them. If we identify a need for a usability improvement, we should report it to a bug tracker.

It is a usability issue when, for example, the UI interferes with the expectations of users who have no interest in a program's innards. What happens under the hood is not what they were trained or hired for. They have (for example) a document to write and that's what they're concerned about. They expect the computer to "just work".

For instance, in Linux, typing rm . used to work without further ado. But it was so often misunderstood that a confirmation step was added.

I once reported a bunch of bugs and/or feature requests on a program, someone responded that these were all support requests, I corrected him, and it turned out that he was busy and only interested in violations of RFCs and that's why he thought my threads were irrelevant. It would have been better for him to defer usability issues in case another developer came along.

But usability issues in bug trackers run into highly frequent disinterest, frequent opposition, and sometimes confusion because someone thinks I'm making a support request and should not be filing at the bug tracker. It seems to be common among OSS experts across many products related to Linux and *BSD to expect users to have technical knowledge before using a program, but many other backers of OSS want to broaden user bases to include more lay users. Efforts to broaden the user base to include nontechnical users require letting people without technical knowledge benefit from using the program. This also leads to adding developers.

While product managers occasionally refer a topic to user experience (UX) people, it might help if topic reviewers understood in their first reading that the topic is in the bug tracker as a usability issue. While I have said so in the body of the topic, using various phrasings, apparently this gets missed or misunderstood.

In the same way that other characteristics can be selected for sortation or auto-notification, usability should be given that path as well.

A control, such as a checkbox, to indicate that the given thread is mainly about usability could be used even when there are nonusability issues in the same thread. The control should be used when usability is the main point of the thread, and can be labeled accordingly. E.g., the label could say, "Usability, mainly". The default would be off, for nonusability.

This control could be hidden, to be shown only when advanced fields are shown.

Every Bugzilla installation is free to define their own products, components, keywords, tags, or whiteboard entries. If any Bugzilla installation would like a way to somehow mark "usability" things then this is already possible via many many ways.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

Some of those don't apply to usability at all (product and component) and others are not clear to reporters as something they can use for the purpose (keywords, tags, or whiteboard) and those last three are not even visible to this reporter in Mozilla's instance. Some of those fields appear to be only for use by assignees (I'm not one) and most reporters won't dig through detailed field instructions to find out if they can use it to mark usability or how. I've seen entries for UX but it appears that I'm not a person who's supposed to make that judgment. (I looked at another organization's list and some of it wasn't clear to me, and it likely wasn't meant for outsiders like me.)

I raised the issue of letting the reporter saying so in a way more useful than adding it to long-form free-form text, just as bug trackers already ask whether what is being reported is a bug or a feature request or what OS is in use without hoping the reporter will accidentally think to say so. Free-form text is hard to sort by particular strings that tend to be inconsistent, so assignees can't readily collect reports on usability based on OP statements.

I'm reopening for discussion by other people.

P.S.: Above I refer to "rm . " I wrote that with asterisks surrounding the dot but I guess the software thought the asterisks were boldface markup.

I wanted to reopen but I guess I'm not authorized to. I think the closure was due to a misunderstanding, my response was not answered, and I'd like to know what other people think. I realize many people don't see a need to work on usability but it's a real need. Thank you.

My point remains: "usability" means everything and nothing to different people. It's a horrible term never to be used.

You didn't say that in your comment (and in general you should say what you mean), but if you have a better term, offer it. Meanwhile, this term is commonly used for the meaning I discussed above. If some people are confused by it, they should say why. Meaning everything and nothing is not how most users of the term use it. If you don't understand it (and you even say it's "horrible"), tell us what you don't understand about it. If you accept the concept of usability but it's just the label you don't like, propose an alternative. If you disagree with usability, speak up about why. If you oppose the concept, you could break new ground in how most of us understand computers.

If you think that smart people don't need usability, NASA figured out decades ago that it was vital for astronauts that the panic button be different from most other buttons. Most users of computers are not computer whizzes and don't want to be. A Linux computer retailer said he gets questions about how to turn the power on.

If you think a support forum is enough, most users never go there, even if you tell them. They ask their human neighbors at nearby desks and they may not know either. The software itself has to meet their needs. The software has to be made easy to use. For many years, Windows had that advantage, even though their software was worse than a Linux distro. FOSS, to reach a wider user base, has to be user-friendlier.

We need usability, whatever it's called.

Sources, e.g.:

— Jakob Nielsen has been a leader for years in usability work; see https://www.nngroup.com/articles/usability-101-introduction-to-usability/ .

— Mozilla addresses it through user experience and now calls it content design; see a variety of articles linked to at https://blog.mozilla.org/ux/ .

— For usability advice for the U.S. government, see https://www.usability.gov/ including https://www.usability.gov/what-and-why/usability-evaluation.html .

There are good definitions of usability (or UX) out there, sure. It's just that 95% of people don't know and won't read those definitions.

So adding random checkboxes does not solve anyone's problems. It's a solution in search of a problem.

  • The computer doesn't boot = cannot use it = usability issue.
  • I cannot click the button = cannot use it = usability issue.
  • Any other bug about something that does not work = usability issue.

This very issue tracker has 20 keywords for UX. If this is about some other Bugzilla instance, then feel free to create a custom "usability" keyword.

You're right that most people won't read them, but that's also true of user manuals, For Dummies books, Help files, and so on, and they still complain, and some of those complaints are still legitimate in substance. Those of us who know the concept are more qualified than other people to apply it.

Misunderstanding does not itself invalidate something. We could say that every reported bug is really about numbers or really about letters of the alphabet, since both occur somewhere in almost any bug, but we don't get confused about those. If a bug reporter is confused about either one, the report gets straightened out; we don't invalidate reports only because they have something to do with numbers or letters.

Disagreeing with something does not make it random. Random is when two things within a given category have no predictable relationship to each other so that knowing one of the things tells you nothing about the other except the category, like in good passwords.

I just opened a form on this tracker for a new report, to see if I missed something. I set it for Thunderbird (I'm not sure if I can make it generic although I tried, such as by editing the URL) and to show advanced fields. No field was applicable to the reporter reporting for usability and supporting sorting or filtering on a standard term. The Keywords field is not there. Not 20 keywords; none.

Maybe the Keywords field is only for bugs or enhancements already reported. This existing report has the field but the user has to click the Edit Bug button on a form that's already editable to a degree and then has to click the field label to get the instructions from which the user can get to the list of controlled keywords (https://bugzilla.mozilla.org/describekeywords.cgi). The field label is not obviously clickable unless the user hovers. The field itself is not obviously the place for the purpose. Insiders likely know but most users wouldn't be expected to.

In the controlled list, a search for "usab" (to get inflections like usability and usable) found nothing except "useless-UI". A search for "ux" (caseless) got 17, but even a dozen would be too many for most reporters to sift through as a condition of reporting a bug we should know about. I suggest a single control, like a checkbox, and then someone authorized to enter keywords who finds the report interesting can pick from the 17. If one of the 17 is entered, that could automatically turn on the usability control for easier sorting. We could also make the 17 as choices easier for users to know about.

The problem exists. In various fora, I get objections to usability issues that seem to be based on the idea that users should either learn it all or hire experts to do everything for them. Something may be technically sound but unnecessarily hard to use. When the Macintosh first came out with a GUI a few decades ago and CLI systems like MS-DOS were likely doomed, the Mac reduced user training from about 750 hours to about 75. Both could edit and copy, but one was easier to learn.

A problem exists, and it won't get solved by the proposal in this ticket.

Please bring your proposal. If you believe the right solution has to be different because the problem is different, tell us how. If the problem is already well described here, how long will you need to develop a proposal?

You can add whatever keyword you want to add in your Bugzilla installation, and if you think that keywords aren't helpful here, you can write whatever custom checkbox code could you'd like to see in your Bugzilla installation and add random checkboxes with random labels to random pages to hope that someone interprets their labels in the same way. Whatever you prefer. In bugzilla.mozilla.org though, it's done via keywords.

How about proposing one keyword that would apply to all usability, with someone more expert or more committed and who's interested in the report going through the 17 to find the right one? The 17 are virtually hidden from most users now. The one keyword might be new, not necessarily from today's controlled list. Perhaps caseless "ux"?

If we settle on one keyword for most reporters to use, it may as well be a checkbox. We change methods when old ones don't work well enough. The old method is not even on the page for a new bug and a reporter is unlikely to submit a bug and then immediately edit the report to get to the keywords field, especially if they don't know to do that. A checkbox on the original-report page is easier for most people to use and avoids misspellings getting lost in searches and sorts. Even "ux" will get misspelled, like as "u x" or "ui".

It's not just for one installation, but, with Bugzilla as a model, the method or one like it could be in all issue trackers, with installer organizations able to omit whatever they don't want on their site, as they apparently do now. Forking is not necessary.

And please stop saying "random" except when you mean 'random'. You're competent but that makes you look incompetent. I don't doubt that you know what randomness is. Say what you mean.

How about proposing one keyword that would apply to all

See comment 8

That means you're abandoning the effort to fix this and that leaves my proposal as the only one, and it has no competition. Come up with a better idea.

Remember that with the list of 17 the list has to be applied anyway by someone. Doing nothing to fix this excludes the original reporter from using a keyword to signify that the report is about usability. The original reporter doesn't have the keywords field on the form.

Come up with a better idea.

See previous comments: Use keywords.

Where? The original-post form does not have the Keywords field. See comment 7 (and comment 13).

Which keyword? Do you want amateurs to choose from 17? How would the original poster find the list? See comment 7 (and comment 11 and comment 13).

As written in comment 4, the Bugzilla software won't add random additional checkboxes with random unclear labels (such as "usability"). The UI is already convoluted. The webserver bugzilla.mozilla.org (that is not "the Bugzilla software", under which this ticket is filed) has some keywords configured for that. "Amateurs" (?) don't need to set random unclear unhelpful vague keywords such as "usability" that do not help anybody.

Good that we agree not to add anything random to Bugzilla. You seem to have left this thread, so, in the meantime, I'll try to accommodate your reasonable concerns before reopening. Feel free to comment.

I'm looking at the Bugzilla hosted by its publisher, Mozilla, when looking at how to improve Bugzilla for all software organizations wanting bug trackers. Fedora's Software app does not list Bugzilla as an app installable on my Fedora platform, so I don't know if installing it on my machine is viable. If there's an installed raw form I should look at somewhere else, let me know, but presumably Mozilla's installation is the model for most Bugzilla installations generally. Thus, I'm basing this issue on Mozilla's Bugzilla installation.

You didn't answer my point that the field you suggest reporters use is not on the form. It's not on the standard form with or without advanced fields and it's not on the helper form. There's no place to put any of the 17 keywords configured for the purpose so they can be surfaced, sorted, and counted. Adding that field would make declaring usability much more complicated and error-prone and you don't propose adding it, so we seem to agree that adding the Keywords field would be a bad step.

For a better approach, I'm uploading a set of mockups. I address some points about it here.

Some people know so little (I rightly called them amateurs and we welcome their discoveries of problems) that some of them may think nearly everything is a usability issue. I agree; so, to discourage them from overclaiming, this should not be in the helper form and, to see it in the standard form, the reporter should have to click the button that will show advanced fields. Then there are two design choices; the first is easier to use (and even so the term "usability" is only in a tooltip and most users won't see it or know or look up what "UX" means) but the other does even more to discourage overclaiming, such as greater length that discourages reading except by careful posters, and it offers fast access to the support forum with what the reporter has already entered. The reporter wouldn't have to start the support question from scratch, although this method makes it less likely that they'll search for questions already answered.

Because support fora linked to are of many kinds and may have many kinds of login methods (such as logging in through Google), the Bugzilla should allow all of those methods. It may also need a way to get through or around captchas in advance. Perhaps it could offer a generic hook for implementors to use without needing Bugzilla programming for each method.

If the support forum would not be coordinated with the Bugzilla, Bugzilla elements needing the coordination can be dimmed or invisible and disabled. While there's one Bugzilla, support forums have many publishers and designs and coordination cannot be promised.

Support questions would be labeled as auto-generated from the Bugzilla submission. The label would not be embedded in the question text because that could produce a lot of false positives in searches of questions. Instead, the label would be separate from the question text, just as the warning against support scams is separate.

The Bugzilla report suspension process could be a new Bugzilla status set automatically when the issue is put into a support forum, and auto-unset when someone unsuspends the issue.

On the Bugzilla form, whether selecting the "task" button would make the UX options irrelevant is something I don't know. If it would in all cases, then the UX controls could be disappeared for a task.

I'm reopening because the only proposal besides mine is not nearly as elegant. It depends on users using a field that's not there and filling it from a list that's virtually hidden. I posted a bug report with Google about another product and its form asked if it's a "UI" bug. It's not hard to fix this problem here. I've already attached mockups for this proposal.

If the other person was proposing that I fork Bugzilla, that's not necessary or useful for most users of Bugzilla. I wouldn't have the product distribution.

Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: