Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Part II. Basics

Chapter 8. User Interfaces for Configuration Environments

Gerhard Leitner^a, Alexander Felfernig^b, Paul Blazek^c, Florian Reinfrank^b and Gerald Ninaus^b, ^aAlpen-Adria Universität Klagenfurt, Klagenfurt, Austria, ^bGraz University of Technology, Graz, Austria, ^ccyLEDGE, Vienna, Austria

Abstract

Configuration technologies are successfully applied in different domains such as telecommunication, financial services, and automotive. User interfaces of configuration environments play a key role with regard to two major aspects. First, users of a configurator application need interfaces that allow for efficient and intuitive configuration processes. Second, knowledge engineers and domain experts (developers of configurator applications) need interfaces that provide intelligent support of development and maintenance operations. In this chapter we discuss aspects that should be taken into account when developing user interfaces for configurator end users and application developers.

Keywords

Knowledge-based Configuration; User Interfaces; End Users; Application Developers; Knowledge Engineering; Guidelines

Acknowledgments

The work presented in this chapter was partially funded by the Austrian research promotion agency (grant number: 827587).

8.1 Introduction

Configuration is one of the key technologies of mass customization (Anderson and Pine, 1996; Pine, 1999; see also Piller and Blazek, 2014¹). It can be defined as a special case of design activity where the resulting artifact is composed from a predefined set of component types and is consistent with a given set of constraints (Sabin and Weigel, 1998). Configuration environments allow endusers to design their own individualized products and services and knowledge engineers and domain experts to develop configurator applications (mainly user interfaces and knowledge bases). For both types of users, the user interface of the configuration environment plays a key role. First, a major precondition for lasting acceptance and application is that end users can easily configure a product that fits their wishes and needs (Ardissono et al., 2003; Falkner et al., 2011). Second, knowledge engineers and domain experts need technologies that allow effective development and maintenance, which are a precondition for up-to-date knowledge bases (Blythe et al., 2001). For both scenarios we discuss properties of user interfaces that help to make the application of configuration technologies a success.²

The major contributions of this chapter are the following. We provide an overview of important criteria to be taken into account when developing user interfaces for configurator applications as well as user interfaces for the corresponding knowledge engineering environments (see Section 8.2). For the criteria, we present and exemplify supporting technologies (see Section 8.3). In the following, we discuss usability issues related to configurator user interface construction in industrial practice (see Section 8.4). Section 8.5concludes this chapter.

8.2 Design Principles for Configurator User Interfaces

Contrary to conventional product design where experienced product designers and managers are responsible for the design of product alternatives offered to a customer, the task of customization is now also presented to end users. An important aspect in this context is that we cannot expect end users to possess detailed technical product domain knowledge. Moreover, end users typically do not know their preferences and needs beforehand, which makes the configuration task even more challenging (Simonson, 2003). As analyzed by Randall et al. (2005), there are problems with existing configurator user interfaces that have to be tackled in order to increase the usability of configuration technologies. We now summarize five key principles to be taken into account when developing user interfaces for configuration environments (see Randall et al., 2005). In this context we focus on both interfaces for users of a configurator application as well as interfaces that support knowledge engineers and domain experts in configurator application development and maintenance. A discussion of relevant approaches to support the presented design principles is given in Section 8.3.

Principle 1: Customize the Customization Process. Sales persons are typically adapting their customer interaction style depending on the type of customer. For example, customers interested in technical details should be supported by in-depth technical information and corresponding analyses. In contrast, customers without expertise in the product domain should be supported by a more function-oriented dialog where technical details are omitted. Since we can expect different types of end users of a configurator application, we need technical approaches that help to personalize the interaction with the configuration environment depending on the basic characteristics of the current user (see also Tiihonen et al., 2014³). As proposed by Randall et al. (2005), a configuration environment should support at least two different types of user interfaces: a needs-based interface for non-experts and a parameter-based one for users who want to perform configuration primarily on the basis of the given set of technical product properties.

Similar to end users there are also different types of knowledge engineers and domain experts responsible for the development and maintenance of a configurator application. There may be experts who know every technical property of the product, as well as novices or new employees who recently started and did not acquire enough expertise yet about the knowledge representation. These two types of users need different navigation styles.

