bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Apache Bloodhound] #206: Ticket fields layout broken if custom textarea fields are declared
Date Thu, 04 Oct 2012 16:21:53 GMT
On 10/4/12, Gary Martin <> wrote:
> Perhaps we could continue the discussion started in
> here..
> On 03/10/12 21:10, Apache Bloodhound wrote:
>> #206: Ticket fields layout broken if custom textarea fields are declared
>>   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 ?
> 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.

That's why description box (i.e. .well) has been moved to the top
after applying submitted patches . Indeed placed after the first row
of select | radio fields.

> The two columns of key:values takes up the same amount of room as the
> current 4 column key/value

... well ... technically speaking at the moment it's 4 columns *IF*
Activity feed is shown to the right . Otherwise they would be more
(... 6 afaicr ...)

> but effectively makes better use of the space
> for wide fields.

therefore that's why I asked this question in first place . The design
will be about two columns of ticket fields , or about sizing each one
using span4 . *IF* Activity feed is available it's the same thing ,
otherwise there will be three columns .

So which one are we talking about ?
FWIW I'd rather choose span4

> 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.

I already have , somehow . Proposed patch treats first row of ticket
fields to be more prominent . It's placed on top of description box .

Configurable threshold you mean ? hmmm ... IMO -1 . One row (maybe
two) should be enough .

> 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.

This is implemented already , as I mentioned . I'm not sure about
collapsible section though.
Please take a look at the patches and screenshots . Is that ok ?



Blog ES:
Blog EN:

Featured article:

View raw message