On 09/10/12 11:49, Apache Bloodhound wrote:
#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 jdreimann):

  Replying to [comment:11 olemis]:
  > Replying to [comment:10 jdreimann]:
  > [...] 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 .

  I see your point. I wouldn't mind if you set that as the default, we can
  change it based on actual user feedback later if desired.

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

  I think that's enough of an improvement to go with it for now. Ultimately
  I believe we'd want the `Keys` to be left-aligned to make them more easily
  scannable, but currently the potentially huge gap this leaves between
  `Keys` and `Values` reduces overall readability in my view.


It looks like the conversation continued on the ticket for a bit.

The upshot appears to be that the suggested patches will put the description closer to the top of the ticket, separating out the custom fields.

In addition I think we will end up with a two column layout.

I will need to test those assertions as I am not sure that is precisely what the associated screenshot in the ticket suggests: https://issues.apache.org/bloodhound/attachment/ticket/174/bh_theme_x_77_ticket_scrollspy_v3.png (note that the scrollspy button bar above the fields is a result of a different ticket which I hope to review shortly).

I will attempt to assess the patches themselves but all thoughts are welcome.

Cheers,
    Gary

Reply via email to