Principle 2: Provide Starting Points. Users of a configurator application can not only be differentiated with regard to their product preferences, they can also be differentiated with regard to their preferred product properties (i.e., properties of a product they are interested in and would like to specify). For example, one user of a car configurator prefers to start with a specification of the car type (e.g., limousine vs. combi) whereas another user prefers to specify the price as a parameter with the highest priority. In this context, a requirement for configurator user interfaces is the provision of so-called starting points, which can be seen as a kind of initial design from which the customer can continue the configuration activities. The important idea behind starting points is that not every user is interested in designing (configuring) a product from scratch but rather relies on existing basic settings (also known as stereotype configurations).

Starting points should also be provided for knowledge engineers and domain experts. A knowledge engineer (or domain expert) with nearly no knowledge about an already existing configuration knowledge base clearly needs an indicator of where to best start the analysis of the knowledge base. Such starting points can improve the overall efficiency of developing a basic understanding of a knowledge base, or more generally, a configurator application. Another example of a starting point in the context of knowledge base development and maintenance are recommendations (see also Tiihonen et al., 2014)⁴ to inspect those parts of a knowledge base that have low understandability (Felfernig et al., 2013a).

Principle 3: Support Incremental Refinement. Users of a configurator application typically construct their preferences within the scope of a configuration session (Simonson, 2003); that is preferences are not known beforehand. A requirement for user interfaces in this context is that the configurator should actively support sensitivity analysis in the sense that tradeoffs between different properties are visualized and alternatives to the current configuration are shown in an intuitive fashion. An easy way to support such a tradeoff analysis is to include product comparison functionalities—a comparison between different alternative configurations. An important functionality in this context is that the configurator is able to automatically determine alternative configurations on the basis of defined user preferences.

Similarly, there is a need for the support of tradeoff analysis in the context of knowledge base development and maintenance. In this context, a knowledge engineer (or domain expert) should be supported in correction and extension activities. For example, if a domain expert has specified examples for the intended behavior of a configurator in terms of which configuration should be shown in which context (kind of test cases; see Friedrich et al., 2014⁵) and the configurator is not able to fulfill these requirements, then the configurator should provide the means for explaining the given inconsistency (see Felfernig et al., 2014⁶ and Friedrich et al., 2014). In this context, the user interface should support the comparison of explanations for the inconsistencies (e.g., diagnoses and repair proposals for faulty knowledge bases) and it should provide information about the pragmatics of changes to the knowledge base, for example, in terms of test cases, which are additionally accepted by the knowledge base due to the performed repairs.

Principle 4: Exploit Prototypes to Avoid Surprises. A major obstacle for the willingness to purchase a product is the lack of trust in a given configuration (Felfernig et al., 2006b; Grabner-Kräuter and Kaluscha, 2003). Since configurations in many cases are unique, the exploitation of product evaluations for decision making is often impossible. Consequently, alternative concepts have to be provided, which help the customer to anticipate the post-purchase experience (Randall et al., 2005). In this context it is important to visualize the impact of different decision alternatives on the final configuration outcome. For example, a change of the interior color of a car has to be immediately shown to the user by directly visualizing the new interior of the selected car type. Another example is the configuration of financial service portfolios: after increasing the level of willingness to take risks or after increasing the expected yearly return rate of a financial service, the configurator should immediately show the possible consequences of the decision. For example, in terms of less available money due to plunging stock prices or, on a more visual level, in terms of the possibility of not being able to buy the envisioned car.

In the context of configurator application development, we need prototypes for visualizing the consequence of decisions made during the configuration process. For example, when developing a knowledge base, knowledge engineers and domain experts should be able to test the new version of the knowledge base by interacting with the configurator; new versions of a knowledge base have to be automatically integrated with the corresponding user interface. Another example of a visualization in the context of knowledge base development and maintenance is to show information regarding quality properties of the knowledge base (Felfernig et al., 2013a). If a knowledge engineer adapts or extends the knowledge base, feedback should be given immediately, for example, in terms of an indication of a deterioration or improvement of the level of maintainability (Felfernig et al., 2013a). Test cases often have to be adapted due to the fact that they fail after the completion of change operations. Such adaptations should be proactively supported by the configuration environment.

