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
