One-Hour Tutorial at the Workshop Session on Recommender SystemsGraz, October 12th, 2017

Using Chusapedia to Design ApplicationsThat Support Human Choice

Anthony Jameson

Chusable AG and DFKI, German Research Center for Artificial Intelligence

chusable.com, dfki.de/~jamesonchusapedia.chusable.com

Why Should You Care About This Topic?1. A primary function of recommender systems is to

support (or at least influence) people’s choices2. Doing so requires having a good general overview of

how people make choices and how they can be helpedto make better choices

3. A lot of knowledge about this topic is embodied in theknowledge base of the Chusapedia web application

4. Chusapedia also helps to reduce the complexity ofapplying this knowledge during the design andevaluation of recommender systems

5. Chusapedia also supports collaboration among analystsand researchers with regard to both

– the formulation of general knowledge and– the working out of specific applications of that knowledge

Why Is This Topic Difficult?

Current Views of Choice and Decision Making

How People Make Choices –in a Nutshell

High-Level Strategies forSupporting Choice

The ARCADE Model

Access Information and Experience• Help the chooser to gain access to

information and experience that isrelevant to the current choice.

Access Information and Experience

Represent the Choice Situation• Influence the way in which the

chooser perceives the choicesituation in such a way that thechooser's processing is facilitated.

Represent the Choice Situation

Combine and Compute• Process available information

computationally in a way thatfacilitates one or more processingsteps of the chooser.

Combine and Compute

Advise About Processing• Encourage the chooser,

implicitly or explicitly, to apply aparticular (part of a) choicepattern (in a particular way).

Design the Domain• Change the basic reality about

which the choice is being madeso as to make the choiceproblem easier.

Design the Domain

Evaluate on Behalf of the Chooser• Take over from the chooser some

step in the processing thatinvolves evaluation or choiceamong alternatives.

Evaluate on Behalf of the Chooser

Introduction to Chusapedia

Publications Are Not EnoughRecommender Systems Handbook (2nd edition):

2014: 2015:

Both works are available freely from my home page dfki.de/~jameson

Why Computational Support?1. Help analysts put the many

pieces together2. Make available domain- and

problem-type-specificknowledge

3. Integrate competing models4. Support sharing and reusing of

design solutions

What Can You Do With Chusapedia?1. Analyze how particular existing

recommender systems support andinfluence choices – and how they can beimproved in this respect

2. Analyze issues and strategies concerninga particular type of recommendersystem

3. (Coming soon:) Help extend Chuspediaby formalizing general knowledge in anarea of interest to you (see the nextslides)

Applying Chusapedia to anInteractive Product

Configuration System

During the remainder of this talk no further slides were presented. Instead, the presentation alternated betweenthe following two related demonstrations:1. Excerpts from a video-recorded demo of the configuration system Tacton CPQ – Heavy Vehicles.• Interested readers can view the entire demo video on the following page:• http://www.tacton.com/resources/?resource_type=m205-demos• The excerpts discussed are taken from the first few minutes of the 12-minute video.(Note: The presenter has no affiliation with the company Tacton. This demo was chosen because the configurationsystem is a representative state-of-the art commercial configurator and because the demo video is of high quality.)2. A live demonstration of how the application Chusapedia can be used to analyze the choices made by a user ofthe Tacton CPQ configurator.• Interested readers can find the analysis shown in the following slides at http://chusapedia-app.chusable.com

(at least through November 2017). This particular “intervention” should not be edited, but you can create a“separate copy” of it, changing its name, if you would like to experiment with the application by extending ormodifying the analysis.

• The following slides include screenshots and notes that convey the main points of this part of the presentation.

