In [[ changelog/2018.15 ]], I shipped a new `[+++- ]` element to provide a quick visual indicator of revision sizes. The original request for this was PHI230. I dragged my heels for a long time on this and made various claims like these:
On the value of the feature:
> (PHI230) I'm also not sure this really serves any use case except "make it easier to ignore large revisions I don't want to review".
> (D16322) As far as I can recall, everyone who has ever wanted improvements here has been trying to find ways to ignore diffs they don't want to review.
> (T376) I think the root problem here is that people are worried that other people are ignoring their diffs because of a large linecount, possibly because they themselves ignore diffs with a large linecount. I think this is basically a social problem. Line count should be a curio, not something people actually pay real attention to or make decisions based on. If anything, we should simply remove it.
On the behavior:
> (PHI230) Also if anyone complains that the line counts are off because moved lines should/should not be counted and/or blank lines should/should not count/should only count on a log scale I am deleting the feature forever.
> (T376) There are too many types of changes (like generated files, copies, deletes, indentation changes) which make the line count larger than it "should" be. Many of these don't have clear-cut "right" ways to count line changes (people will continue to complain that certain types of changes were or weren't counted), and some are technically difficult or prohibitively expensive to count.
This has now shipped, and we've collected some feedback:
- (PHI569) The element was generally "very well received".
- (PHI579) The element was generally received with "meh".
- (PHI587) The colors are too bright and the element stands out too much.
- (PHI569) The element is too hard to see and does not stand out enough, particularly for colorblind users.
- (PHI579) Red and green are good color choices.
- (PHI587) Red and green are poor color choices, and should be shades of blue.
- (PHI579) Grey is a poor color choice, and should be orange.
- (PHI579) The meaning of the element is completely unclear.
- (Z2413) The element is confusing, but you can understand what it means if you hover over it.
- (Z2413) The element is fairly clear and the rules driving it make reasonable sense.
- (PHI230) Generated lines should be excluded from line counts.
Broadly, all incarnations of this feature have invited an enormous amount of bikeshedding for the last decade. I think this feature is second only to button text (T10000) as a magnet for bikeshedding.
I think part of the core problem with this feature is that it isn't really solving a very concrete or well-defined problem and the information is barely of any importance, so all decisions about it are mostly aesthetic decisions.
The feedback is so wide-ranging and contradictory that no version of this element will satisfy everyone, so I currently plan to continue changing it at random as the mood strikes me.
At least as of time of writing, a piece of feedback I haven't received is "this should just be a number, the visual element is worse than a number", so I consider this change a resounding success overall. (But I currently have one unread followup on one of the support issues which probably says "maybe this should just be a number".)
These are //likely// future changes:
- With "Red/Green" colorblind mode enabled, it is extremely likely that the element will stop using red/green colors in the future.
- The use of red/grey/green in default color mode may also change.
- The tooltip may get a subjective hint about the color, e.g. "Smaller Change" or "Larger Change".
- I generally think that the element stands out too much relative to the importance of the information it conveys today. It is likely that future versions of the element will be less prominent than the version that exists today. I may decrease prominence mostly by changing the colors.
- It is not currently trivial to exclude generated changes from line counts. If this becomes easy in the future (PHI64, T784 are possible avenues) it is likely that future versions of this element will not count generated lines.
- It is not currently trivial to exclude moved lines from line counts. If this becomes easy in the future, it is likely that future versions of this element will not count generated lines.
- (In both cases, I feel emboldened to try to make this element reflect "review difficulty" rather than "exact change size" because the move away from actual line numbers to a visual representation seems to have been successful.)
- The current line counts in the table of contents may become more visual, to echo this element.