Mailing-List: contact bloodhound-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Apache Bloodhound" <bloodhound-dev@incubator.apache.org>
Cc: bloodhound-commits@incubator.apache.org
Auto-Submitted: auto-generated
Date: Mon, 09 Jul 2012 16:07:54 -0000
Reply-To: bloodhound-dev@incubator.apache.org
Subject: Re: [Apache Bloodhound] #67: Highlight tickets outputted by reports
Message-ID: <070.ac24727c74018754ae53a478837a4b7f@incubator.apache.org>
References: <055.933d3ded661f0e29c3dc13ef5d5ee6a6@incubator.apache.org>
In-Reply-To: <055.933d3ded661f0e29c3dc13ef5d5ee6a6@incubator.apache.org>

#67: Highlight tickets outputted by reports
--------------------------+----------------------------------
  Reporter:  olemis       |      Owner:  olemis
      Type:  enhancement  |     Status:  accepted
  Priority:  major        |  Milestone:  Release 2
 Component:  ui design    |    Version:
Resolution:               |   Keywords:  reports highlighting
--------------------------+----------------------------------

Comment (by olemis):

 Replying to [comment:8 gjm]:
 > Replying to [comment:7 jdreimann]:
 > > Replying to [comment:3 gjm]:
 > > > It looks like the colours may have been dropped on purpose - that
 would mean that we need to decide whether we have an appropriate means of
 distinguishing the most important tickets while they are not in priority
 order.
 > >
 > > I believe we should look for a better indicator than colour -
 especially as the number of distinct colours needed grows it becomes
 difficult to differentiate between them and remember the meaning.

 There are only six colors , i.e. those defined for
 [http://twitter.github.com/bootstrap/components.html#labels bootstrap
 labels] :

 || '''Value''' || '''Label classes''' ||
 || 1 || `label`, `label-important` ||
 || 2 || `label`, `label-warning` ||
 || 3 || `label`, `label-success` ||
 || 4 || `label`, `label-info` ||
 || 5 || `label`, `label-inverse` ||
 || 6 and higher || `label` ||

 > > Let's not forget the significant share of population with colour
 blindness too. There's also a risk of highlighting very prominently
 something which may not be the focus of the user at all at that moment.
 >
 > Colour blindness is clearly a very good argument against colours.

 jftr , I guess this will be the same problems to differentiate between
 warning, info, success messages and buttons , etc ...

 > However, I suspect that the alignment solution may well have a greater
 risk of drawing focus than the whole row colours provided by Trac, though
 it is certainly a lot less attention grabbing than the bold colour blocks.
 >

 Maybe we can combine both methods . I mean it's possible to insert labels
 using different padding according to target value used to sort the result
 set .

 > An interesting aspect of the suggestion from Olemis is that there appear
 to be up to six levels available.

 yes , like I mentioned above ''';)'''

 > I wonder how far people will want to distinguish the absolute priority
 of a ticket with the priority attribute though.
 >

 in current implementation , there's no difference . Beyond those six
 values all tickets are rendered using light gray labels .

 > What if we go back to a whole row background but stay with a single hue
 and adjust the value? These kinds of scales are already a bit non-linear
 but we might also want to emphasise that with the value calculation as we
 could consider the distinction between the highest priorities as more
 important than between the lowest priorities.
 >

 IMO there is also the fact that Trac default highlighting uses two
 different background colors for each level i.e. even and odd rows
 respectively . That looks a bit annoying to me . Using labels the level is
 always highlighted the same way and this is orthogonal to the decision of
 having different background colors for even and odd rows (e.g.
 [http://twitter.github.com/bootstrap/base-css.html#tables bootstrap table-
 striped class] ) .

 > > My suggestion is using alignment of the text in the priority column -
 high priority aligned to the left, lower levels to the right.
 >
 > The implication from the design was that it would only be the highest
 level (or the highest visible level) that would be promoted to left
 alignment if I remember correctly.

 /me recalls the same

 > We should of course consider whether we need to mark out anything but
 the most important work items in this way.

 Well , considering default priority values , this will only work for
 `blocker` value . Question is ... why not to highlight critical tickets as
 well ?

 > I think that there is a case for more granularity for users who are not
 not able to work on highest priority tickets, although it could be
 mitigated by more appropriate sorting.
 >
 > > We may also want to consider using priority as a secondary sorting
 method by default when it is not the primary one.
 >
 > Yes, that sounds like a very good plan.

 -1 for enforcing this rule in the code . IMO if that's the case then
 ''SQL'' report definition should be updated . Ticket queries consider
 nothing but priority for highlighting rows .

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/67#comment:9>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker