It is has been a while since I blogged. So I will break down what I have been up to over a few blog entries. This particular blog will focus on the overall picture of my work.

My work is underpinned by a need to have an architecture that is flexible and standard based for supporting development of IVR (Interactive Voice Response) applications. As it stands, despite providing unsatisfying user experience in the past, IVR technologies are still seen as pivotal in realising a new generation of self-service voice systems. There are a number of reasons for this including the fact that telephones and mobile phones are ubiquitous (just go to http://www.ametw.com/ and download the Africa Mobile Factbook for statistics on the mobile phones penetration in Africa). This means that there is, for example, a strong “market” for IVR applications – not just in the commercial sense but also for use in supporting social innovation 😉 .

With the above providing part of the motivation, the goal is to use IVR technologies (specifically VoiceXML) to propose an architecture for building IVR systems with high configurable dialogs to improve user experience. The premise is that the effort to customise (configure) each dialog to suit each users’ goals will bring intelligence to IVR systems – a component that is possibly a source of much user frustration.

In a nutshell, the proposed architecture builds IVR systems by generating dialogs using VoiceXML and a rich backend. The backend comprises of a specially built interface that allows a reasoner to interact with any ontology-based knowledge base in order to generate dialogs. In the context of AI, the interface can be regarded as some sort of an inference engine.

Architectural Design Considerations

An overarching consideration is to ensure that the architecture is flexible. Another important consideration is to ensure that the generated dialogs do not violate any principles of user interface design. This translates into ensuring that:

• Menu options do not exceed five options. Otherwise this is will result in an overload on the short-term memory of the user. Consequently, the user will have problems remembering the presented options.

• Break content into small chucks to enhance memorability by introducing rhetorical questions or using quiz type questions. However, the number of dialogs generated should be kept at a minimum.

Case Study: Service Directory for Locating HIV Test Providers

As part of the methodology, a case study is included to act as a proof of concept for validating the proposed architecture. This proof of concept case study is a service directory for locating HIV test providers.

The case study is built from a service provider ontology, which together with individual facts about specific service providers forms a knowledge base. This is strictly in the context of defining a knowledge base as an entity made up of a terminological box (TBox) and an assertional box (ABox). In simple terms, TBox refers to the definitions of various concepts and how they relate to each other within an ontology while ABox refers to the individual facts associated with the definitions in the TBox.

Below is a quote from good old Wiki to provide another angle to the definitions of TBox and ABox:

Tbox statements are sometimes associated with object-oriented classes and Abox statements associated with instances of those classes.