CiviCRM Community Forums (archive)

Stuart -
Medium term plan (3.2 if possible) is to replace all table-driven form layout with div's which will float / adjust width nicely. We'll target this form as one of the first ones. In the meantime, I added a small improvement by setting a fixed width on the Tag <select> (which we already had on the Group <select>). This means the width of that field will be 12em regardless of longest Tag.

{if $form.tag}
            <td class="label">{$form.tag.label} {$form.tag.html|crmReplace:class:medium}</td>
{/if}

This tweak will be part of 3.1.

Hmm - I have it in my 3.1 local install (screenshot attached). Also present on demo:
http://drupal.demo.civicrm.org/civicrm/contact/search&reset=1

Makes a lot of sense to me since there is no shortage of space on that screen

Don't think vertical/horizontal will solve the main issue:

A select when you have a long list is painful, especially if it doesn't respect/represent their hierarchy.

What about an autocomplete field ?

I don't know what to do for the hierarchy, haven't found a nice interface so far to have a something to represent it that either doesn't need a huge space or lots of clicks

X+

firstly - thanks stoob for bringing this up - it's been on my list for a while.

i don't see results being  "above the fold" as a primary concern of this workflow (above the fold is generally a concern if individuals are not already motivated to find information below the fold and for a search result you have a "motivated" user), and therefore don't see any usability problems in moving to a vertical orientation for the form elements.

i think our goals for the long term viability of civicrm should be to really do work and put thought into layout in administrator forms, and would propose that we use a two column format for this specific form: 1) name email and contact type 2) groups and tags, however i think now is probably not the right time in the release cycle to be implementing that kind of change.

that said, i think any updates that bring CiviCRM further in line with the CiviCRM layout+coding guidelines are great at any time (not that i'm biased . it would be great if people could take a look at layout/coding guidelines, specifically section elements (see http://wiki.civicrm.org/confluence/display/CRMDOC/Section+elements ) when contributing template modifications, as we are headed towards a more uniform set of layout widgets, with the goal of allowing/encouraging easy UI modification through CSS alone. (see http://civicrm.org/node/642 )

in this particular case, modifiying the template to use CiviCRM's coding standards has a similar effect to Stoob's code.  I've re-coded the template (as an example for future contributors) and have attached a screenshot of the results.  I should note that making this change allows us to easily make the form move to a two column format at a later date (3.2?).

hope this helps!

kyle

Kudo's to Stoob for highlighting the issue and to Kyle for creating an attractive solution. The search form is an annoyance 'no longer' - pun intended.

FWIW - a 2 column format might be the ultimate solution.