• We are going to analyze selected aspects of Tacton CPQ – Heavy Vehicles (“the configurator”) usingthe Chusapedia App (available via http://chusapedia-app.chusable.com).

• The app helps the user to analyze a choice-supporting intervention: any set of measures intended tohelp people make choices.

• The “Features” table shown here lists a number of features of the configurator that support users’choices in one way or another.

• In the next few slides, using the table “Design Rationale” (collapsed in this screenshot), we will lookclosely at several choices that a user of the configurator needs to make and how they are supportedby the listed features.

• In most of these slides, a partial screenshot of the configurator will be shown in the top part and thecorresponding part of the Chusapedia analysis will be seen in the bottom part.

• The first question to be asked in Chusapedia is: Who are the “choosers”? That is, whatindividuals or groups are making choices that are being supported by this intervention?

• In the case of this configurator, it appears that a customer is walked through theconfiguration process by a sales representative, who helps the customer to answer thequestions posed by the configurator. So choices are being made by both of theseindividuals: The choices of the sales representative concern questions like how to helpthe customer make his own choices.

• In the demo video, the presenter takes the role of a customer who is answering theconfigurator’s questions by himself. So in this presentation we assume this simplerscenario.

• Experience has shown that even the apparently simple task of explicitly listing thechoosers who are involved in an intervention can help analysts understand anintervention more clearly.

• The first choice to be made by the customer concerns the truck “series” that should be used as a starting point for the configuration.• Chusapedia helps the analyst to take into account the fact that people can apply various “choice patterns” (described in the ASPECT model

introduced in the book by Jameson et al., 2014; see the last slide for a link) when making choices like this. One clearly relevant pattern is the“consequence-based pattern”. This pattern comprises a number of “choice steps”, which Chusapedia offers to the analyst in a menu (notshown here); the analyst has chosen to analyze the two most important steps in this case. (Note: The names of the choice pattern and the twochoice steps are shown in gray to indicate that the analyst has adapted the standard texts offered in menus by Chusapedia; texts formulatedby the analyst him- or herself appear in black.)

• The first of these choice steps, identifying the available options, is often quite difficult; but it is made very easy in this case because theconfigurator applies the straightforward “choice support tactic” of informing the user about the available options. It does so with the “feature”of listing all of the options explicitly on the screen.

• The trickier step — for customers want a truck that does not fit one of the two “descriptions” much better than the other description — is thatof anticipating the consequences of choosing a particular series: A possible negative consequence of this choice is to discover much later that itis impossible to configure the desired truck using the selected series as a starting point. In that case, the user might have to start the wholeconfiguration process over again, using the other series is a starting point.

• One straightforward tactic used by the configurator is to describe explicitly what sorts of trucks can be configured within each series.• A less obvious choice-supporting tactic was applied earlier, by the truck company itself, when the product offerings of the truck company were

designed: The two truck series shown here are inherently relatively easy to choose between — as would not be the case, for example, if thedistinction were between “Modern trucks” and “Traditional trucks”.

• The ARCADE model of choice support that is included in Chusapedia (also introduced by Jameson et al., 2014) helps intervention designers andanalysts to identify a wide range of choice support tactics, so that they do not have to rely on the more obvious tactics.

• Another relevant choice pattern here is the “trial-and-error-based pattern”: The chooser tries out an option and observes whether applying ithas the desired effect. On the positive side, the configurator shows the specific initial configuration that results from the choice of a series (seethe next slide). On the other hand, this configuration doesn’t say much about what future choices will be possible if this series is chosen.

• As can be seen in the right-hand side of the configurator’s screen, from this point on at any momentthe configurator is managing a specific valid configuration for the customer’s truck.

• Each choice made by the customer will in general result in some changes to this configuration.• By inspecting the new configuration, the customer may (or may not, partly depending on his domain

knowledge) be able to evaluate whether his most recent choice has taken him in the right direction (cf.the description of the trial-and-error-based pattern on the previous slide).

• The three questions on this screen are in many ways similar to the one about the truck series; buthere we are told in the video that the customer has the option of skipping any of the questions.

• Hence one choice that the customer has with regard to each question from now on is whether to skipit.

• As the Chusapedia analysis indicates, the configurator offers less support for this choice than it doesfor the choice involved in providing an answer to a question.

• A quite different type of choice is offered on this screen: Which of three possible criteria theconfigurator should use when “optimizing” the configuration — that is, automatically making choicesthat are not explicitly made by the user.

• If the customer applies the trial and error-based pattern — simply checking which of the three offeredcriteria seems to yield the best result — the configurator’s feedback about the resulting configurationis even more helpful than in the example shown before: The configurator highlights the differencesrelative to the default criterion of “list price” (as can be seen in the color-coded substitution of a moreexpensive component in the right-hand column).

• Moreover, it is easy to reverse a tentatively made choice — simply by clicking on a different radiobutton.

• But suppose that the customer instead applies a different choice pattern, the “policy-based pattern”,taking into account his company’s policy with regard to this type of choice. If his company’s policymatches one of the three offered criteria, the choice is very easy. But suppose that the company has asomewhat more complex policy, such one that weights price and emissions equally: Then thecustomer has to determine which of the offered criteria best matches the company’s policy — adifficult step for which (understandably) no support is offered here.

• In this screen, the customer is being asked to select a “wheel configuration” (e.g., which axles shouldbe steerable). A difference here is that there is one recommended option, indicated by the dashedbox.

• While the choice patterns already discussed can also be applied here, there is an additional choice inthis case: whether to adopt the configurator’s recommendation. One applicable choice pattern here isthe “socially-based pattern”, which involves choosing on the basis of the advice, expectations, orexamples of other persons.

• Whereas “advice” is traditionally something that comes from another person, when recommendationtechnology is being deployed the advice can be seen as coming from the configurator. General tacticsfor helping people to process advice appropriately are relevant here.

• One such tactic is to somehow help the chooser to assess the credibility of advice giver. Specificvariants of this tactic include (a) providing information about the advice giver’s “track record”; and (b)explaining the reasoning or computation that led the advice giver to give this particular advice.

• As we can see, the configurator does not provide any such support here, instead leaving it to the userto assess how reliable the recommendation might be.

• This screen shows a relatively complex example of support for the trial-and-error choice pattern.• In Step 1, the user has chosen what seems like an appropriate engine, with 360 horsepower.• In Step 2, when proceeding to choose a gearbox, the customer sees that his preferred gearbox option “TC

Tronic” is grayed out, which means that the option is not available given the choices that have been made sofar.

• A sophisticated customer might recognize that the unavailability of TC Tronic is due to his choice of an engine,in which case he could backtrack and choose a different engine.

• The configurator makes the process of trial and error easier (Step 3 above) by (a) allowing the customer tochoose TC Tronic despite its incompatibility with previous choices and (b) informing the customer about aspecific change that he can make in his previous choices if he really wants to have the TC Tronic.

• As is indicated in the Chusapedia analysis, the configurator is providing unusually explicit support for the choicestep of selecting the next option to try out once a previously tried option has proven to be unsatisfactory.

• But note that, like the configurator’s recommendation concerning the wheel configuration, the user needs todecide for himself whether he will accept the configurator’s recommended resolution of the conflict.

For Further Information …

Chusable.com

Chusable.com

Additional relevantpublications are availablefarther down on this webpage.