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 <[email protected]> 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