Principle 5: Teach the Consumer. Often consumers do not have the technical background knowledge about important technical properties of the product. For example, customers do not usually know the performance specifications required for a specific processor type (Randall et al., 2005). Increasing knowledge about the properties of a configuration can also increase the corresponding willingness to buy (Felfernig et al., 2006a). As a consequence, we need mechanisms that assist users and help them to increase their personal product domain knowledge. Besides basic concepts such as help buttons, which explain the role of specific product parameters, more sophisticated explanation functionalities can be integrated into configuration environments. First, users typically need explanations as to why a concrete configuration has been recommended. This functionality can simply be supported by interpreting the information received from the configuration environment (i.e., which constraints were responsible for the calculation of the configuration). Second, users also need explanations in situations where no solution can be found by the configuration system. In this context, the user needs information regarding which requirements are responsible for the conflict as well as knowing what possible actions can be taken to arrive at a solution (see also Felfernig et al., 2014)⁷.

In the context of configuration knowledge acquisition and maintenance, similar explanation functionalities are needed: knowledge engineers and domain experts need to be informed about the sources of inconsistencies in the knowledge base (in case some of the test cases fail) and what the corresponding alternatives for repairing the knowledge base are. Another type of explanation stems from collaborative recommendation (Konstan et al., 1997) where explanations are typically presented in the form of users who purchased item also purchased item . This type of explanation can also be applied in the context of knowledge base development and maintenance, for example, in the form of users who changed constraint also changed constraint .

8.3 Technological Issues

On the basis of our discussion of basic design principles for configurator user interfaces in the previous section, we now focus on a discussion of basic technologies that can help to support these design principles for end user interfaces and user interfaces for knowledge engineers.

Customize the Customization Process. User interfaces of configurator applications can simply be implemented on the basis of explicit definitions of a configuration process. Such a process defines in which order parameters have to be specified by the user. For our computer configuration example (see Hotz et al., 2014⁸) we can specify, for example, two different types of user interfaces. For experts in the domain of personal computers, we could provide a search interface where a user (customer) can specify the requirements at the level of technical product properties such as type of cpu, motherboard, operating system, screen, hd unit, internet, and application software. For non-experts in the product domain, a user interface could ask questions at a more abstract (needs-oriented⁹) level such as primary types of use (e.g., multimedia and game playing, programming, video editing, complex mathematical calculations, and office applications). This needs-oriented view on the product assortment is known as the functional architecture of a configurable product (see Hotz and Wolter, 2014¹⁰). From the specification of preferences, the configurator application can then determine the corresponding technical properties. For example, video editing and complex mathematical applications require a multicore cpu architecture.

At both levels (functional architectures and detailed technical product properties), questions asked to the customer have to be ranked. The simplest way to achieve this is to specify a static ordering where, for example, the question regarding type of cpu is asked first. However, more flexible approaches have been developed, which help to adapt their strategy regarding the selection of the next question depending on the navigation behavior of the user. One approach to support a selection of questions “on the fly” is to apply the concepts of collaborative filtering (Falkner et al., 2011; Konstan et al., 1997). The idea of collaborative filtering is to determine recommendations for the current user on the basis of the preferences of users with a similar navigation behavior as the current user. In our scenario, in order to determine the next question to ask the current user, we would determine users with a similar navigation behavior (the nearest neighbors) and on the basis of the preferences of the nearest neighbors try to select (recommend) the next question to ask the current user.

A working example of such a collaborative dialog management is shown in Table 8.1. Users 1 through 5 have already completed their configuration sessions; for example, user 1 has first specified a value for CPU, then a value for OS, then an assignment of HD,motherboard, Screen, Internet, and finally Applications. The current user has already specified values for the parameters CPU and OS and we would like to predict which of the remaining parameters will next be specified by the current user. The nearest neighbors of the current user are user1, user3, and user4 since all of them have first selected a CPU, followed by an assignment of OS. Since the majority of nearest neighbors has selected motherboard as the third parameter, we recommend motherboard as the next parameter to be specified by the current user. For a more detailed overview of parameter selection methods refer to Falkner et al. (2011).

Table 8.1

Example of determining relevant questions on the basis of collaborative filtering (Konstan et al., 1997).

