The application of knowledge-based consultation- and documentation systems is, apart from large industrial projects, often also bene cial for small to mid-sized enterprises. Yet, their design and implementation still is a tedious and costly task. We motivate, that customized UI and interaction patterns constitute a pragmatic technique for supporting especially requirements engineering, and thus are capable of considerably promoting real-world projects. In this paper, we introduce abstract categories|Guided-, Adaptive-, and Autonomous Entry | for classifying tailored patterns for knowledge-based systems. Further, we discuss their role in an overall approach extending the Agile Process Model and resulting bene ts.
Knowledge-based systems gained increasing impact also outside academia over the last decades. Apart from large clinical and industrial projects, the application of knowledge-based consultation and documentation systems is also often bene cial for small to mid-sized corporations. Yet, the trade-o between their potential bene ts and their mostly still tedious and costly development, is still often perceived as unfavorable, and respective projects are declined.
In general software engineering, user interface (UI) prototyping already is an
established methodology regarding iterative, rather inexpensive system speci
cation before the nal product is implemented [
As a rst step into this direction, this paper introduces Interaction Pattern
Categories, that provide an abstract classi cation framework for knowledge
systems and corresponding interaction/UI patterns. We further discuss the role of
such patterns within the proposed, extended agile approach; the details
regarding the prototyping and a respective tool are subject of separate work, see [
The rest of the paper is organized as follows: Related research is presented in Section 2. In Section 3, we introduce our classi cation framework of Interaction Pattern Categories and the relevant terminology. We further present three categories, identi ed on the basis of past experiences with conducted projects. In Section 4, we outline the extended, agile process model, and the patterns' speci c role as well as resulting bene ts. We conclude with a summary of the presented work and a discussion of future research directions in Section 5. 2
The process model for knowledge system development, that we suggest in this paper, integrates pattern- and prototyping-based development, thus uniting the advantages of both approaches and especially fostering an enhanced requirements engineering.
Patterns specify proven solutions for recurring (design) problems and are
established in many domains: Examples are software engineering, ontology
engineering, or knowledge formalization, [
Regarding knowledge system development, various methodologies have been
proposed in the past|see [
UI prototyping so far has become an established approach in general software
engineering [
By Interaction Patterns for Knowledge-Based Systems, we understand the description of the systems' interaction- and UI design for a speci ed context. They comprise a compact speci cation of their applicability, and exemplify the corresponding solution approach. Yet, there exist attributes, the value of which may be common to more than one distinct pattern. Thus, we rst introduce an abstract framework|Interaction Pattern Categories |for classifying patterns according to such common properties before specifying concrete patterns. In Section 3.1, we rst introduce relevant terminology, and in Section 3.2, we present the classifying categories|Guided-, Adaptive-, and Autonomous Entry. 3.1
In the following, we specify the addressed system types as well as the classifying attributes, that characterize the pattern categories, in more detail. Knowledge-Based Systems: We speci cally address knowledge-based systems with our approach|by that, we understand knowledge systems, that serve either a consultation or a documentation task. In both cases, the main usersystem interaction is structured data entry|mirrored by "Entry" in the pattern category names. Regarding consultation, the system gradually derives solutions for a given problem with the respective, implemented reasoning mechanisms based on the provided user input (answers). Documentation systems emphasize supporting uniform and reliable data input as e ectively as possible. Classifying Attributes: The attributes User Competence, Context Presentation, and Data Volume are common to all patterns of one category. Major classi er thereby is User Competence|in the context of knowledge-based systems, lengthy, strictly prescribed interviews can be annoying and in exible for competent users, that might want to in uence the interrogation ow according to their expertise. This makes it essential to tailor the system and interface design to the target users' competence.
A. User Competence : A naive data provider follows the prescribed interrogation sequence, with no desire for deviation or adaption; possible reasons can vary from rather low domain competence/lacking experience to a highly stressful usage context (but nevertheless domain expertise). Experienced users possess a certain domain expertise, and thus may be interested in system-suggested workow guidance, yet, additionally require the option to in uence the interrogation and to deviate from suggested paths. An autonomous problem solver nally possesses su cient expertise to solve the problem independent from system guidance, based on the (potentially various and complex) information presented.
B. Data Volume : The amount of data that is processed during a typical interrogation session; thus, it corresponds to the number and the complexity of questions required for deriving a solution or entering a complete data set. We roughly distinguish between small, medium, and large. Data Space, in contrast, speci es the universal range of possible input data, and thus corresponds to the domain complexity. The respective data volume/data space combination does not in uence the pattern categorization, yet the knowledge required for a speci c implementation|e.g., large data space and low data volume implies sophisticated interrogation structures to present appropriate questions e ciently.
C. Context Presentation : No context means, that during an interrogation, only the required questions are presented, but no further information. Otherwise, we distinguish support knowledge|auxiliary information (not interrogation speci c), or informal knowledge representations|and interrogation context |i.e., additional information regarding, e.g., the progression of the work ow, or indicating the consequences of choosing certain answer alternatives in advance. Type and extent of context presentation highly depend on the respective level of user competence|concerning naive data providers, interrogation context often is not required, yet for complex questions, support knowledge presentation might be advisable; with rising competence, the presentation of interrogation context gains importance for supporting an independent, e cient system usage. 3.2
Based on experiences from past projects, we de ne three basic categories for UI/interaction patterns: Guided-, Adaptive-, and Autonomous Entry. For each category, we describe the Problem Statement, the Solution, and the Applicability, specifying common properties that apply to all contained patterns. Further, we provide Examples |i.e., existing implementations|and Variants, that describe in what regard patterns of a category may vary.
The basic interaction specifying each pattern, regards question selection during interrogation. Even if patterns later vary, e.g., regarding the processed data volume, that basic interaction remains the same. For its speci cation we use the UML sequence diagram notation and the elements: User, the system Interface, Questions (presented to and answered by the user), the Data pool (storing data resulting from provided answers or reasoning), and the Knowledge component.
Problem Users act as naive data providers, thus for a reliable, e ective decisionor documentation support, a high level of system autonomy/guidance regarding the interrogation ow is required. Data volume might vary from small to medium. Solution An interview metaphor is transferred to the interface, where the user and the system interact alternately. The system exibly reacts to the provided answers by adapting the interrogation sequence, thus presenting only the question(s) that t the respective context best. The interview proceeds system-guided, and deviation is mostly not (or only in limited terms) intended. Thus, presenting interrogation context is not mandatory, even though regarding lengthy sequences status feedback may be bene cial. Contrastingly, support knowledge is required in the case of complex/di cult questions for clari cation. Figure 1 depicts the interaction sequence for Guided Entry. The interface initiInterface ates the question request, whereupon the knowledge component assesses the next question|where available, based on the previously provided user input stored in the data pool|and propagates the result back to the interface. The then provided answer of the user is propagated to the data component and thus made available for the knowledge component hereafter. Those steps are performed iteratively until a de ned interrogation sequence is nished.
Applicability Systems based on Guided Entry equally t consultation and
documentation tasks. Especially documentation of high quality or frequently
recurring data is supported, as speci ed data entry can be assured by the
strict, system-guided interrogation ow. However, if a higher level of user
autonomy is desired|e.g., in uence on the interrogation, or adaptable question
representation|Adaptive- or Autonomous Entry provide more exibility.
Examples Figure 2 presents two implementation variants of Guided Entry.
CareMate (A) is a quick response second-opinion system for emergency
situations. Its one-question interaction style creates the literal impression of an
interview and supports the intuitive usage in the context of stressful emergency
conditions. Continuous status feedback on the current solution states is provided,
and the processed data volume is rather small. For a more detailed introduction,
see [
Variants Pattern variants arise with regards to the type and extent of context presentation (see above examples), as well as regarding the characteristics of the naive user (e.g., expert in stressful context vs. non-expert's ad-hoc usage).
Problem Experienced target users have a certain|yet, from user to user potentially varying|domain competence; consequently, both system guidance as well as the option for autonomous decisions regarding the work ow are desired. Also, questions should be presented in a user-adaptable manner. Solution The system basically suggests the most appropriate work ow to the user; yet, also the option to deviate from that path and choose an adapted interrogation sequence is provided. Where applicable, a hierarchical tree metaphor is applied to cater with varying user competence levels: Questions are de ned both on an abstract (aggregate) level, but also subdivided into (several) re ned questions, where reasonable. Thus, according to their expertise, users may either answer the aggregate questions|taking less time, but requiring more expertise| or request the presentation of the questions' re nement. To support the user's decision-making, providing interrogation context is strongly recommended. Also, depending on the re nement level and complexity of the questions, support knowledge should be additionally presented.
Figure 3 sketches question selection in Adaptive Entry. Basically, the user decides whether to follow the system-guided interrogation or whether to choose an own path. Regarding the rst alternative, question selection proceeds as in Guided Entry (Figure 1). In the second case, either the user's competence allows for answering the currently displayed question; then the answer is propagated to the data pool and thus is available for the knowledge component as the interrogation continues. Otherwise, the user can request question re nement whereupon the knowledge component assesses the possible re nement, and propagates the result back to the interface for displaying it to the user.
Applicability Apart from consultation, respective systems can, with limitations, also serve documentation purposes. In that case, special care has to be taken that all required input data is obtained from the user. Regarding e ective interrogation of naive data providers Adaptive Entry is only marginally suitable. Examples Figure 4 shows the Labour Legislation Consultation, that clari es, whether a dismissal in a given context is legitimate. Figure 4, A, represents the problem statement. Its current derivation state and the questions' state (e.g., answered) are visually indicated by background coloring and updated with each provided answer. Questions can be processed either in the sequence suggested (i.e., from top to bottom), or in any other order. Further, adaptable question presentation is implemented|e.g., Figure 4, B, was con rmed on the abstract level; question Dismissal was... is expanded into re ned questions (Figure 4, C). Variants Possible variants originate from di erent forms of context presentation as well as from di erent data volumes that may be processed.
Problem Target users are highly competent, autonomous problem solvers, thus no explicit guidance regarding the interrogation sequence is required. Solution The user explores the (various and potentially complex) information sources presented by the system. Integrated knowledge-based components|e.g., consultation features or automated data entry support|can be used optionally, but are not mandatory to bene t from system usage. The user provides any input data voluntarily; based on those data fragments, the system performs rather modularized reasoning, following sort of a bits and pieces metaphor. Thus, the system merely provides a second-opinion to the user in presenting reasoning results (e.g., rated solutions, next-input suggestions). Such extensive user control requires a high level of context presentation, regarding both types of context.
Interface
Question
Data
Knowledge loop alt [Use support features (consultation/data enty) ] [Exploration] alt explore() answerSelected
Question()
As Figure 5 shows, the user always can choose between using more formal
knowledge components and free exploration. In the rst case, potentially any
kind of (complex) knowledge component can be integrated into such a system,
e.g., according to the Guided Entry or Adaptive Entry categories. Otherwise,
the user can either simply explore the provided information, or answer questions
autonomously in a modularized manner. Answers then are propagated to the
data component, and from there assessed by the knowledge component; the
latter rates solutions, presents context, and recommends next steps piecemeal.
Applicability Autonomous Entry can be applied for loose consultation, as well
as regarding a more informal, potentially collaborative documentation task. In
contrast, it is inappropriate, if rather naive data entry is desired, as no strict
work ow guidance for solving the addressed problem is provided. Further it is
not suitable for high quality documentation tasks, as any interaction takes place
voluntarily, and thus the supply of any data cannot be guaranteed.
Examples Implementation examples are the user-centered consultation
approach described in [
Variants Implementation variants arise with respect to the data volume, and the type and extent of context presentation. Despite mainly addressing expert users, systems falling into this category, might to some extent also be suitable for unexperienced ad-hoc usage. Finally, resulting systems can vary regarding the extent of integrating knowledge-based features.
The proposed pattern categories classify basic knowledge system types and corresponding UI/interaction design patterns according to the level of user competence (corresponding to the level of system guidance). Ongoing research addresses the de nition of concrete patterns and their categorization accordingly. We proceed by discussing how such patterns can be integrated in an extended, agile process model for developing knowledge-based consultation and documentation systems. 4
Regarding knowledge system development and knowledge engineering, there
exist diverse approaches today, such as CommonKADS, MIKE, or adaptions of
the classical stage-based and incremental software development models. Yet, for
the success of knowledge system projects in the context of small to mid-sized
companies, a pragmatic approach|a ordable and e cient regarding time and
e ort|is essential, c.f. [
In the following, we introduce the Extended Agile Process Model, and
afterwards we discuss resulting bene ts speci cally regarding the integration of
tailored UI/interaction patterns. Although prototyping and usability-related
activities are included in the model for reasons of completeness, their detailed
discussion is part of further work, see [
Basically, tailored patterns and pSryostteomtypMingetapchaonr saunpdpoPrtlanbnointhg MSeytsatpehmor PTatatielronrsed& Game. In System Metaphor, the Prototypes system objectives are de ned by Planning developers and customers. Based Game on appropriate patterns and cor- UA2: Prod. System, UA1: Prototype responding implementation exam- User-based / Hybrid Expert / Hybrid ples, a basic idea can be devel- Integration Implementation oped more easily. Thereby, patterns can be assessed either manually, or by using a tailored recom- Fig. 6. Extended Agile Process Model. mender system, that suggests patterns matching the target context.
Prototypes, that also provide the relevant user-system interactions, further support that process by presenting a realistic simulation of a potentially resulting system as opposed to the static, visual depiction of knowledge system examples provided by the patterns. The Planning Game de nes the scope and prioritization of development tasks. Here, patterns ease the analysis and valuation of system requirements|taking place during the Exploration sub-phase of the planning game|by providing clear speci cations of required features and interactions. Additionally, prototyping supports that task by allowing for actually trying out (and thus better evaluating) relevant functionalities.
With regards to Usability Activities, the original model can be extended
both regarding Implementation and Integration (Figure 6, UA1, UA2). The
basic model de nes Implementation as a test- rst activity|i.e., before actually
implementing new or additional features, the corresponding tests for assuring
their correctness are developed. This can be expanded by an evaluation- rst
activity, in the sense that based on the formerly created prototypes, usability issues
are assessed and valued rst, before continuing with test- rst implementation as
de ned by the model. Without going into detail here, at that stage, expert- or
hybrid approaches (according to a categorization suggested in [
We motivated that tailored patterns can constitute the cornerstone of an
extended, agile model for knowledge system development. Especially when
targeting smaller to mid-sized companies as customers, the suggested approach is a
rather inexpensive, pragmatic technique for promoting and launching respective
projects. As a rst step, in this paper we introduced three abstract categories for
classifying corresponding patterns. Due to our focus on knowledge-based
consultation and documentation systems, those categories speci cally address the data
entry task; yet, the elementary classi cation|guided, adaptive, and autonomous
interaction might be applied accordingly for other forms of interaction. The
categorization arose from practical experiences with implementing knowledge-based
systems in the past, such as SonoConsult [