incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [Apache Bloodhound] #206: Ticket fields layout broken if custom textarea fields are declared
Date Thu, 04 Oct 2012 10:55:50 GMT
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

Mime
View raw message