A similar approach can support the navigation of knowledge engineers (domain experts) in complex knowledge bases (see the example in Table 8.2). In our scenario, the knowledge engineers (users 1–4) have already interacted with the knowledge base; for example, user 1 took a look at all the constraints in the following order: .¹¹ The current user has already inspected the constraints and . The constraint that should be recommended next to the current user is since this one has been inspected next by the majority of the nearest neighbors of the current user (user 2 and user 4).

Table 8.2

Example of determining relevant constraints on the basis of collaborative filtering (Konstan et al., 1997).

The ICONE¹² knowledge acquisition prototype is an example of a graphical knowledge acquisition user interface that includes recommendation technologies for proactively supporting knowledge engineers and domain experts in their development and maintenance activities. The ICONE user interface is depicted in Figure 8.1. On the left-hand side, the user can exploit typical functionalities such as product data (component) management, definition and maintenance of constraints, and the definition of the configuration process (dialog management). In addition to these basic functionalities, the ICONE environment includes intelligent recommendation functionalities that proactively support the user in inspecting the knowledge base (e.g., the functionality take a look at … on the right-hand side of Figure 8.1). From the definition of products (components) and constraints, the ICONE knowledge acquisition user interface can directly generate the corresponding configurator applications for different platforms (iOS, Android, and HTML). Note that the exploitation of recommender algorithms and machine learning approaches in knowledge acquisition and maintenance scenarios is a young and evolving discipline; significant improvements regarding the efficiency of configurator development processes can be expected in the future (Burke et al., 2011).

FIGURE 8.1 ICONE Knowledge Acquisition Environment: Example of a simple requires relationship (see also Hotz et al., 2014).

Provide Starting Points. The basic approach to the provision of starting points is to predetermine parameter settings that are of interest for the user. Such starting points serve as default values, which are proposed to the user within the scope of a configuration session. On the one hand defaults can represent specific parameter settings, for example, in German-speaking countries the value for the keyboard part of the configuration is set to German. On the other hand, defaults can represent whole subconfigurations; for example, the default installation settings for a software package included in a computer configuration. Independent of the generic type of default (i.e., specific parameter setting vs. whole subconfiguration), defaults can be distinguished in terms of the way that default values are determined. Three basic types of defaults will be discussed in the following.

Static Defaults. A parameter has a fixed predefined default value that is independent of the current configuration context. For example, the default value of the parameter internet is set to yes since it is assumed that most of the users want to have included the corresponding network hardware. The application of this type of default is limited since in many cases defaults depend on the context of user interaction. This aspect of contextualization is taken into account by the following two types of defaults.

Rule-Based Defaults. Here the determination of defaults is personalized and the selection of default values is performed on the basis of predefined default rules. An example of such a rule is the following: if the user has selected “programming” as a main field of application then the default value of the parameter “memory” is set to xGB. Although this default type takes into account context information (on the basis of rules), rules trigger knowledge acquisition and maintenance efforts. The following default type does not rely on an explicit specification of contexts but on context learning on the basis of an analysis of already completed configuration sessions.

Adaptive Defaults. If we want to keep knowledge base development and maintenance efforts as low as possible, we have to develop mechanisms that are able to automatically determine parameter settings of relevance for the current user. Different types of machine learning approaches can be applied to support such an adaptive determination of defaults (Ardissono et al., 2003; Cöster et al., 2002; Falkner et al., 2011; Tiihonen and Felfernig, 2010). An example of the application of collaborative filtering is given in Table 8.3. The default value for the parameter OS (the operating system) proposed to the current user would be OS-Alpha since the nearest neighbors of the current user (the users 1 and 5) have choosen OS-Alpha. An example user interface that is based on adaptive default values is depicted in Figure 8.2. This configurator (RecoMobile) supports the configuration of mobile phones (for details see Tiihonen et al., 2014¹³).

Table 8.3

Example of determining default values for the parameters of the computer configurator on the basis of collaborative filtering (Konstan et al., 1997).

FIGURE 8.2 RECOMOBILE user interface for the representation of (adaptive) defaults.

In the context of knowledge engineering and maintenance scenarios, defaults play a major role as well. The recommendation of constraints (see Figure 8.1) that could be of relevance for the current user (knowledge engineer or domain expert) can be interpreted as a specific type of adaptive default. Similar defaults can be determined for diagnoses (Felfernig and Schubert, 2010) or sets of redundant constraints (i.e., constraints that do not change the semantics of the knowledge base when deleted; Felfernig et al., 2011). In this context, a default can be interpreted as a set of faulty or redundant constraints.

