Group recommendation technologies have been successfully applied in domains such as interactive television, music, and tourist destinations. Existing technologies are focusing on speci c domains and do not o er the possibility of supporting di erent kinds of decision scenarios. The Choicla group decision support environment advances the state of the art by supporting decision scenarios in a domain-independent fashion. In this paper we present an overview of the Choicla environment and exemplify it's application in the context of personnel decisions.
Decisions in everyday life often come up in groups, for
example, a decision about the destination for the next
holidays or a decision about which restaurant to choose for a
dinner. Knowledge about the preferences of other users in
early phases of a decision process can lead to sub-optimal
decision outcomes [
One major goal of the Choicla environment is to facilitate
group decision making and improve the overall quality of
decision outcomes. The idea of this environment is to support
de nitions of di erent types of decision tasks in a
domainindependent fashion while taking into account the above
mentioned risk factors. In order to achieve this goal, Choicla
builds upon di erent group recommendation algorithms [
One example of the application of Choicla is to support groups of users in context of personnel decisions with the aim of achieving a more structured, fair, and transparent way of job interviews as well as to nd the most suitable candidate for the job advertisement. Other typical scenarios for the application of Choicla technologies are the decision about which restaurant to select for a dinner or - in a scienti c community - a decision regarding the selection of the destination of next year's conference.
The remainder of this paper is organized as follows. In Section 2 we provide insights to (1) the Choicla modelling process where participants can design decision tasks from scratch and (2) the intelligent management of already created decision apps. In the Section 3 we give an overview of the personnel decision scenario. We then discuss related & future work (Section 4) and thereafter conclude the paper (Section 5).
Because decision scenarios di er from each other in their process design, a variety of parameters is needed to specify all relevant properties of a decision task. We will now discuss basic features (parameters) which can be con gured (modelled) by the creator of a decision task. In this context we refer to the example features depicted in Figure 1.
Because decision scenarios di er from each other, some
decision scenarios rely on a preselected decision heuristic that
de nes the criteria for taking the decision, for example, a
group decides to use majority voting for deciding about the
next restaurant or cinema visit. The design of decision tasks
(the underlying process) can be interpreted as a con
guration problem (see [
Administration of Decision Alternatives. The
administration of decision alternatives within the scope of a
decision task can be supported in di erent ways. First, only
the initiator of a decision task is allowed to add alternatives
{ this could be desired if a person is interested in knowing
the opinions of his/her friends about a concrete set of
alternatives (e.g., alternative candidates for the next family
car). Another related scenario are so-called "Micro-Polls"
where the initiator is only interested in knowing the
preference distribution of a larger group of users. Second, in
some scenarios it is important that all decision makers can
add alternatives during the decision task by themselves {
a common example of such a scenario is the group-based
decision regarding a holiday destination or a hotel [
Preference Visibility. The scope "private" allows only
invited users to participate, i.e., the decision task is only
accessible for invited users and not accessible for other users.
If the scope is "public", the decision task is accessible for
all users { this is typically the case in the context of
socalled Micro-Polls. The decision quality can be in uenced
if the individual preferences of the other participants are
visible during the decision process (see [
Group Distance (GD) (see Formula 1) returns the value d as group recommendation which causes the lowest overall change of the individual user preferences where eval(u; s) denotes the rating for a solution s de ned by user u.
GD(s) = minarg(d2f1::5g)( jeval(u; s) dj)
(1)
X Ensemble Voting can be seen as an example of a metaaggregation function included in Choicla. Ensemble Voting (see Formula 2) determines the majority of the results of the individual voting strategies H = fMAJ, AVV, LMIS, MPLS, GDg where eval(h; s) denotes the result of an individual voting strategy for a solution s.
EN S(s) = maxarg(d2f1::5g)(#( [ eval(h; s) = d)) (2) h2H
After the design process has been nished, the creator of the decision task as well as all invited participants (after accepting the invitation) see a corresponding decision app directly on the personal home screen (see Figure 2). gets subjective. In such a case the assessment criteria of the candidates change and no "fair" and objective decision can be made. Another important factor is that in most cases personnel decisions come up in groups of users which means that often more than one person is a ected by the hiring procedure.
To prevent groups from unsystematic reviews, Choicla offers a structured and fair way to evaluate candidates of a job position. Figure 3 shows the evaluation of the candidates in context of our working example (new receptionist) for a particular decision maker. The tab DecisionApp Store contains publicly available decision apps which can be searched and installed on the personal Home Screen. This method prevents a creation from scratch every time for frequent decision tasks such as, for example, scheduling decision tasks. In such a case the decision process can be triggered right after the download of a decision app. This reuse technique has the potential to reduce the entry barrier for using Choicla and keep the interaction simple { especially for people who want to start a decision process quickly. The tab Create DecisionApp allows a user to design a completely new decision app from scratch. Due to the fact that many decision tasks occur regularly { for example, a group of friends go for dinner once a month { a concept is needed to manage a potentially large number of decision tasks. To keep the potentially large number of decision tasks manageable, every decision app consists of a variable number of instances. A concrete instance of a decision app can be accessed within the corresponding decision app - all instances of a concrete decision app will be loaded when the decision app is opened. The created instance of the example depicted in Figure 1 is accessible in the "Personnel-decision" app (see Figure 2). This mechanism o ers the possibility of an exact documentation of all past decisions and is also a basis for supporting recurring decision tasks.
Personnel decisions are often in uenced by various factors. Such factors are, for example, if a candidate has physical handicaps, in most cases no concrete structure is followed during the job interview and the evaluation often To keep the screen understandable, only the line with the aggregated information of a candidate is visible - by clicking on this line, several dimensions including their actual ratings show up for the corresponding candidate (only visible for rst candidate in Figure 3). In order to avoid misunderstandings in context of evaluation the sliders of the rst candidate are automatically displayed if the screen is loaded. Due to the fact that depending on the advertised job position di erent assessment criteria are needed, the dimensions on which a candidate can be evaluated can be chosen by the creator of a decision task. If we look at the example in Figure 3 we can see that for the "New Receptionist" the dimensions English skills, Communication, Friendliness, and Punctuality are chosen.
In situations where there are candidates for whom not all
criteria (dimensions) have been evaluated or there exists a
discrepancy between individual evaluations, special
markers are used to point out open issues. This approach
creates need for closure (see, e.g., [
If a candidate should be excluded from the application procedure in early phases (e.g., some criteria are not met), this can be achieved by using the "Manage Candidates" button (a new menu shows up). The early exclusion of an unsuitable candidate supports more clarity since only the "relevant" candidates are displayed.
The tab Group Preference presents the current group
recommendation, after a prede ned number (the threshold) of
participants articulated their preferences. This threshold
prevents from statistical inferences to the individual
preferences of other participants (only in combination with a
"private" decision scope - see Section 2). The group
recommendation in context of personnel decisions is based on
the MAUT-principle (multi-attribute-utility-theory [
M AU T (s) =
X If we look at the individual ratings in Figure 3 we notice the values 8, 5, 8, and 5 for the dimensions. For simpli cation purposes we assume in our example that all dimensions have the same weight (wd1 = wd2 = wd3 = wd4 = 5). Due to Formula 3, the individual MAUT value for the actual user of the rst alternative is 32:5. To present the evaluation of a solution (candidate) within a ve star scale, these values have to be normed.
All previous described options and screens can only be accessed by the decision makers of the decision task itself and can of course not be seen by the applicants of the job position. During the design phase of a decision task the input elds (e.g., name, age, and application text) which are then visible by the applicants during the application process can be de ned. Figure 4 shows the view of an applicant in our running example "New Receptionist". All the added information of the candidates is then prepared and accessible for the decision makers during the assessment phase - see Figure 3. This way of adding solutions to a decision process shifts the burden of entering candidate information by a single person - in most cases a secretary - to the applicants.
There exist a couple of online tools supporting decision
scenarios. Rodriguez et al. [
Recommendation approaches in the line of Choicla are also
presented in Sangeetha et al. [
Our future work will focus on the analysis of further
application domains for the Choicla technologies. Our vision is to
make the design (implementation) of group decision tasks as
simple and straightforward as possible. The resulting
decision task should be easy to handle for users and make group
decisions in general more e cient. Our focus will also be
on the analysis of decision phenomena within the scope of
group decision processes. Phenomena such as decoy e ects
[
Biases can be induced if a system is open in the sense that
new decision alternatives can be added during the decision
process. However, such a feature is imperative in cases where
all possible decision alternatives are not available from the
beginning. The group preferences can also be in uenced by
the order of the incoming individual preferences due to the
fact that the participants of a group will perceive already
selected alternatives more attractive than new options [
If consensus out of discussion is reached in early phases,
literature shows that this consensus is cognitive resistant to
changes. That means that additional information which is
added later in a decision process will be adapted to already
de ned consensus and due to this it is very unlikely that
another alternative is chosen [
We want to emphasize that one of our major goals is to make the Choicla datasets available to the research community in an anonymized fashion for experimentation purposes.
In this paper we gave a short introduction to Choicla which supports the exible design and execution of di erent types of group decision tasks with a focus on personnel decisions. With the help of Choicla it is possible to achieve more transparent, fair, and structured personnel decisions. Compared to existing group decision support approaches, Choicla provides an end user modelling environment which supports an easy development and execution of group decision tasks. We also discussed further research directions which can help to extend the available functionality of the Choicla environment.