launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2010/1/13 Graham Binns <graham@xxxxxxxxxxxxx>:
> 2010/1/13 Gavin Panella <gavin.panella@xxxxxxxxxxxxx>:
>> On Mon, 11 Jan 2010 11:46:49 -0600
>> Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx> wrote:
>> ...
>>> > This is one way of showing it, yes. We need to figure out how it looks
>>> > on the listing, and if it's clear enough. The question on how to
>>> > distinguish a bug with 1000 heat and another one with 10 is still on
>>> > the table, no?
>>> >
>>>
>>> I assumed there would be X different icons/indicators representing
>>> varying degrees of hotness.  So as a simple example, let's say there
>>> are 3 icons (I think in practice 5-7 is more appropriate) --
>>> low_heat_icon.png, med_heat_icon.png, and high_heat_icon.png.  The
>>> total group of hot bugs would be split into these categories based on
>>> the heat numbers for that project.  A heat of 500 might be low for an
>>> active project with 1000 bugs having some heat value but high in a
>>> project with only 20 bugs with a heat value.
>>
>> I think the display used by Spotify, amongst others, to display song
>> popularity is quite good. I've attached a (tiny) screenshot. A log
>> scale would stop any sun-hot bugs from dominating. It could be coloured
>> too, redder to the right perhaps, as an additional cue.
>
> My vote is for simpler-is-better - i.e. 3 icons representing low,
> medium and high bug heat. At least for the first iteration of this
> feature (incremental improvement and all that).

I very much agree. Not just because it's simpler for us, but because I
think it will be simpler for the users. For the same reason I think
that we should resist displaying any concrete number, as was suggested
earlier. My concern is that the more we expose the machinery behind
hotness (in the UI) the more users will fixate on it, trying to
manipulate their pet bugs to get a higher rank, complaining when they
don't and using the number as a voodoo device when they make decisions
about bug. The information about hotness is only useful in relative
terms, and will change over time, so I think that sorting + putting
bugs in one of three bins (or should i say binns) will give users all
the information they need, without distracting from the core
information - the bug itself.