#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