Support Incremental Refinement. An important feature to support a user in preference construction is to explicitly visualize the existing tradeoffs between different configuration alternatives in corresponding comparison tables (Felfernig et al., 2006a). An approach often used to support such a tradeoff analysis is to simply rank alternative configurations with regard to their price (see Figure 8.3). Presenting configuration alternatives in such a way biases the product comparison toward an evaluation of the price attribute (see also Mandl et al., 2014¹⁴). Since price is in many cases the most important decision criterion, such interfaces are often used in commercial settings. The major drawback of this type of product comparison is that the interface does not take into account the real preferences of the user.

FIGURE 8.3 Configuration comparison interface based on price ranking.

If user preference information is available, it can be taken into account when presenting configuration alternatives. For the purpose of our example let us assume that the preferences of the current user regarding the importance of the different product properties is known (see Table 8.4). Such preferences can be obtained, for example, by directly asking the user or by learning from the interactions of previous users. Additionally, we have a utility evaluation of the different product properties (see Table 8.5).

Table 8.4

Example list of user preferences.

Table 8.5

Example list of product utilities.

On the basis of this information and a corresponding utility function we can determine the user-specific utility of each configuration alternative (Felfernig et al., 2013b; Winterfeldt and Edwards, 1986). The utility function used for the purposes of our example is shown in Formula 8.1 where denotes a specific configuration alternative, denotes the importance of product property for the current customer, and denotes the utility of configuration with regard to property .

(8.1)

When combining the customer-specific preferences (Table 8.4) with the attribute utilities defined in Table 8.5, we receive the ranking configuration (^$612) > configuration (^$455) > configuration (^$389) (see Table 8.5). This shows that the most expensive configuration can also have the highest utility for a user. A corresponding comparison interface is sketched in Figure 8.4.

FIGURE 8.4 Configuration comparison interface based on utility-based ranking.

Note that tradeoff analysis does not only play a role in the context of comparing different solution alternatives with regard to their utility for the user. In situations where no solution can be found for the current set of user requirements (specified preferences), the configurator application proposes a set of repair alternatives—alternatives for changes to the current set of requirements that can guarantee the retrieval of a solution (Felfernig et al., 2009, 2013c). Such repair alternatives can be represented in the same way as alternative configurations (see Figure 8.5).

FIGURE 8.5 Repair comparison interface based on utility-based ranking.

Tradeoff analysis in the context of configuration knowledge base development and maintenance has a similar need in terms of user support. When testing a knowledge base, knowledge engineers have to figure out which constraints are responsible for the faulty behavior of a knowledge base (e.g., the knowledge base calculates configurations that are not feasible on the technical level) and that are the repair alternatives to be taken into account. In this situation, different subsets of constraints have to be evaluated with regard to the probability of being responsible for the faulty behavior of the knowledge base. A detailed technical discussion of the techniques supporting the automated identification of faulty constraint sets can be found in Friedrich et al. (2014).¹⁵

Exploit Prototypes to Avoid Surprises. An important commercial aspect to consider is the concept of trust that sides the act of purchasing. This is even more important with online configuration environments (see Felfernig et al., 2007, 2006a, 2008; Grabner-Kräuter and Kaluscha, 2003). Due to large solution spaces of configurable offerings, individual configurations are in many cases unique. As a consequence, product evaluations are not available. A concrete visualization of the outlook (and pragmatic) of theconfiguration is crucial in order to give the customer a clear impression of the product he/she will purchase. Examples of such visualization-based configurator user interfaces are shown in Part IV.

Prototyping concepts also play a major role in the context of configurator application development and maintenance. When creating or adapting a configurator application, the knowledge engineer should be able to immediately analyze the impact of changes on the layout of the configurator interface as well as on the underlying configuration logic. The configuration environment Combeenation¹⁶ is an innovative look and feel environment that supports application development on a graphical level (see Figure 8.6).

FIGURE 8.6 COMBEENATION: Integrated development and visualization.

