Loading...
 

Bootstrap Transition - Forms

Process

There are many forms in Tiki's Smarty template files, and generally these need to be modernized and made Bootstrap-compatible (and therefore responsive - more usable in all device sizes).

Although the construction of some admin pages, etc. was updated, the templates directory still (as of Dec. 8, 2013) contains 218 usages of table class="formcolor", which as a rule has been used for form layout in Tiki. So the task continues.

For example, code like:

<form>
<table class="formcolor" width="100%">
	<tr>
		<td><label for="anonymous_name">Name</label></td>
		<td><input type="text" maxlength="50" size="30" 
id="anonymous_name" name="anonymous_name"  value="{$comment_preview_data.name|escape}"></td>
	</tr>
</table>
</form>


Needs to be changed to something like:

<form class="form-horizontal" role="form">
  <div class="form-group">
    <label for="anonymous_name" class="col-sm-2 control-label">Name</label>
    <div class="col-sm-10">
      <input type="text" maxlength="50" class="form-control" 
id="anonymous_name" name="anonymous_name"  value="{$comment_preview_data.name|escape}">
    </div>
  </div>
</form>


Class="form-horizontal" uses Bootstrap's predefined grid classes to align labels and groups of form controls in a horizontal layout. Class="form-group" groups a label and input and gives them some bottom white space. Class="control-label" gives the label some spacing and aligns the text to the right. Class="form-control" adds styling to the input and makes its width 100%. The width can be controlled by wrapping the div in one of the grid-class divs, if needed.

General points

Breakpoint display size

Bootstrap in its form examples uses "sm" grid div types for forms ("col-sm-3", etc.) and this seems to work well, so should probably be the default for Tiki's forms.

Element examples

Select

<div class="form-group">
     <label class="col-sm-2 control-label" for="mess-prio">Priority:</label>
     <div class="col-sm-10">
          <select name="priority" id="mess-prio" class="form-control">
     </div>
</div>

Textarea

<div class="form-group">
     <label class="col-sm-2 control-label" for="broadcast-body">Body:</label>
     <div class="col-sm-10">
          <textarea class="form-control" rows="20" name="broadcast-body" id="broadcast-body" />
    </div>
</div>

Form construction style guide

Before the guide can progress very far, first there are ...

Decisions to make

Currently (August 2015), there are basically two trends of "Bootstrapified" form layout in Tiki. In the Admin - Include pages (tiki-admin.php?page=general, etc.) most forms have labels left-aligned, and use a 4/8 grid column layout. In pages in the default menu (such as tiki-admin_calendars.php), forms mostly have labels right-aligned and use a 3/9 layout.

There are a few forms that align labels above fields, like tiki-user_preferences.php, for no particular reason. In other cases, the top alignment is used to maximize input field width like the wiki edit page (edit textarea tab).

Horizontal form label alignment: left or right?

Many of Tiki's converted forms that are "form-horizontal" type according to Bootstrap docs don't have that class. The wiki edit page and some other content-creating/editing pages have class form-horizontal, but most tiki-admin.php?page=x forms don't. The visual difference is that with form-horizontal, field labels are aligned right, to be close to the field. This is considered best practice for UI. Without form-horizontal, the labels are aligned left, which makes for a visually nice even left margin, but worsens UI since the user has to try harder to match each label and its field.

Another problem so far: inconsistent use of col sizing for label and content

The problem is that some forms (as in the examples below) use col-sm-2 for the label, others use col-sm-3 and there are examples for col-sm-4. Also some forms use col-md-.., some use col-sm-... breakpoints. We should pick one and stick with that.
col-sm-2 seems to be short for translations, col-sm-3 is mostly enough, col-sm-4 makes too much whitespace imho. Also we could shorten the labels and put the loooooong text as help-block under the the content

Label position above field or to its left?

Question as of 2014-01-25: two directions emerged in the recent bootstrap transition for styling of input fields, can we/should we pick one in order to have a standardized layout?

Option 1: label is above the input field

Sample:
Edit Article Sample

Pro: label length does not matter, also translations can be as long as desired without line breaks

sample for long label:
Edit Article Sample Longlabel

Contra: form becomes longer vertically as each label is a new row

Option 2: label is before the input field

Sample:
Edit Blog Sample

Pro: form is shorter vertically

Contra: if the label text or the translation is long, than the input filed has less space, also layout becomes messy as the label text/description get linebreaks to fit into the allowed space, so the form becomes long again..

Tiki Trunk NewTest 2014 01 28 15 23 15 (Vertical Labels)

Opinions

gezza: i am for option1.

update: Tiki has many options for each feature and I agree it makes the editing layout too long and scattered. Having labels on the left is ok for "small" inputs, eg language selection, but for larger text areas (eg: body of a blog post or an article) having the label above is nicer as it leaves more space for the content.
I think the key is the content, the focus should always be on the content.

Maybe an approach could be to have a different layout for content, eg: have Content tab where labels are above and all other tabs that are for settings the labels are on the left.

Or is it too complicated and hard to follow?

Voting might be useful to achieve a general understanding

luci: +1 for option1, also for removing the need to use "for" attribute and id="" on these labels+inputs (prevent breakage of things when you get accidentally two forms with same IDs on one page), something like this (notice how the label contains the form input element; would be possible ?):

