1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
---
title: Configure Input Fields To Guide Data Entry
order: 83
layout: page
---
[[configure-input-fields-to-guide-data-entry]]
= Configure input fields to guide data entry
[[field-size]]
Field size
^^^^^^^^^^
There are a number of tricks we can use to help users understand what
kind of values we expect them to enter into a field, without resorting
to tooltips, footnotes or excessively long captions. Consider the form
below:
image:img/form1.png[Basic form]
The shape, size and layout of these fields don’t really correspond to
the kinds of values expected to be entered in them, or to the relations
between different fields. For instance, while the homepage url is
probably between 25 and 55 characters long, European postal codes are
only about 6 digits long, and age maxes out at three digits. By setting
the widths of these fields to be approximately proportional to the
lengths of expected values, the fields become easier to identify, and
the entire form feels more friendly and less monotonous:
image:img/form2.png[Form with different input widths]
Please note that there is no point in trying to _match_ the _exact_
lengths of expected values – the positive effect here relies more on the
sizes of fields _relative to each other_ than on specific widths. Also
note that it’s important not to make the shortest fields too short just
to distinguish them from longer ones. An address field that can only
display 10 characters at a time would be really annoying.
An easy way to set field widths to approximately a certain number of
characters is to set the component’s widths using
http://en.wikipedia.org/wiki/Em_(typography)[Em units], found in
Vaadin’s *Sizeable.Unit* enum. One *Em* is approximately the width of
(actually usually slightly wider than) an uppercase M.
[source,java]
....
TextField tfPostalCode = new TextField("Postal code");
tfPostalCode.setWidth(6, Unit.EM);
....
This was all about the _width_ of input fields, since most input fields
are single-line. Fields for which you expect more than a few words of
text should of course be multi-line *TextAreas*. While the height of a
*TextArea* might not be as important as the width of a *TextField*
(since it has scrollbars), it’s still a good idea to set both the width
and the height of a *TextArea* to roughly match the amount of text you
expect people to enter. A bigger *TextArea* encourages the user to enter
more text into it, while a smaller area suggests that perhaps a few
carefully chosen words is enough, thank you very much.
[[component-grouping]]
Component grouping
^^^^^^^^^^^^^^^^^^
Some of the fields in the above example clearly “belong together”. First
and last name. Street address, postal code, city and country. By
changing the layout slightly, moving the most closely related fields to
the same line and adding a little spacing between groups of related
fields the fields become even easier to identify, and the form easier to
understand in a single glance:
image:img/form3.png[Form with grouped inputs]
(See layout component sections in Tutorial and Book of Vaadin to see how
this is done in Vaadin.)
[[input-prompts]]
Input prompts
^^^^^^^^^^^^^
An input prompt is a placeholder text inside an input field that
disappears as soon as a value is entered into the field. Many input
components in Vaadin have a *setInputPrompt()* method for this:
[source,java]
....
TextField tfSearch = new TextField();
tfSearch.setInputPrompt(“Search by keywords”);
....
One use for input prompts is as an alternative to a separate *caption*.
This can be useful especially if there is very little space for the
field, or if you wish to reduce the visual clutter of your UI. A common
example is a search or text-filter field with an input prompt like
_“Search by keywords”_ or _“Filter by name”_ :
image:img/searchfield.png[Search field with prompt]
The decision to use input prompts as captions should not be taken
lightly, however. Keep in mind that the input prompt disappears as soon
as any text is entered into the field, so the user will have to remember
what the field was for, or be able to deduce its identity from its
current value. In the example above, with just a single search field, or
even in a login form with username and password fields, this is
acceptable. In a significantly longer form, however, especially one that
the user might wish to read through before submitting to check that
everything has been correctly entered, this approach quickly turns into
a problem.
Another way to use input prompts is for displaying *additional
information* about the field, such as the expected *format*, or the
*types of values that are accepted*. This is quite similar to
*tooltips*, with the difference that the input prompt must be kept short
enough to fit into the field itself, and that it is immediately visible,
without hovering over the field with the mouse pointer. For this reason,
input prompts are useful on touch screens, as opposed to tooltips.
A good example of indicating the types of values a fields accepts is a
_Location_ field where you can enter a street address, a postal code or
just the name of the city. These details are probably too long to fit in
the field’s caption, and might not be discoverable enough in a tooltip.
An input prompt briefly explaining the options is an excellent solution:
image:img/locationfield.png[Input field with prompt]
|