The definition of a configuration knowledge base is product-centered, which means that component and constraint definitions are directly attached to a graphical representation of the configurable product. This approach allows for rapid prototyping processes in the context of knowledge-based systems development and maintenance. Furthermore, Combeenation allows for immediate user testing and feedback; erroneous behavior of the application can be immediately reported to the responsible knowledge engineer. Further research related to graphical development, testing, and debugging environments for configurator applications can be found in Felfernig (2007).

Teach the Consumer. The basic and widespread approach to support a better understanding of configuration results as well as situations where inconsistencies occur is to provide explanations (Sinz et al., 2007). Basically, we can differentiate between two basic forms of explanations. First, an explanation can provide a set of argumentations as to why a configuration alternative has been recommended (Felfernig et al., 2006a). Second, in situations where the configurator cannot find any solution, the user has to be informed about the underlying inconsistencies and potential repairs. An example of the visualization of such inconsistencies is provided in Figure 8.7, which shows the screenshot of the WeCoTin configuration environment (Tiihonen et al., 2013). This environment represents the result of pioneer research in the field of answer set programming (ASP; see also Hotz et al., 2014¹⁷ and Tiihonen and Anderson, 2014).¹⁸

FIGURE 8.7 WECOTIN: Configuration environment (car configurator).

In the context of knowledge base development and maintenance, knowledge engineers and domain experts are in a similar situation—they have to be informed about the sources of faulty behavior; for example, in the case that certain test cases become invalid due to a prior change to the knowledge base. In such situations, diagnoses take over the role of explanations (see also Felfernig et al., 2014¹⁹). Beside these basic types of explanations, all the criteria for the development of configurator user interfaces discussed in the prior sections also contribute to a better understanding of the product domain and the underlying configuration knowledge bases. Customizing the customization process allows users to deal with topics they are interested in and as a consequence, to know more about relevant concepts of the product domain. Similarly, knowledge engineers can efficiently develop a basic understanding of the most relevant components and constraints part of the configuration knowledge base. The provision of starting points offers initial and reasonable settings in terms of, for example, a partial configuration and thus helps to reduce overheads related to the design of consistent configurations. Furthermore, starting points make knowledge engineering operations more efficient due to the availability of additional indicators of potential sources of inconsistencies.

Knowledge engineers and domain experts are supported in developing a basic understanding of the tradeoffs with regard to alternative repair operations needed to restore the consistency of a knowledge base. Supporting the concept of incremental refinement, for example, on the basis of product comparison pages, helps the user to develop a clear understanding of existing tradeoffs in the space of solutions offered by the configuration knowledge base. Finally, prototypes that are visualizing alternative configurations can significantly help to develop a better understanding and clearer preferences regarding certain solution alternatives. In the context of knowledge base development, such visualizations help to understand alternative impacts of change operations on the next version of the knowledge base (Felfernig, 2007).

To summarize the discussed design principles for user interfaces of configuration environments, we provide an overview of these principles, including related technological foundations (see Table 8.6).

Table 8.6

Design principles of configurator user interfaces and technological foundations.

8.4 Usability Issues in Configurator User Interface Development

The diversity of the configuration model has a strong influence on the design and structure of user interfaces—nevertheless certain commonalities can be identified. The Configurator Database Project²⁰ provides a collection of online configurators and includes more than 800 entries. After analyzing configuration environments contained in this database, we detected that more than 50% of the analyzed configurators show the following basic characteristics:

• Selected components are summarized at the end of the configuration process.

• Products available for configuration are presented as images.

• Process navigation, if available, is structured on a horizontal plane.

• Choice fields are positioned next to and/or beneath the product picture.

• Shopping cart, order button, and total price are clearly visible.

A configurator application that takes into account the mentioned characteristics is depicted in Figure 8.8. It is intended as an example for developers of configurator applications. Important hints regarding the design of individual configurator user interface elements are the following:

• The logo should be shown in a dominant position for a fast identification.

• The navigation bar should be clearly visible and shown unfragmented.

• The size of product (configuration) images should be sufficient to see details.

• Selection box(es) should follow a logical clustering.

• Prices (price tables) should be accessible in all steps of a session.

• User preferences should be adaptable (e.g., by back/forward navigation).

• Shopping cart and order-button should be available for completion purposes.

FIGURE 8.8 A prototype web-based bicycle configurator (see www.cyledge.com).

