=Paper=
{{Paper
|id=Vol-2068/exss12
|storemode=property
|title=Representing Repairs in Configuration Interfaces: A Look at Industrial Practices
|pdfUrl=https://ceur-ws.org/Vol-2068/exss12.pdf
|volume=Vol-2068
|authors=Tony Leclercq,Maxime Cordy,Bruno Dumas,Patrick Heymans
|dblpUrl=https://dblp.org/rec/conf/iui/LeclercqCDH18a
}}
==Representing Repairs in Configuration Interfaces: A Look at Industrial Practices==
https://ceur-ws.org/Vol-2068/exss12.pdf
Representing Repairs in Configuration Interfaces:
A Look at Industrial Practices
Tony Leclercq, Maxime Cordy, Bruno Dumas, Patrick Heymans
University of Namur, Belgium
first.last@unamur.be
ABSTRACT configurator achieves this by, notably, making unavailable new
Configurators are widespread applications where users can options that are incompatible with the options already selected.
tailor products (i.e. goods or services) to their needs by se- This functionality, named propagation, drastically simplifies
lecting options and setting parameter values. Constraints over the work of the user. The downside lies in the risk for the user
these options exist to avoid building invalid products. Thus, to be refused options that she really wants, due to previous
when the user attempts to combine incompatible options, the choices that were of lesser importance. In this case, she must
configurator should raise an error and help the user repair her change her configuration to make the desired option available.
configuration, that is, change the selected options to obtain a This can be really difficult, as the incompatibility between the
valid product. In this paper, we observe how 54 configurators desired option and the current configuration can result from
from different industries handle this repair mechanism. We the interaction of many constraints between many options.
show that in a majority of cases, the configuration interfaces
A prerequisite is to explain the reason why the option is not
exhibit bad practices that impede an effective usage of repair,
available. This is a common functionality required in configu-
thereby impoverishing user experience.
rators, that classifies them amongst the range of explainable
ACM Classification Keywords
software systems. Feedback explanations already help the
customer resolve the incompatibility problem, but they are
H.5.2. User Interfaces: Graphical user interfaces (GUI), Stan-
far from sufficient. This motivated the need for configuration
dardization, Configurator, Smart system
repair [3, 9, 15, 4], an automated method to determine what
INTRODUCTION
must be changed in the configuration to accept a forbidden
option. Computing configuration repair is not an easy task:
Today’s companies increasingly rely on mass customisation
consider, e.g. that to select an option o1 , an option o2 must be
to provide their customers with products (i.e. goods or ser-
unselected, but doing that requires to select a third option o3 .
vices) that meet their particular needs, while still achieving
Still, efficient solutions exist, e.g. [16]. Together with validity
economies of scale [12]. The customisation of a product is
checking, propagation and explanation, configuration repair is
typically performed via a software application named config-
essential for a smooth user experience [13].
urator [6]. This application often comprises a graphical user
interface where users enter their needs and preferences by A question yet unaddressed is how to properly integrate repairs
selecting options and setting parameter values. Configurators in the graphical user interface of configurators [14, 1, 10, 4].
have been developed for many years and are more and more Major difficulties include the possibly high number of changes
frequently used, be it as back-office tools in companies [2, 8, to perform, and the potential inability of the repair algorithm
11, 7] or as public tools on the web. The ever-growing size of to determine all the changes to make in one execution step.
Cyledge’s Configurator Database [5] witnesses the ongoing Our long-term objective is to fill this gap by providing HCI
interest towards configurators. Given their critical role in to- guidelines for representing repairs, thereby contributing to
day’s businesses, these must be effective at guiding users and build a consistent body of knowledge dedicated to engineering
absolutely reliable. configurators, as envisioned by Abbasi et al [1].
An essential functionality of a configurator is to guarantee that This paper constitutes the first step of our work. More pre-
the configuration created by its user is valid. Indeed, invalid cisely, we analyse how 54 configurators, chosen across 10
configurations must be avoided as they lead to inappropriate industries, represent repairs in their interface. Thereby, we
products, be it for technical, marketing or legal reasons. The aim at identifying bad practices in current configurators, which
would in turn justify the need for precise guidelines specific to
configuration repair. Our observations show that 46 configu-
rators do not handle repair properly. This is due not only to
their inability to compute repairs in every problematic case,
but also to bad integrations within the configuration UI. This
motivates the need for standard guidelines for handling repair
within any configuration interface.
©2018. Copyright for the individual papers remains with the authors.
Copying permitted for private and academic purposes. ExSS ’18, March
11, Tokyo, Japan.
Figure 3. Propagation without explanation or repair
Figure 1. An example of PC configurator
Figure 4. Configuration repair following a selection
especially in the western industry2 , provide a lot of customi-
sation possibilities: customers can combine any trim with the
many available options. It is therefore unrealistic not to pro-
Figure 2. Explanation after a detected configuration invalidity
vide the customer with a repair functionality showing her how
the configuration must change to accept a desired option. Fig-
A FEW EXAMPLES OF REPAIR IN CONFIGURATORS ure 4 illustrates this situation occurring in the UK Volkswagen
We first illustrate through intuitive examples what lies behind configurator. The rear-view camera option requires either the
a configurator and the concept of configuration repair. Figure 1 standard park assist or its trailer variant. Accordingly, after
shows an overview of a PC configurator.1 The left part of the selecting rear-view camera, the customer is asked to select one
screen gives a summary of the current configuration, while of the two park assist options.
the right one depicts the parts of the PC to configure (such as
CPU, Coolers, and motherboard). Not all combinations are BENCHMARKING CURRENT PRACTICES IN INDUSTRY
valid, though. For instance, once the customer has selected a The previous section already highlights multiple difficulties
motherboard, obviously the quantity of RAM modules cannot that users may encounter. To better assess the rate of oc-
exceed the number of slots on the motherboard; see Figure 2. currence of these issues, we carried out an evaluation of the
In this case, the configurator raises an error and explains that current practices in industry. More precisely, we selected 54
the selected quantity of RAM modules is inappropriate. It configurators taken from different industries: cars (28), com-
also suggests to reduce this quantity to make the configuration puters (5), audio systems (5), electrical appliances (5), boats
feasible. Thanks to this explanation, the user knows how to (6), drones (1), smart altimeters(1), trucks (1), motorbikes
repair her configuration. This mechanism, however, leads to (1), and garden rooms (1). Car configurators are particularly
two pitfalls. First, the customer has to fix the configuration interesting because they typically provide a high number of
manually, and is therefore forced to check how many slots are options and constraints, which even more justifies the need for
available on the selected motherboard. Second, the configu- explanations and repair mechanisms. For each configurator,
rator omits the alternative of selecting another motherboard we check whether 11 specific bad practices occur when repairs
equipped with more slots. This example is an instance of what are triggered. We consider three categories of bad practices
we name manual repair. depending on the type of repair mechanism that is provided.
Figure 3 illustrates another case problematic to the user. We 1. No repair. This first category comprises bad practices that
observe that some Power Supply Units (PSUs) are greyed make it impossible to compute repairs. These practices are:
because they are not compatible with the current configuration. (a) Undetected errors. The configurator does not check
This impedes the user to select these inappropriate power for inconsistencies, allowing users to build configura-
PSUs. However, no explanation is given and no automated tions that are not valid.
means of changing the configuration to accept these PSUs is (b) Unexplained errors. Configuration errors are raised
provided. While this might seem unimportant in this specific as soon as they are produced, but no explanation is
PC example, it can be really problematic when numerous given to the user.
options are provided to the user. (c) Invisible propagations. Unavailable options are hid-
den. The user is unaware of them and thus cannot ask
Consider instead car configurators, arguably the most popular
for a repair.
kind of configurator [5]. Cars are known to give access to a
high number of options and accessories. Their configurators, 2 We indeed observed that in their asian counterparts, configurators
often limit the customer’s choice to a smaller number of models with
1 See http://www.dinopc.com predefined options.
(d) Immutable propagations. Unavailable options are
greyed out but the user is impeded to select them.
(e) Unresolved repair. When the user attempts to make
an invalid choice or to change a propagated option, the
configurator proposes her to reset her configuration,
thereby losing any previous progress.
2. Manual repair. Manual repairs display messages explain-
ing users how to change their configuration to achieve their
goal. Related bad practices include:
(a) Misleading: The repair message is ambiguous and
does not precisely pinpoint the options to change.
(b) Misplaced: The repair message is not well situated,
resulting in low odds of being detected by users. Figure 6. Reasons for lack of repair
(c) Understated: Too little emphasis is given to the mes-
sage, running the risk for it to be unnoticed.
(d) Incomplete: The message suggests only one solution
although there exist others.
3. Assisted repair. Bad practices also occur when an auto-
mated repair mechanism directly proposes solutions to the
user (see Figure 4). These are:
(a) Unknown effects: The configurator proposes to mod-
ify the configuration, but does not explain which op-
tions would be changed.
(b) Cascading repair: The configurator is able to detect
the option o1 to change to achieve the user’s goal. How-
ever, if changing o2 requires changing another option
o2 , the configurator alerts the user only after she ac- Figure 7. Issues encountered in manual repair
cepted to change o2 . This process is repeated as many
times as the total number of options to change.
undetected errors. Indeed, 46 configurators are not able to
detect all the inconsistencies that may occur in a configura-
tion, which is quite surprising given the importance of this
must-have functionality. When errors are raised, they are too
often unexplained (11 cases). As for propagations, 14 config-
urators make them invisible while four do not allow one to
modify a propagated value. Finally, four configurators do not
support repair and only allow the user to completely reset the
configuration.
Figure 7 reports issues observed in the 14 occurrences of
manual repair. The four kinds of bad practices occur al-
most equally, with six occurrences of misleading explanations,
seven of misplaces explanations, five of understated, while
Figure 5. Number of configurators that support repair mechanisms seven configurators propose incomplete solutions. In total,
only four configurators implement manual repair properly (i.e.
Results. As a first step, we measure how many configurators
without exemplifying an identified bad practice).
exhibit cases of manual repair, assisted repair, and no repair
at all (see Figure 5). It turns out that 46 configurators do not Regarding the 23 configurators that provide assisted repair
provide a repair each they should. Manual repair occurs in 14 (see Figure 8), only one of them suffers from the cascading-
configurators, while assisted repair does in 23. These num- repair problem. The problem of unknown effects is, however,
bers also reveal that the way repair is handled is not always more frequent with 11 occurrences. Overall, half of these
consistent within a given configurator. Indeed, it happens that configurators handle assisted repair properly, although only
for some errors the configurator provides no repair, while for eight of them provide this functionality each time it is needed.
others it provides manual or assisted repair. This is symp- This low number corroborates our previous statement that
tomatic of configurators that are developed as any software managing configuration repair is a laborious task that cross-
and do not rely on a rule-based engine to perform logical cuts the whole configurator.
computations [4].
Surprisingly, the choice between manual and assisted repair
Looking at the no-repair cases (see Figure 6), we find out that highly depends on the considered industry. Car configura-
the most common reasons for the absence of repair are the tors rely more often on assisted repair than on manual repair
5. Cyledge. 2017. Configurator Database. (2017). Retrieved
July 24, 2017 from
http://www.configurator-database.com
6. Xuegong Ding. 2008. Product Configuration on the
Semantic Web Using Multi-Agent. In ICNSC ’08.
304–309.
7. Alexander Felfernig, Lothar Hotz, Claire Bagley, and
Juha Tiihonen. 2014. Knowledge-based Configuration:
From Research to Business Cases (1 ed.). Morgan
Kaufmann Publishers Inc., San Francisco, CA, USA.
Figure 8. Issues encountered in assisted repair
8. Gerhard Fleischanderl, Gerhard E. Friedrich, Alois
Haselböck, Herwig Schreiner, and Markus Stumptner.
(19 cases against 2). On the contrary, manual repair is more 1998. Configuring Large Systems Using Generative
common in computer and electrical appliance configurators, Constraint Satisfaction. IEEE Intelligent Systems 13, 4
whereas the audio configurators provide no repair at all. One (July 1998), 59–68.
possible explanation is that assisted repair is more important
in customer-oriented configurators, while the ones aimed at 9. Arnaud Hubaux, Yingfei Xiong, and Krzysztof Czarnecki.
domain experts can settle for manual repair. Nevertheless, 2012. A User Survey of Configuration Challenges in
this observation justifies the need for studying both types of Linux and eCos. In VaMoS ’12. ACM, 149–155.
repair. 10. Tony Leclercq, Jean-Marc Davril, Maxime Cordy, and
Patrick Heymans. 2016. Beyond De-Facto Standards for
CONCLUSION Designing Human-Computer Interactions in
Although repair is essential for a smooth user experience, Configurators. In EnCHIReS@EICS 2016, Bruxelles,
our study reveals that it is rarely properly and thoroughly Belgium. 40–43.
supported. This is indeed a difficult functionality to implement,
notably on the back-end side [9]. However, HCI guidelines are 11. Deborah L. McGuinness and Jon R. Wright. 1998.
also needed [10], especially as there is no de-facto standard Conceptual Modelling for Configuration: A Description
across multiple industries [14]. Given the bad practices that Logic-based Approach. Artif. Intell. Eng. Des. Anal.
proliferate amongst the configurators we studied, designing Manuf. 12, 4 (Sept. 1998), 333–344.
appropriate HCIs for repair will constitute an important focus 12. B.J. Pine and S. Davis. 1999. Mass Customization: The
of our future research work. New Frontier in Business Competition. Harvard Business
School Press.
ACKNOWLEDGEMENT
This work was partly supported by the European Commis- 13. Rick Rabiser, Paul Grünbacher, and Martin Lehofer.
sion (FEDER IDEES/CO-INNOVATION) and the Wallonia- 2012. A Qualitative Study on User Guidance Capabilities
Brussels Federation under the ARC programme. in Product Configuration Tools. In Proceedings of the
27th IEEE/ACM International Conference on Automated
REFERENCES Software Engineering (ASE 2012). ACM, New York, NY,
1. Ebrahim Khalil Abbasi, Arnaud Hubaux, Mathieu Acher, USA, 110–119. DOI:
Quentin Boucher, and Patrick Heymans. 2013. The http://dx.doi.org/10.1145/2351676.2351693
Anatomy of a Sales Configurator: An Empirical Study of 14. C. Streichbier, P. Blazek, and F. Faltin. 2009. Are
111 Cases. In CAiSE’13. Springer-Verlag, Berlin, De-Facto Standards a Useful Guide for Designing
Heidelberg, 162–177. Human-Computer Interaction Processes? The Case of
2. Liliana Ardissono, Alexander Felfernig, Gerhard User Interface Design for Web Based B2C Product
Friedrich, Dietmar Jannach, Ralph Schäfer, and Markus Configurators. In HICSS ’09. IEEE Computer Society,
Zanker. 2002. A Framework for Rapid Development of Washington, DC, USA, 1–7.
Advanced Web-based Configurator Applications. In 15. J. White, D. C. Schmidt, D. Benavides, P. Trinidad, and
ECAI’02. IOS Press, Amsterdam, The Netherlands, The A. Ruiz-Cortés. 2008. Automated Diagnosis of
Netherlands, 618–622. Product-Line Configuration Errors in Feature Models. In
3. Thorsten Berger, Steven She, Rafael Lotufo, Andrzej SPLC ’08. IEEE Computer Society, Washington, DC,
Wasowski,
˛ and Krzysztof Czarnecki. 2010. Variability USA, 225–234.
Modeling in the Real: A Perspective from the Operating
16. Yingfei Xiong, Arnaud Hubaux, Steven She, and
Systems Domain. In ASE ’10. ACM, New York, NY,
Krzysztof Czarnecki. 2012. Generating Range Fixes for
USA, 73–82.
Software Configuration. In ICSE ’12. IEEE Press,
4. Maxime Cordy and Patrick Heymans. 2018. Engineering Piscataway, NJ, USA, 58–68.
Configurators for the Retail Industry: Experience Report
and Challenges Ahead (to appear). In SAC ’18. ACM.