580550 - BMO: Add a new keyword: "customizability" (similar to "access")

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[Thomas D. (:thomas8)]

STR

- Do bug triage

Actual result

- I have seen a lot of bugs that boil down to the same problem:
Different people have different needs, but our programs apparently sometimes do not offer enough customizability to cater those needs.

- There's no efficient way to tag those bugs as part of a common problem ("customizability"). 

Expected result

- introduce a new keyword in bmo: "customizability"
- which will make it a lot more efficient to label and track respective bugs where customizability is an issue
- while avoiding the overhead, mail spam etc. of having a meta bug
- conceptually, this is very similar to the current keyword "access" which we use to easily tag and filter on accessibility bugs

Additional information:

- There are a lot of bugs where customizability plays a role:

For example:
- anything that looks like a toolbar should act like a toolbar (full customizability: choose buttons, choose icon/text, hide the bar from view menu, etc.); common problem in TB
- keyboard shortcuts should be customizable (which is a single big bug, but there are lots of other bugs that are affected by this)
- preferences to turn on/off certain behaviour (including legacy behaviour)

Comment 1

[Jesse Ruderman]

Customizability is not a goal unto itself.  Bug reports asking for new prefs are not symptoms of a "common problem" that is "lack of customizability".  It doesn't seem to me like it's a useful category of bug reports to track with a keyword, but I'm curious why you want to track them.

From your examples:

> anything that looks like a toolbar should act like a toolbar

The "correct" reason to want this is ux-consistency, and to a lesser extent, ux-implementation-level.  Since it's so visible and so popular a request, it might even rise to the level of ux-control.

> keyboard shortcuts should be customizable (which is a single big bug, but
there are lots of other bugs that are affected by this)

ux-efficiency, access

> preferences to turn on/off certain behaviour (including legacy behaviour)

We have to take these on a case-by-case basis.  This usually means saying "no" to the "add a checkbox" request, but also trying to figure out why the reporter asked for it and doing something appropriate in response.

Comment 2

[timeless]

agreed. we've added plenty of keywords recently, please try to make do with the ux- keywords.

Comment 3

[Thomas D. (:thomas8)]

Jesse, thanks for quick reply with helpful information!