Summarizing, a close-to-reality approach is recommended to reduce the uncertainties that a customer feels regarding a product that is not tangible yet. For a more detailed discussion on usability issues in configurator user interface development refer to Rogoll and Piller (2004).

8.5 Conclusion

With this chapter we provide an overview of relevant principles of developing user interfaces for configuration environments. In this context we focused on both types of user interfaces, interfaces for the end-user and interfaces for knowledge engineers and domain experts who are in charge of knowledge base development and maintenance. In addition to this discussion of design principles, we proposed a couple of technologies that help to achieve these principles.

References

1. Anderson D, Pine JB. Agile Product Development for Mass Customization. McGraw-Hill 1996.

2. Ardissono L, Felfernig A, Friedrich G, et al. A framework for the development of personalized, distributed web-based configuration systems. AI Magazine. 2003;24(3):93–108.

3. Blythe J, Kim J, Ramachandran S, Gil Y. An integrated environment for knowledge acquisition. In: 6th International Conference on Intelligent User interfaces. New York, Santa Fe, NM: ACM; 2001:13–20.

4. Burke R, Felfernig A, Göker M. Recommender systems: an overview. AI Magazine. 2011;32(3):13–18.

5. Cöster C, Gustavsson A, Olsson R, Rudström A. Enhancing web-based configuration with recommendations and cluster-based help. In: Francesco R, Barry S, eds. AH’02 Workshop on Recommendation and Personalized in e-Commerce. Málaga, Spain: Universidad de Málaga; 2002:30–40.

6. Falkner A, Felfernig A, Haag A. Recommendation technologies for configurable products. AI Magazine. 2011;32(3):99–108.

7. Fano A, Kurth S. Personal Choice Point: helping users visualize what it means to buy a BMW. In: International Conference on Intelligent User Interfaces IUI’03. New York; Miami, FL: ACM; 2003:46–52.

8. Felfernig A. Standardized configuration knowledge representations as technological foundation for mass customization. IEEE Transactions on Engineering Management. 2007;54(1):41–56.

9. Felfernig A, Schubert M. Diagnosing inconsistent requirements. In: Hotz L, Haselböck A, eds. 19th European Conference on Artificial Intelligence (ECAI-2010), Workshop on Configuration Lisbon, Portugal. 2010;15–20.

10. Felfernig A, Friedrich G, Jannach D, Zanker M. An integrated environment for the development of knowledge-based recommender applications. International Journal of Electronic Commerce (IJEC). 2006b;11(2):11–34.

11. Felfernig A, Teppan E, Gula B. Knowledge-based recommender technologies for marketing and sales. International Journal of Pattern Recognition and Artificial Intelligence (IJPRAI). 2006a;21(2):333–354 (special issue of Personalization Techniques for Recommender Systems and Intelligent User Interfaces).

12. Felfernig A, Friedrich G, Gula B, et al. Persuasive recommendation: exploring serial position effects in knowledge-based recommender systems. In: De Kort Y, IJsselsteijn W, Midden C, Eggen B, Fogg BJ, eds. 2nd International Conference of Persuasive Technology (Persuasive 2007). Palo Alto, CA: Springer; 2007;283–294. Lecture Notes in Computer Science vol. 4744.

13. Felfernig A, Gula B, Leitner G, Maier M, Melcher R, Teppan E. Persuasion in knowledge-based recommendation. In: Oinas-Kukkonen H, Hasle PFV, Harjumaa M, Segerståhl K, Ø hrstrm P, eds. Persuasive Technology, 3rd International Conference (PERSUASIVE 2008). Oulu, Finland: Springer; 2008;71–82. Lecture Notes in Computer Science vol. 5033.

14. Felfernig A, Schubert M, Friedrich G, Mandl M, Mairitsch M, Teppan E. Plausible repairs for inconsistent requirements. In: 21st International Joint Conference on Artificial Intelligence (IJCAI’09), Pasadena, CA. 2009:791–796.

15. Felfernig A, Zehentner C, Blazek P. CoreDiag: eliminating redundancy in constraint sets. In: 22nd International Workshop on Principles of Diagnosis (DX’2011), Murnau, Germany. 2011;219–224.

16. Felfernig A, Schubert M, Zehentner C. An efficient diagnosis algorithm for inconsistent constraint sets. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM). 2012;26(1):53–62.