<div class="form-group">
     <label class="col-sm-12 control-label"><span>Priority:</span>
          <select name="priority" class="form-control">
     </label>
</div>


Gary: luci, I like the simpler way you describe, of wrapping the input or select with the label tags, but it doesn't seem to be supported very well in Bootstrap (see http://getbootstrap.com/css/#forms). I get not-so-good results when I try that.

About the choice of label position - above the input or on the left side, I followed the legacy layout pretty much, as shown on tiki-admin pages. This also seems to be the most common on the web (anyway, according to http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php). I kind of prefer to have the labels on the left, as the page content seems more clear to me, but this is probably a matter of opinion. I didn't check about label length problems in translated strings. I (ignorantly) used the English string lengths to decide about the grid size. This could be adjusted if there is a frequent problem with too much text wrapping. Here are two versions of tiki-editpage.tpl's Properties tab content (not optimized, but just for a quick comparison):

Tiki Trunk NewTest 2014 01 28 15 23 15 (Vertical Labels)
Tiki Trunk NewTest 2014 01 28 15 27 44 (Labels On Left)

Do we need to have a "vote" or something to decide label position?

Label Positioning References

  • Top, Right or Left Aligned Form Labels

http://www.lukew.com/ff/entry.asp?504
"Top-aligned labels tend to reduce completion times (how long it takes to complete a form) the most for familiar data (i.e. address, credit card, etc.) because they only require a single eye fixation to take in both input label & field. Top-aligned labels also work well for forms that require localization or long labels as there is plenty of horizontal real estate to expand/contract the label without negatively impacting the overall page layout. Top-aligned labels, however, do take up a lot of vertical real estate.

Right-aligned are a bit slower to complete but require less vertical screen space. They do, however, have flexibility issues when the labels change widths. When localizing applications, it is important to note that languages like German or French can be twice as long as English. Right-aligned labels also don't work well when people need to scan a set of labels to see what is required as a left rag text impedes readability.

Left-aligned forms are the slowest of the three to complete because of the number of eye fixations they require to parse. However, for forms with lots of optional fields or unfamiliar data (like preferences dialogs or advanced settings), they allow users to effectively scan labels. In fact, if you want users to slow down and consider each input in a form more carefully, left-aligned labels are a good way to go."

  • Eye Tracking and Usability Testing in Form Layout Evaluation

http://c.ymcdn.com/sites/www.bfma.org/resource/resmgr/Articles/08_32.pdf
"Observable performance in the form of completion time and accuracy was not affected by the form
layout. However, eye movement and user satisfaction measures pointed to forms 1 and 2 as the most satisfying to the users and least demanding in terms of cognitive processing, and to form 3 as the most efficient in terms of visual scanning. [1. Left-aligned labels to the left of left-aligned input fields (“left alignment”) 2. Right-aligned labels to the left of left-aligned input fields (“right alignment”) 3. Left-aligned labels above left-aligned input fields (“top alignment”)].

  • Formulate Information Design - Alignment

http://www.formulate.com.au/blog/alignment/
"When the question text is placed to the left of the answer field, the (perhaps counter-intuitive) recommendation is to have that text be flush right. The aforementioned research by Matteo Penzo has shown that flush right performs markedly better than flush left. It seems that the advantage of having the text close to the answer field outweighs the disadvantage of the ragged left edge (although for people with dyslexia, this may unfortunately not be the case, which is why the ideal approach is placing the label above the field)."

  • Labels and Buttons on Forms

http://www.slideshare.net/cjforms/labels-and-buttons-on-forms?next_slideshow=1#14387542487431&fbinitialized
"Decide where to put your labels according to your users, their goals, and the questions

Your users and their goals .... Your questions ... Put the labels ...
Willing to reveal the answers;
filling in the form helps them to achieve a goal
Simple, only a few of them Above
Simple but lots of them Right-justified
Complex Left-justified
Unwilling to reveal answers or reluctant to fill in the form Simple or complex Left-justified (you’ll need more explanation)"
  • Forms that work: Designing web forms for usability

http://www.formsthatwork.com/Appearance
"Users don't care very much about the placement of labels....What users DO care about is whether the questions are easy to answer, whether they want to reveal that information on your form, and whether the validations prevent them from entering the answers of their choice.

"So our advice is:

Arrange the labels in any way that looks harmonious to you.
Make sure that each label is close to the field it belongs to.
Then test your form with your users and change it according to whatever they tell you."

Also, related:

  • Placeholders in Form Fields Are Harmful

http://www.nngroup.com/articles/form-design-placeholders/
"Summary: Placeholder text within a form field makes it difficult for people to remember what information belongs in a field, and to check for and fix errors. It also poses additional burdens for users with visual and cognitive impairments." The author says the placeholder can supplement but shouldn't replace either the label or help text.


Page last modified on Wednesday 05 of August, 2015 09:40:47 GMT

Switch Theme

Layout

Subscribe to Tiki Newsletters!

Delivered fresh to your email inbox!
Newsletter subscribe icon
Don't miss major announcements and other big news!
Contribute to Tiki

Site Config