incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject Re: [Apache Bloodhound] #206: Ticket fields layout broken if custom textarea fields are declared
Date Thu, 04 Oct 2012 15:13:25 GMT
About long strings: that's exactly where the current layout falls down. Trac's layout makes
that a smaller issue. That style also works better with a responsive layout because less of
a change is required when we're using Bootstrap's span* classes to set the column widths.
They'll show up one below the other, instead of next to each other, on mobile phone screens
for example.

Hiding fields after a certain number will make sense on mobile devices especially, but I think
that shouldn't influence our decision here yet.

Cheers,
Joe

On 4 Oct 2012, at 11:55, Gary Martin <gary.martin@wandisco.com> wrote:

> 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