(In reply to comment #1)
> Customizability is not a goal unto itself.

Agreed. I hope I haven't created that impression...

> Bug reports asking for new prefs
> are not symptoms of a "common problem" that is "lack of customizability".

I apologize if my description sounded too much like a general accusation, which it isn't. I'm coming from a Thunderbird perspective, where I think this has been and still is quite topical: E.g., ux-control, ux-consistency and whatever else was pretty much endangered when the new buttons on the message header were first introduced without any way of controlling/customizing that new UI. In the Thunderbird product, I still see various places where such problems exist, hence this bug.

> doesn't seem to me like it's a useful category of bug reports to track with a
> keyword, but I'm curious why you want to track them.

See above. Other recent examples:
- Thunderbird's new mail header buttons cannot be customized in various places (with multiple mails selected etc.; existing bugs)
- Thunderbird has introduced a new Quick Filter Bar which is pretty much non-customizable in many respects (with bugs like bug 570815 and bug 575313 being just the beginning)

> From your examples:
> 
> > anything that looks like a toolbar should act like a toolbar
> 
> The "correct" reason to want this is ux-consistency, and to a lesser extent,
> ux-implementation-level.  Since it's so visible and so popular a request, it
> might even rise to the level of ux-control.

Thanks for pointing out existing keywords, I wasn't aware enough of these.
I agree that with a lot of brainwork, some of my cases could be tagged with a combination of these super-fine-grained ux-keywords.
However, as a volunteer triager I feel having to choose between as many as 17 ux-keywords is a bit over the top. Apparently, looking at the numbers, I am not the only one who is NOT using any of these:

For all 17 ux-keywords, average number of bugs per keyword for all products combined is 4 [sic!], with one single ux-keyword already having the maximum number of 12 matching bugs (ux-efficiency), and all others significantly below that.

Besides, let's be honest: those ux-keywords are not half as clear-cut as they pretend to be. E.g., ux-efficiency will often be a combination of ux-affordance, ux-consistency, ux-control, ux-discovery, ux-feedback and potentially others. I do see the systematical benefit of having these (especially as a reference of UX-principles), but I think for the average bug triaging volunteer these are way too complex to differentiate (and even for developers, apparently).

> > keyboard shortcuts should be customizable (which is a single big bug, but
> there are lots of other bugs that are affected by this)
> 
> ux-efficiency, access

That's not the same as saying there's a customizability issue here...
 
> > preferences to turn on/off certain behaviour (including legacy behaviour)
> We have to take these on a case-by-case basis.  This usually means saying "no"
> to the "add a checkbox" request, but also trying to figure out why the
> reporter asked for it and doing something appropriate in response.

Agreed.

I'm not sure if we have the same idea of the proposed "customizability" keyword. I haven't given this loads of thought yet, but my idea was more like this:

- have customizability as a more general keyword indicating that the bug touches a problem that *might* be solved by providing legitimate/extra/consistent customization options without hurting other ux-principles

Iow, adding "customizability" keyword perhaps doesn't mean straightforwardly that providing customization is the ultimate solution for a bug, but we express that the bug somehow involves a problem that with some likelyhood is a problem of customization options or the lack thereof. Personally, I'd much prefer a certain degree of applicable fuzziness over the non-applicability of 17 ux-keywords that are very hard to tell apart.

Really, this should work in the same general way as "access" keyword, where we don't differentiate either:
- missing menu?
- missing access key?
- missing shortcut?
- just too inefficient via keyboard?
- missing tab stop?
- bad ui design?

Strictly-speaking, many "access" bugs could certainly be subsumed under some combination of the 17 ux-keywords. Yet we all use the "access" keyword efficiently, and everyone immediately understands the meaning(*) without cracking their head about the details (*: "it's a bug that involves accessibility or the lack thereof"). I think the same holds true for "customizability" keyword as a way of just saying "this bug seems/claims to involve customizability or the lack thereof".

Technically, I doubt if "ux-consistency" keyword (or a complex combination of others) actually covers all the cases I have come across. It's not expressing the same thing. ux-consistency presupposes that same/similar UI already exists, which might not always be the case. Yet the new UI might require customization options.

Finally, although I cannot come up with a technically 100% bullet-proof definition of meaning and coverage of proposed "customizability" keyword, all I can say is that I am a heavy bug triager with many years of experience (mainly in Thunderbird product), and I can easily think of a number of bugs where "customizability" keyword would add value to the bug. Again:
> Personally, I'd much prefer a certain degree of applicable fuzziness over the > non-applicability of 17 ux-keywords that are very hard to tell apart.
And I already know of more candidates for "customizability" keyword than the average 4 bugs that have been tagged with ux-something...

Maybe it's good to revise the question: Instead of "Are we 100% sure we want this?, Is there a 100% clear-cut definition?, and: Can we predict 100% of the consequences?", we could also ask: "Would it hurt to have it? Any major damage that cannot be undone?" If not, I'd think that anything with the slightest chance of being helpful for anyone in dealing with bmo as "the devil we know" should be given consideration and just a chance...

Comment 4

[Thomas D. (:thomas8)]

(In reply to comment #2)
> agreed. we've added plenty of keywords recently, please try to make do with the
> ux- keywords.

Please read comment 3 to find out why using ux-keywords doesn't seem to be a good solution for this enhancement request.

timeless, while I appreciate the need for quick decisions to get bugs out of the way (which is what I am helping with on a pretty much daily basis), I'd like to make you aware of the following:

- from a communicative pov, wontfixing a bug on the same day it was posted has a high risk of making the reporter feel bad and not taken serious
- wontfixing a bug before reporter can even reply to first comment that puts the bug into question is definitely bad style, and will make the reporter feel bad and not taken serious
- wontfixing a bug while a qualified response (comment 1) still indicates "curiosity" about the proposed feature feels like a somewhat rude interruption of discussion

Bottom line:
- you can reach the same ultimate result (wontfix) in a better manner that will be perceived less rough and more communicatively sensitive and adequate if you leave the bug open for a while (say 14 days at least) before wontfixing (flag wontfix? in the meantime, but even that flag shouldn't be set on the first day)
- this will also give other interested parties a chance to have their say rather than pushing a bug into oblivion before it has even seen the light of day
- after all, reporter has a reason to file the bug and invested his time to help improve our products

Seriously, wontfix on day 1 of a bug's life feels VERY bad and might easily be detrimental to the good spirits of volunteers :(((

Comment 5

[timeless]

sorry, my triage system works based on bugmail. i've tried using whinemails, but they fail miserably (i get 2 whines a week and my brain pretty much automatically ignores them). i also have a todo list of starred items in gmail, it's >150 items right now, and reviewing that list is incredibly expensive.

the alternative is that bugs languish.

there are two things i'm willing to propose:

1. the keyword completion thing should have a way to show the description for the keywords it's suggesting (someone can file a bug about this).
2. it might make sense to have a ux keyword which means "needs ux triage", however based on the way the keywords work, i'm not quite sure how it'd work. using "ux" alone is likely to result in people using it as a dumping ground.

as is, i think we have too many ux keywords, they were added because i wasn't a strong enough owner to prevent them. i'd like to give them another 3 or so months and then go after the person who created them and force them to be pruned, dropped, converted to a whiteboard, or something.

the keywords were added for faaborg as part of bug 561262:
ux-affordance  	2
ux-consistency 	8
ux-control 	8
ux-discovery 	2
ux-efficiency 	12
ux-error-prevention 	4
ux-error-recovery 	3
ux-feedback 	6
ux-implementation-level 	none
ux-interruption 	2 
ux-jargon  	4
ux-minimalism 	3
ux-mode-error 	3
ux-natural-mapping 	1
ux-tone 	3
ux-undo 	none 

(~60 uses)

I think that I'll add one further note about keywords:
I'd like people who make requests for keywords to provide an estimate of how often a keyword will be used for a given time period and "success criteria".

reed:
i think that your keyword completion widget should be extensible to support the status whiteboard (i.e. automatically recognizing [] annotations and offering to complete based on them).

but yes, i agree, the ux- keywords suffer from ux-jargon and shouldn't have been allowed in (i think they violate ux-minimalism too and they definitely hurt ux-efficiency).

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

>they were added because i wasn't a
>strong enough owner to prevent them. i'd like to give them another 3 or so
>months and then go after the person who created them

I agree that these haven't seen much pickup in usage yet, but if people on bugzilla don't want to focus on usability issues, I don't think that is necessarily a failing of the keywords.  When things settle down with Firefox 4 I'm planning on making a video for each of the UX keywords, showing examples of violations in Firefox and other applications.  Ideally when people understand the usage more, these will see more pickup.

>"success criteria"

Even in the event that these keywords are only used by the UX team (because in the end only the UX team ends up tracking UX issues), I don't think that means the keywords are not useful for improving Firefox and other products being tracked in our instance of bugzilla.