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 14:13:31 -0000
Reply-To: bloodhound-dev@incubator.apache.org
Subject: Re: [Apache Bloodhound] #67: Highlight tickets outputted by reports
Message-ID: <070.851a84dab54d54dfa00aa9722958f11e@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 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. 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. 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.

 An interesting aspect of the suggestion from Olemis is that there appear
 to be up to six levels available. I wonder how far people will want to
 distinguish the absolute priority of a ticket with the priority attribute
 though.

 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.

 > 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. We should of course consider whether we
 need to mark out anything but the most important work items in this way. 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.

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