![](bg4.png)
particular with respect to the choice and design of
the widgets to manipulate shader parameters, ways to
communicate couplings of parameters, and the com-
putation of parameters of GPU-based shaders from
user-specified parameters.
4.1 Color Selection
One or more colors are usually among the visual dis-
tinct features of a surface shader. Appropriate col-
ors should potentially (i.e. under very specific circum-
stances) appear in a rendered image exactly as speci-
fied by the user. This is implied by Principle 1, which
requires parameters that control visual features: a
color that cannot appear in a rendered image would
not be a visual feature. Moreover, this requirement
tends to make it possible to pick specific colors in
photos or artwork.
Principle 1 encourages the use of standard widgets
in order to guarantee an intuitive behavior of widgets.
Thus, the standard color selector is usually the best
way to specify colors. This includes opacities of fea-
tures if their specification is supported by the standard
color selector; otherwise a slider should be used as
discussed below.
If a default value of a color is available, it should
not only be used as initial value for the color selector
but it should always be represented graphically in the
widget as suggested by Principle 4. Alternatively, a
button might be added that allows the user to select
the default color.
4.2 Sliders
Sliders are often the best widget to interactively spec-
ify scalar numbers such as intensities, opacities, sizes,
translations in a certain direction, etc. The behavior of
a standard slider widget is very likely to be familiar to
users in accordance with Principle 1.
Moreover, most sliders visualize the current set-
ting as well as the extreme values and, in fact, all pos-
sible values as required by Principle 4. If the default
value is not one of the extreme values, it is often pos-
sible to define the parameter such that the center posi-
tion of the slider represents the default value, which is
conveyed to users even without any explicit labels if
the default value is also the initial value of the widget.
In Western culture, Principle 1 suggests that a
slider movement to the right or up should correspond
to an increase of the parameter. Furthermore, changes
should correspond to appropriately scaled changes in
appearance. Specifically, the perceived “sensitivity”
of the slider (i.e. the change of appearance per dis-
tance moved by the slider) should be appropriate over
the whole range of possible values, i.e. the sensitivity
should not be too high, which would make it diffi-
cult — or even impossible — to choose a sufficiently
good approximation to a particular value, nor should
it be too low, which would require largemovements of
the slider for visible changes of the appearance of the
shader and therefore might appear to the user as if the
slider was ineffective. In order to satisfy this require-
ment, it is often necessary to introduce a non-linear
mapping from user-specified parameters to low-level
GPU-shader parameters. For example, the range from
0 to 1 of a user-defined parameter can be mapped to
the range from 0 to infinity of a low-level parameter
by the mapping x 7→ ((1− x)
−c
1
− 1)c
2
with two posi-
tive real numbers c
1
and c
2
, which can be adjusted by
the programmer to provide an appropriate sensitivity.
4.3 Couplings of Parameters
While Principle 2 encourages decoupled parameters,
there are various cases in which coupled parameters
are actually more user-friendly. One reason for the
coupling of parameters is to offer users alternative
ways of specifying the same (low-level) parameters.
An example is the specification of a color either in the
RGB or the HSV space. In these cases, the coupling
should be clearly communicated to the user, for ex-
ample by displaying only one set of independent pa-
rameters (e.g. either the RGB coordinates or the HSV
coordinates) at a time.
As discussed by Sadeghi et al. (Sadeghi et al.,
2010), it is sometimes useful to optionally couple pa-
rameters; for example, in order to allow users to find
an initial solution by manipulating only a subset of
all parameters and automatically computing further,
coupled parameters. Novice users who are not famil-
iar with all parameters would particularly benefit from
such a coupling. However, later in the artistic process,
some users might want to fine tune these additional
parameters separately without the coupling between
parameters. Some expert users might even prefer to
always use the decoupled version.
Thus, a shader interface should allow the user to
enable or disable the coupling of shader parameters.
This can be achieved with the help of a checkbox or
similar widgets. In fact, the concept of optionallycou-
pled parameters is familiar to many users; for exam-
ple, several image editing tools allow to fix the as-
pect ratio of an image when specifying a new width
or height.
In some cases, couplings are unavoidable; for ex-
ample, highlights become invisible if their color is
set to black; thus, other parameters, e.g. the size of
the highlight, become ineffective as the highlight no
USER-CENTERED DESIGN OF GPU-BASED SHADER PROGRAMS
251