incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject Re: [Apache Bloodhound] #206: Ticket fields layout broken if custom textarea fields are declared
Date Mon, 08 Oct 2012 18:01:47 GMT
#206: Ticket fields layout broken if custom textarea fields are declared
------------------------+-----------------------------------
  Reporter:  olemis     |      Owner:  olemis
      Type:  defect     |     Status:  accepted
  Priority:  blocker    |  Milestone:  Release 2
 Component:  ui design  |    Version:
Resolution:             |   Keywords:  ticket field textarea
------------------------+-----------------------------------

Comment (by olemis):

 Replying to [comment:10 jdreimann]:
 > Replying to [comment:9 olemis]:
 > > The only change I suggest is to move description box to the top .
 Candidate locations are
 > >
 [...]
 > >   1. Beneath all enum ticket fields but on top of text and textarea
 fields (e.g. between ''bool field'' and ''cc'' in attached screenshot).
 > >
 >
 > I wouldn't move it at this point.
 >
 [...]
 > In general the ticket fields are there to give a quick overview of the
 state of the ticket, without having to dive too far into it - therefore
 the description should come after them by default.
 >

 Ok . That's a good point , but I think you are talking of '''enum'''
 ticket fields . So first two options are out of this discussion .

 Nonetheless , what about the third one ? It seems to me that description
 field is more relevant than any possible text or textarea custom ticket
 field a ticket might ever have . Those are not in there «to give a quick
 overview of the state of the ticket» but to document some aspects related
 to the ticket (e.g. ''Release notes'' and ''API changes'' defined in t.e.o
 issue tracker) . Hence it's a reasonable decision to place description
 `div.well` above those fields .

 > To combat the issue of the description field almost disappearing off
 screen (shown in your screenshot), I believe we should reduce the
 top/bottom margins between the rows.

 ok

 > We should also try and make the gap between the `keys` and `values`
 smaller, to make it easier to read. Potentially we could wrap items that
 are too long into a second line?
 >

 I explored three options offered by ''Bootstrap'' library .

   1. align key values by combining `form-horizontal` , `control-label` ,
 and `controls` CSS classes . It turns out there's no enough space for
 field value
   1. Use `span1` for field label and `span3` for the value . As a result
 text in most labels wrapped to the next line , and long words overflowed
 available width (<= big problem for e.g. German language)
   1. Use `span2` for field label and `span2` for the value . This is what
 can be seen in [attachment:bh_theme_x_74_ticket_fields_two_cols.png the
 picture] .

 After applying `pull-right` class to field label it looks like this .

 [[Image(bh_theme_x_75_ticket_fields_two_cols_v2.png, width=600)]]

 Proximity highlights group field / value groups and similarity delimits
 enum fields zone and text / textarea fields area . Is this ok ? Otherwise
 , what else should I try ?

 > It's also much less of a problem in the default layout without many
 custom fields.

 Yes , you are right . Nevertheless we should be designing for a broader
 audience considering the fact that we should not force users to do
 something (e.g. define a small subset of custom fields) ... unless there's
 a good reason to do so .

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

Mime
View raw message