You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary Martin <ga...@wandisco.com> on 2012/10/04 12:55:50 UTC
Re: [Apache Bloodhound] #206: Ticket fields layout broken if custom
textarea fields are declared
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
Re: [Apache Bloodhound] #206: Ticket fields layout broken if custom
textarea fields are declared
Posted by Olemis Lang <ol...@gmail.com>.
On 10/4/12, Joachim Dreimann <jo...@wandisco.com> wrote:
> 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.
>
I'll need to try these to see what happens in practice .
> Hiding fields after a certain number will make sense on mobile devices
> especially, but I think that shouldn't influence our decision here yet.
>
agree
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #206: Ticket fields layout broken if custom textarea fields are declared
Posted by Joachim Dreimann <jo...@wandisco.com>.
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 <ga...@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
Re: [Apache Bloodhound] #206: Ticket fields layout broken if custom
textarea fields are declared
Posted by Olemis Lang <ol...@gmail.com>.
On 10/4/12, Gary Martin <ga...@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
>>
[...]
>> 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.
>
+1
> 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 ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article: