Perhaps we could continue the discussion started in https://issues.apache.org/bloodhound/ticket/206 here.. On 03/10/12 21:10, 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 olemis): > > Replying to [comment:7 jdreimann]: > > Ok, in brief I think we should move back to something closer to > [http://trac.edgewall.org/demo-0.12/ticket/3000 Trac's layout] for these > fields. > > Two columns of **Key: Value** pairs. > > > > I think full row is necessary for textarea fields . If using two columns > layout width will vary depending on whether Activity feed is available or > not . Is that the idea ? > > > I came to that conclusion by the problems described in this ticket, but > also thinking about how a [https://issues.apache.org/bloodhound/ticket/217 > responsive layout] may work in the future. > > > > Current solution makes field UI more concise which is good for responsive > designs , isn't it ? > > [...] > The full width idea may well make sense for custom textareas. My only worry would be that it could give a similar prominence for those to the description which might be confusing. The two columns of key:values takes up the same amount of room as the current 4 column key/value but effectively makes better use of the space for wide fields. Most of the fields already displayed have the opportunity to have long strings if the users are not careful. One thing I was wondering about was whether we could set a limit on the number of fields that are considered to be important so that the some fields can be treated differently. We might, for example, want to say that above a given threshold number of fields, the less important fields are either separated from the others by the description or further relegated to an expandable section. Cheers, Gary