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
|
[[choosing-input-field-components-wisely]]
Choosing input field components wisely
--------------------------------------
The core Vaadin framework has more than ten different input field
components. Choosing the right one can improve your application’s
usability significantly. Which component is the best fit in a certain
situation depends on so many factors that it’s pretty much impossible to
set down any specific rules. Nevertheless, here are some helpful
pointers that might guide you in the right direction.
[[textfield-or-selection-component]]
Textfield or selection component?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
**TextField**s are of course the most obvious choice in most cases.
However, their inherent lack of restrictions requires that the user
understands what kind of values are acceptable. They don't present any
options to choose from, and, although you can restrict them to certain
kinds of values e.g. by using **Converter**s, these restrictions are not
immediately obvious to the user. Furthermore, if the UI in question is
mostly mouse-operated, a *TextField* forces the user to move her hands
to the keyboard to enter a value. Thus, a selection component can in
many cases be more convenient for your users.
[[optiongroup-and-checkbox]]
OptionGroup and Checkbox
^^^^^^^^^^^^^^^^^^^^^^^^
**OptionGroup**s are handy for very small sets of options (typically
2-4). You can toggle between single-select (radiobuttons) and
multi-select (checkboxes) with the *setMultiSelect(boolean)* method.
Using an OptionGroups to present purely numerical options might be
somewhat strange, though.
image:img/optiongroup.png[OptionGroup]
For binary either/or, yes/no options, a *CheckBox* is a natural choice.
However, if the meaning of the "no" option (i.e. unchecked) is not
completely obvious, or the "yes" (i.e. checked) option could be
confusing by itself, a two-item single-select *OptionGroup* might be
better, since it clearly states what both options represent.
image:img/checkbox-vs-og.png[Checkbox vs OptionGroup]
[[nativeselect]]
NativeSelect
^^^^^^^^^^^^
The often-overlooked *NativeSelect* component is also convenient for
small sets of options (up to 10 or so), and works great both for named
items and small sets of numbers.
image:img/nativeselect.png[NativeSelect]
[[combobox]]
ComboBox
^^^^^^^^
If the set of options is larger than about 10 items, a *ComboBox* might
be a better choice, since it allows the user to search for a specific
value to typing part of it, and supports lazy loading.
image:img/combo.png[ComboBox]
[[slider]]
Slider
^^^^^^
The *Slider* is great for _quickly_ selecting a value from a wide range
of values, _if precision is not that important_, such as audio volume,
brightness, or any approximate value. (If precision is important it's
much better to allow the user to manually enter the value, such as with
a *TextField*.)
image:img/slider.png[Slider]
[[datefields]]
DateFields
^^^^^^^^^^
The *PopupDateField* component, which opens a calendar popup for date
selection, is great for entering dates and times. Remember to set the
datefield's _resolution_ to something appropriate: seconds are hardly
relevant in most cases, and sometimes all you need is the date.
image:img/datefield.png[DateField]
There’s also the *InlineDateField*, which is really just the
*PopupDateField*’s datepicker without a textfield. It’s probably a bit
too big to use in most forms, but if picking dates is one of the few
tasks in a form, give it a try if you have the space.
|