17. Felfernig A, Reiterer S, Stettinger M, Reinfrank F, Jeran M, Ninaus G. Recommender systems for configuration knowledge engineering. In: Workshop on Configuration Vienna, Austria. 2013a:51–54.

18. Felfernig A, Schippel S, Leitner G, et al. Automated repair of scoring rules in constraint-based recommender systems. AI Communications. 2013b;26(2):15–27.

19. Felfernig A, Schubert M, Reiterer S. Personalized diagnosis for over-constrained problems. In: 23rd International Conference on Artificial Intelligence, Peking, China. 2013c:1990–1996.

20. Felfernig A, Reiterer S, Reinfrank F, Ninaus G, Jeran M. Conflict detection and diagnosis in configuration. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:73–87. (Chapter 7).

21. Friedrich G, Ryabokon A, Falkner AA, Haselböck A, Schenner G, Schreiner H. (Re)configuration based on model generation. In: Second Workshop on Logics for Component Configuration (LoCoCo 2011), Perugia, Italy. 2011;26–35.

22. Friedrich G, Jannach D, Stumptner M, Zanker M. Knowledge engineering for configuration systems. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:139–155. (Chapter 11).

23. Grabner-Kräuter S, Kaluscha E. Empirical research in on-line trust: a review and critical assessment. International Journal of Human-Computer Studies. 2003;58(6):783–812.

24. Heiskala M, Anderson A, Huhtinen V, Tiihonen J, Martio A. A tool for comparing configurable products. In: 18th International Joint Conference on Artificial Intelligence – Workshop on Configuration. Acapulco, Mexico: AAAI; 2003:64–69.

25. Hotz L, Wolter K. Smarthome configuration model. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:121–135. (Chapter 10).

26. Hotz L, Felfernig A, Stumptner M, Ryabokon A, Bagley C, Wolter K. Configuration Knowledge Representation and Reasoning. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:41–72. (Chapter 6).

27. Konstan J, Miller B, Maltz D, Herlocker J, Gordon L, Riedl J. Grouplens: applying collaborative filtering to usenet news full text. Communications of the ACM. 1997;40(3):77–87.

28. Mandl M, Felfernig A, Teppan E. Consumer decision-making and configuration systems. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:181–190. (Chapter 14).

29. Mittal S, Frayman F. Towards a generic model of configuration tasks. In: 1989:1395–1401. 11th International Joint Conference on Artificial Intelligence (IJCAI-89), Detroit, Michigan. vol. 2.

30. Piller FT, Blazek P. Core capabilities of sustainable mass customization. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:107–120. (Chapter 9).

31. Pine BJ. Mass Customization: The New Frontier in Business Competition. Harvard Business School Press 1999.

32. Randall T, Terwiesch C, Ulrich K. Principles for user design of customized products. California Managament Review. 2005;47(4):1–18.

33. Rogoll T, Piller FT. Product configuration from the customer’s perspective: A comparison of configuration systems in the apparel industry. In: International Conference on Economic, Technical and Organisational aspects of Product Configuration Systems (PETO 2004) Lyngby, Kopenhagen, Denmark. 2004;179–199.

34. Sabin D, Weigel R. Product configuration frameworks - a survey. IEEE Intelligent Systems. 1998;13(4):42–49.

35. Simonson, I., 2003. Determinants of Customer’s Responses to Customized Offers: Conceptual Framework and Research Propositions. Stanford GSB Working Paper No. 1794.

36. Sinz C, Haag A, Narodytska N, et al. Configuration. IEEE Intelligent Systems. 2007;22(1):78–90.

37. Tiihonen J, Anderson A. VariSales. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2013:309–318. (Chapter 26).

38. Tiihonen J, Felfernig A. Towards recommending configurable offerings. International Journal of Mass Customization. 2010;3(4):389–406.

39. Tiihonen J, Heiskala M, Anderson A, Soininen T. WeCoTin – a practical logic-based sales configurator. AI Communications. 2013;26(1):99–131.

40. Tiihonen J, Felfernig A, Mandl M. Personalized configuration. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:167–179. (Chapter 13).

41. Winterfeldt D, Edwards W. Decision analysis and behavioral research. London, UK: Cambridge University Press; 1986.