1. Introduction
This paper present an analysis of dialogue management in the Waxholm system. The analysis is presented in the form of (a) a `grid' which describes the system's properties with particular emphasis on dialogue management and evaluation results, (b) a life-cycle model which provides a structured description of the system's development and evaluation process, and (c) supporting material, such as system architecture, example screen shots, dialogues and scenarios.
The presented information will be cross-checked with the developers of Waxholm as well as with the complementary descriptions of other aspects of Waxholm provided by the DISC partners. These other descriptions address language understanding, done by LIMSI, speech generation, done by LIMSI, dialogue management, done by IMS, human factors, done by Vocalis, system integration, done by Vocalis.
Demonstrator: Available in Stockholm
Developer: KTH
Contact: Rolf
Carlson, Inger Karlsson
System/component identifier The Waxholm system is a research prototype of a multimodal interactive
speech system for information on boat traffic in the Stockholm archipelago. | |
| System performance | |
| Cooperativity | The system is intended to be cooperative. When problems were observed in user-system interaction an effort was made to repair the problems. However, cooperativity has not been a focal point and the design of system utterances has not been analysed and evaluated in any detail. |
| Initiative | Domain communication: User initiative complemented
by system questions when necessary. User initiative works as long as user
utterances address the domain covered by the system and as long as the user
does not use a complex sentence structure. Conditional sentences, for instance,
are not understood. The overall initiative distribution seems appropriate
for the task(s). However, no measurements or evaluations of user and system
initiative have been done except for counting number of utterances with
user and system intitiative, respectively. Meta-communication: Both the system and the user may initiate meta-communication. The system may inform the user that it did not understand what was said or it may inform the user that the topic the user is talking about is outside the domain handled by the system. Users may initiate repair, e.g. by saying `no, I said Waxholm, not Stockholm'. Users may ask for repetition. Clarification, for instance of ambiguities, is not being handled by the system. The meta-communication functionality has not been evaluated in any systematic way. |
| Influencing users | Walk-up-and-use system. Users receive a text introduction to the system on the screen, which is also presented in synthetic speech (slow). It is possible to by-pass the spoken introduction (and thereby also move away from the written introduction) by pressing a button. In what ways is the introduction intended to influence users - wrt. vocabulary, grammar, utterance length, style etc.? Any important limitations here (e.g. lack of control of aspects of user behaviour which should be controlled)? |
| Real-time | According to the developers the system should be able to respond in real time. During the demonstration it was slow, apparently due to an overloaded network. However, database look-ups seem to take quite some time. The recogniser runs in real-time with a delay of perhaps one second from time to time. Graphics takes time and so does synthesis. To make the user aware that something is happening the talking face will say "hmmm" and then "I'm looking for ...". No exact measurements on the individual system components have been made. |
| Transaction success | Transaction success was defined as whether the user did get what s/he asked for. Some scenarios were designed so that they could not be solved. In these cases dialogues would count as transaction successes if the user found an optimal solution taking into account that the task in itself was not solvable. An example could be the task of obtaining information on how to get to an island that has no ferry connection. In that case an optimal solution would be to get information on how to go to the nearest island. Users were encouraged to continue interaction with the system after they had carried out their scenarios. These parts of the dialogues were not counted as transaction successes/failures. In a number of cases it was too difficult to tell if the user got what s/he wanted. No analysis was made to decide whether this was due to a flawed definition of `transaction success' or to a conceptual problem with the concept of `transaction success' itself. |
| General evaluation | No ISO standards other other general methods used. |
| Speech input | |
| Nature | Continuous; spontaneous; speaker-independent; Swedish. The nature of the speech input is appropriate to the task(s). |
| Device(s) | Microphone. A high-quality microphone was used during the WOZ experiments. For the demonstration a medium-quality microphone was used. Deployment appropriateness cannot be evaluated. |
| Phone server | No |
| Acoustic models | Based on neural networks (one output for each of the 40 Swedish phonemes used in the lexicon). |
| Search | A* N-best search. Viterbi search starts when the user starts talking. |
| Vocabulary | Approx. 1000 words. All words are active at any one time. |
| Barge-in | The system does not listen when it speaks. No measurement was made of the potential problems caused by that. However, barge-in by pressing a button to stop the synthetic speech is allowed at any time during interaction. |
| Word hypotheses | The recogniser typically [what does this mean?] produces an N-best list of 10 hypotheses. Recogniser score values are not used in the parsing. |
| Grammar | Simple bigram language model. |
| Prosody | The system does not process input prosody. |
| Speech output | |
| Device(s) | Loudspeaker. |
| Language(s) | Swedish. |
| Input | Text strings. |
| Lexicon | Do you use a lexicon? How big? |
| Sound generation technique | Parametric speech; formant-based. Quality has not been measured in the Waxholm project. Different voice characters (e.g. male/female) are not being used. |
| Prosody | Prosodic modelling. Grapheme to phoneme rules used in synthesis. |
| Pronunciation description units | - |
| Flexibility | - |
| Miscellaneous | - |
| User utterances | |
| Lexicon | Approx. 1000 words in the top-level lexicon. The
parser uses a sub-lexicon. [Size?] Based on one word in the top lexicon
there may be, e.g., six different meanings of this word in the sub-lexicon.
Lexical coverage has not been measured (see also on vocabulary above). Each lexical entry can have domain specific semantic features associated with it in addition to the basic syntactic features. Semantic features are of two types: basic features (e.g. BOAT, PORT) and function features which are typically associated with an action (e.g. TO_PLACE). |
| Grammar | Context-free grammar compiled into an ATN with probabilities assigned to each arc. |
| Parsing | The STINA parser is based on MIT's TINA parser. The
syntactic tree is reduced to a semantic tree through deletion of all nodes
and branches that contain no semantic information. Then a special process
creates a semantic frame with slots corresponding to attribute-value information
taken from the tree. The semantic frame has a feature specification describing
which features are used in the frame and which information might have been
added to the frame from the dialogue history. The N-best list of hypotheses is re-sorted by the parser. Robust (skip nodes) and complete solutions compete all the time. In case of lack of understanding the user may be asked to provide a full sentence as input which will then be given a complete parse. All words and grammar used by the system can be parsed. |
| Style | Different user styles were observed in the experiments. |
| Semantics | See parsing above. |
| Discourse, context | - |
| System utterances | |
| Generation | Generation of system utterances is done as part of dialogue management. A hierarchical structure where slots are filled in is used for generation. Everything is hardwired. Only slot values vary. |
| Lexicon | Lexical information is shared with the recognition module. |
| Grammar | There is no grammar. |
| Semantics | There is no semantics. |
| Style | Terse [True?] |
| Processing | - |
| Discourse, context | - |
| Multimodal aspects | |
| Device(s) | The input device is a button. The output device is a screen. [How large?] |
| None (unimodal system) | No. |
| Non-speech input | In addition to speech, the system accepts input from a button which can be pressed (simple haptic notation). You have to press the button while you speak. The button is also used to by-pass the spoken introduction (and thereby also move away from the written introduction). |
| Non-speech output | Static graphics output: pictures, maps, charts [you simply mean lists of items?], time tables displayed on screen; synthetic face; speech recognition feedback (text). The graphics output cannot be scrolled by the user. |
| Role(s) | Output speech/facial: Lip movements synchronised with output speech, generated by the same algorithm. The head turns in order to "point" to new information displayed on the screen. The head will ask questions and react to user input. When information is displayed on the screen the face will briefly tell what you see. |
| Attentional state | |
| Focus, prior | The interaction model is a kind of graph structure and the focus is the point in the graph currently being addressed. However, this knowledge is only used for generating appropriate system output. There is no use of prior system focus (i.e. what the system has in active memory before the user's next utterance). |
| Sub-task identification | Sub-task identification is based on probabilities. A matrix of topics and features is being used. This matrix expresses, e.g., the probability of talking about restaurants if the word `food' is found in the input. Each semantic feature found in the syntactic and semantic analysis of user input is considered in the form of a conditional probability to decide on the topic. The probability for each topic is expressed as p(topic|F), where F is a feature vector including all semantic features used in the utterance. The system can only handle one topic at a time. Please note that this does not exclude response packages. Test on limited user data during WOZ yielded 12.9% topic recognition failure. |
| Expectations | Not used. |
| Intentional structure | |
| Task(s) | Information on boat timetables, port locations, hotels,
camping grounds and restaurants in the Stockholm archipelago. The user may
achieve departure and arrival times for boats, get a map displayed with
the place of interest, get an overview of lodging and dining possibilities,
get a presentation of possibilities for where to go. [Is this true of
all boats, port locations, hotels, camping grounds and restaurants in the
Stockholm archipelago - or did the developers only include examples?] Adjacent tasks, such as price information and more specialised knowledge on, e.g., types of restaurants are not included. Also no booking tasks are included. In the WOZ experiments it was observed that people (when not carrying out the scenarios) often asked booking questions or asked for information at a more detailed level than what the system can provide, e.g. they might ask for menus or for a certain type of restaurant, e.g. fish restaurants. This problem is evidence that the task(s) handled by the system were not naturally circumscribed or that the users were not suitably informed of the system's task coverage. |
| Task complexity | The task is ill-structured in the sense that there are several different pieces of information which the user may or may not ask for and there is no particular order which s/he has to follow. The number of slots to be filled vary from sub-task to sub-task. For instance, the user may want to see a map. In that case there is only one slot to fill. On the other hand, if the user wants departure times the system must know departure and arrival port, date and in some cases a time interval. If a table contains more than seven lines of information, the table is not displayed. Instead the system asks a question in order to get more precise information and thus being able to throw away irrelevant information from the table. |
| Communication | Domain communication: Mixed initiative. The topic
order is free but only one topic at a time can be handled by the system.
Moreover, complex sentence structure cannot be handled. This
basically means that the user has to express himself in main clauses. Natural
response packages are allowed. Note that a crucial part of the system's
domain communication is done graphically. System-initiated meta-communication: The system may ask for repetition and initiate repair meta-communication in case of missing understanding of user input (e.g. by asking for reformulation) or user input out of the system's domain. The system's vocabulary includes words from adjacent domains. This enables the system to tell the user, e.g., that is does not handle reservations rather than saying that it does not understand the user. Does the system initiate clarification dialogues with users? When? How? What about ambiguous, inconsistent etc. user input? User-initiated meta-communication: Users may ask for repetition of the system's speech output. Users may initiate repair, e.g. by saying `no, I said Waxholm, not Stockholm'. The user cannot initiate clarification dialogues with the system. Problems: Does the system have specific problems as a result of how it communicates about the domain and about the communication? Characterise the problems. What have the developers done to analyse the problems? |
| Interaction level | Most system questions are general and focused because they serve to elicit specific missing information items from the user. In case of understanding problems of a user answer to a system question the system requests a complete sentence from the user. The system thus has two interaction levels. What happens in case of repeated failure to understand the user - must the user simply give up? Does the system have specific problems as a result of its level(s) of communication? What have the developers done to analyse the problems? |
| Implementation of dialogue management | The dialogue component is controlled by hand-crafted context free rules which control all steps in the dialogue including database search, speech and face synthesis, and other graphical feedback. Each step in the dialogue progress is associated to a new frame, with reference pointers to the history. The information that should be pushed forward is defined by semantic feature specifications in the dialogue rules. Each predicted dialogue topic is explored according to a set of rules. These rules define which constraints have to be fulfilled and what action should be taken depending on the dialogue history. A node can be a terminal node or the entry point to a network. In the case of a terminal, several node specific characteristics have to be defined in the rule system. These can be divided into three basic groups: constraint evaluation, system questions and system actions. The constraint evaluation is described in terms of features and in terms of the content in the semantic frame. If the frame needs to be expanded with additional information, a system question is synthesised. A positive response from the constraint evaluation opens the way for the selected action to take place, such as a database search or a graphic presentation of a map or a table. Most of the terminal nodes have no direct input from the user. Rather they deal with small details such as making the synthesis face look at a graphic object on the screen or to simply synthesise a message to the user. Thus, the dialogue rules do not only model turns in an oral dialogue, they cover all actions in the dialogue system. The expanded grammar notation makes it possible to separate the dialogue model from the system implementation. |
| Linguistic structure | |
| Speech acts | The system does not identify speech acts in the users' input. |
| Discourse particles | The system does not identify discourse particles in the users' input. |
| Co-reference | No co-reference resolution is performed. No problems have been observed as a result of this. No particular evaluation has been performed. |
| Ellipses | The system does not do any particular processing of ellipses. Incomplete sentences are allowed and ellipses are handled as such sentences. No problems have been observed. No particular evaluation has been performed. |
| Segmentation | No segmentation of user utterances is performed. No problems have been observed as a result of this. No particular evaluation has been performed. |
| Interaction history | |
| Linguistic | The system maintains a record of the surface language of the users' utterances. However, the record is not being used for anything. No particular evaluation has been performed. |
| Topic | Each utterance is transformed into a semantic frame with attribute-value pairs. The time sequence of these frames is the history. Does the system maintain a time-annotated frame series? A feature specification in the dialogue model tells what attributes to carry further and to keep in current use. Inside the time-table topic, for example, attributes corresponding to arrival port and so on are of interest, while other attributes are of interest to other topics. No particular evaluation has been performed. |
| Task | Graphical overview of the knowledge the user has received so far, in the form of listings of hotels and so on. Is the task history = what is presented on the screen? If the user goes from a time-table topic to a hotel topic, does (a) the time-table topic get removed from the screen? Or (b) does the provided information accumulate on the screen so that is only becomes removed when the user (b1) shifts to a different boat route or (b2) closes the dialogue? When graphical information is removed from the screen, does the system forget about it? |
| Performance | The system does not maintain a record of the user's performance during interaction. No particular evaluation has been performed. |
| Domain model | |
| Data | Boat timetables, port locations, hotels, camping grounds and restaurants in the Stockholm archipelago. The information is accessed through SQL queries to an ORACLE database. Is the data artificially limited or fully realistic (e.g. all boats, all ports?). |
| Rules | The system will understand utterances that require temporal inference, such as "next Sunday before noon". Expressions such as 'first' or 'closest' or 'cheapest' are not being handled. The rules included are ad hoc rather than based on any systematic approach. No detailed evaluation of the rules has been carried out. |
| User model | |
| Goals | The user goal is assumed to be to obtain information on boat timetables, port locations, hotels, camping grounds and/or restaurants in the Stockholm archipelago. |
| Beliefs | The system does not specifically handle user beliefs during interaction. |
| Preferences | The system does not specifically handle user preferences during interaction. |
| User group | Any user; no distinction between user groups. No problems were observed as a consequence of this. |
| Cognition | Nothing has been done to explicitly take into account the specific cognitive characteristics of users, such as task load, limited memory, or limited attention span. However, it has been a goal the interaction with the system should be smooth. Hence, e.g., natural "response packages" are allowed and timetable information is listed on the screen rather than only read aloud. |
| Component architexture and function | |
| Generic architecture | - |
| Sub-components | The dialogue is described as a network. Different nodes have different functions, such as to synthesise an utterance. In this case an utterance frame with slots is described as part of the node description. The slots are filled with the help attribute names. An attribute can also be described with a frame, thus making the whole process recursive. |
| Flow | See Figure 2. The dialogue manager receives input from the linguistic part (grammar and semantics), interacts with the database and sends output to the output modules (graphics, synthesis and sound). Syntactic nodes and dialogue states are processed according to transition networks with probabilities on each arc. |
| Function | The dialogue manager is the control part of the system. |
| Architecture | |
| Platform | The system runs on HP UNIX OS 10. The platform is
still adequate according to today's standards. The system runs on HP UNIX OS 10. No particular platform was used. The architecture is shown in Figure 2. The architecture is event-based. |
| Tools and methods | - |
| Generic | The generic software architecture seems to be event-based. The generic software architecture is still adequate according to today's standards. |
| No. components | See the architecture diagram in Figure 2. Can we give a number? |
| Flow | See the architecture diagram in Figure 2. |
| Processing times | No information is available about the average percentages of processing time spent on the different processing tasks the system has. |
| System integration | |
| System resource utilisation | - |
| Shared information resources | - |
| Interactions | - |
| Data passing | - |
| It's a beautiful summer day and you are in Stockholm. You decide that you'd like to go to Waxholm. Your task is to find out when the boats leave for Waxholm this evening. |
Figure 1. Scenario 1 used for all WOZ subjects.
System/component architecture
Figure 2. The modules in the Waxholm system.
System dialogue(s)
6 February 1998
U: jag vill åka till Vaxholm
S: Var ifrån vill du åka
U: Stockholm.
S: vilken veckodag vill du åka
U: jag vill åka på lördagen
S: det finns många båtar som går från stockholm till vaxholm på en lördag . när vill du åka.
U: jag vill åka på kvällen
S: detta är en tabell över de båtar som går från stockholm till vaxholm på en lördag efter klockan 17 och före klockan 24
U: var ligger som
S: Jag förstår inte
U: var är det Vaxholm
S: vaxholm finns på denna karta
U: finns det en Vaxholm
S: vaxholm finns på denna karta
U: finns det restaurang i Vaxholm
S: information om vaxholm restauranger visas i tabellen
Du talar för starkt. Kan du repetera.
U: vilken båt är samma morgon
S: Vad letar du efter.
U: finns
S: Jag förstod inte. Jag kom så här långt. finns . Kan du formulera om dig. Jag förstår inte. Vad letar du efter.
S: Jag förstår inte
U: jag letar efter sista stan
S: stockholm sista finns på denna karta
U: nu sista sedan
S: Jag förstår inte
U: jag letar sista
S: Jag förstår inte
U: ka söndag hem
S: Jag förstår inte
U: var kostar båten
S: Vad letar du efter
U: jag vill åka till Sandhamn
S: jag söker båtar som går till sandhamn
S: Var ifrån vill du åka.
U: finns det den
S: Jag förstår inte.
U: finns det hotellen
S: information om hotell visas i tabellen
U: tack
S: Tack ska du ha.
21 October 1993
S: Tack för att du vill delta i det här experimentet. Du kommer att få genomföra ett antal uppgifter, som gäller båt-trafik med mera i Stock-olms SJÄRGÅD. Du talar till datorn och datorn ger svar. Ibland går det litet långsamt och då får du vänta. Din röst kommer att spelas in. Tryck på start, med hjälp av musen innan du börjar tala och håll den intryckt så länge du talar. Då det står, "VÄNTA", i rutan måste du vänta.
S: För att göra dig bekant med inspelningsproceduren kommer datorn att be dig säga ett antal saker. Om du inte vill säga ditt eget namn kan du välja något annat. Tryck på knappen för att spela in. Släpp knappen för att avsluta inspelningen.
S: Var så god att börja. Tryck på knappen för att spela in.
S: Kan du repetera.
S: Du befinner dig i Stockholm en vacker SÅMARhyD'A:G. Du bestämmer dig för att åka till Waxholm. Din uppgift är att TA reda på när båtarna går dit i kväll.
S: Var så god att börja. Tryck på knappen för att spela in.
U: jag vill åka till vaxholm ikväll .
S: MMMMM Var ifrån vill du åka.
U: från stockholm .
S: MMMMM vilken veckodag vill du åka.
U: på torsdag .
S: Programmet söker nu i databasen .
S: detta är en tabell över de båtar som går från stockholm till vaxholm på en torsdag .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL VAXHOLM PÅ TORSDAGAR :
BÅT AVGÅNG ANKOMST AVG.HAMN
SKARPÖ 17.30 18.40 STRÖMKAJEN
NORRSKÄR 18.30 19.45 STRÖMKAJEN
S: Vad vill du nu veta.
U: när kan man åka hem .
S: Jag förstår inte.
U: när går båtarna tillbaka till stockholm .
S: Programmet söker nu i databasen .
S: det finns inga båtar som går från stockholm till stockholm på en torsdag .
U: när går båtarna från vaxholm till stockholm på torsdag kväll .
S: Programmet söker nu i databasen .
S: Det finns många båtar, som går från vaxholm till stockholm på en torsdag. När vill du åka på dagen?
U: på kvällen .
S: Vänta, jag letar nu.
S: detta är en tabell över de båtar som går från vaxholm till stockholm på en torsdag .
FÖLJANDE BÅTAR GÅR FRÅN VAXHOLM TILL STOCKHOLM PÅ TORSDAGAR :
BÅT AVGÅNG ANKOMST ANK.HAMN
VÄDDÖ 17.55 18.50 STRÖMKAJEN
SJÖBRIS 18.00 18.45 NYBROKAJEN
VÄSTAN 18.55 20.10 STRÖMKAJEN
WAXHOLMII 19.45 20.55 STRÖMKAJEN
NORRSKÄR 20.30 21.40 STRÖMKAJEN
VÄRMDÖ 20.45 21.30 STRÖMKAJEN
STORSKÄR 21.00 22.10 STRÖMKAJEN
VÅNÖ 21.10 21.55 STRÖMKAJEN
S: Vad vill du nu veta.
U: tack nu räcker det .
S: Du vill åka ut i skärgården under helgen. För att ha det bekvämt vill du bo på hotell. Du slutar klockan 15 på fredagen och börjar klockan 10 på måndagen. Ta reda på var man kan bo och när du kan åka.
S: Var så god att börja. Tryck på knappen för att spela in.
U: var finns det hotell i skärgården .
S: Informationen om hotell visas i tabellen .
FÖLJANDE HAMNAR HAR HOTELL:
DALARÖ
FURUSUND
GRUVBRYGGAN
NORRALAGNÖ
NORRTÄLJE
NYNÄSHAMN
SALTSJÖBADEN
SANDHAMN
STAVSNÄS
VAXHOLM
VÄSBYSTRAND
U: var ligger saltsjöbaden .
S: saltsjöbaden finns på denna karta .
U: när går båtarna från stockholm till saltsjöbaden på fredag kväll .
S: Programmet söker nu i data-basen .
S: detta är en tabell över de båtar som går från stockholm till saltsjöbaden på en fredag .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL SALTSJÖBADEN PÅ FREDAGAR :
BÅT AVGÅNG ANKOMST AVG.HAMN
ROSLAGEN 8.40 9.40 STRÖMKAJEN
ÖSTAN 11.00 12.00 STRÖMKAJEN
ÖSTAN 16.45 17.45 STRÖMKAJEN
S: Vad vill du nu veta.
U: kan man åka tillbaka på måndag morgon .
S: Programmet söker nu i data-basen .
S: detta är en tabell över de båtar som går från
stockholm till saltsjöbaden på en måndag .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL SALTSJÖBADEN PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST AVG.HAMN
SKÄRGÅRDEN 8.40 9.40 STRÖMKAJEN
S: Vad vill du nu veta.
U: jag vill åka i andra riktningen .
S: Programmet söker nu i data-basen .
S: detta är en tabell över de båtar som går från
stockholm till saltsjöbaden på en måndag .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL SALTSJÖBADEN PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST AVG.HAMN
SKÄRGÅRDEN 8.40 9.40 STRÖMKAJEN
S: Vad vill du nu veta.
U: när går båtarna från saltsjöbaden till stockholm på måndag morgon .
S: Programmet söker nu i data-basen .
S: detta är en tabell över de båtar som går från saltsjöbaden till stockholm på en måndag .
FÖLJANDE BÅTAR GÅR FRÅN SALTSJÖBADEN TILL STOCKHOLM PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST ANK.HAMN
SKÄRGÅRDEN 19.00 20.00 STRÖMKAJEN
S: Vad vill du nu veta.
U: när går båtarna på söndag .
S: Programmet söker nu i data-basen .
S: detta är en tabell över de båtar som går från saltsjöbaden till stockholm på en söndag .
FÖLJANDE BÅTAR GÅR FRÅN SALTSJÖBADEN TILL STOCKHOLM PÅ SÖNDAGAR :
BÅT AVGÅNG ANKOMST ANK.HAMN
SKÄRGÅRDEN 20.15 21.15 STRÖMKAJEN
S: Vad vill du nu veta.
U: ja tack det räcker för den här gången .
S: Du befinner dig i Vaxholm och vill åka till Vega-bryggan. Det är tisdag och du vill åka efter lunch. Din uppgift är att ta reda på vilka båtar du kan ta.
S: Var så god att börja. Tryck på knappen för att spela in.
U: hur kommer man från vaxholm till vegabryggan idag .
S: Programmet söker nu i data-basen .
S: detta är en tabell över de båtar som går från vaxholm till vegabryggan på en torsdag .
FÖLJANDE BÅTAR GÅR FRÅN VAXHOLM TILL VEGABRYGGAN PÅ TORSDAGAR :
BÅT AVGÅNG ANKOMST
SKARPÖ 10.00 (10.15)
STORSKÄR 13.10 (13.30)
SKARPÖ 14.25 (14.45)
SILVERÖ 16.15 (17.20)
ÖSTAN 16.55 (17.20)
SILVERÖ 18.05 (18.20)
SKARPÖ 18.40 (19.10)
S: Vad vill du nu veta.
U: jag vill åka på tisdag .
S: Programmet söker nu i data-basen .
S: detta är en tabell över de båtar som går från vaxholm till vegabryggan på en tisdag .
FÖLJANDE BÅTAR GÅR FRÅN VAXHOLM TILL VEGABRYGGAN PÅ TISDAGAR :
BÅT AVGÅNG ANKOMST
SKARPÖ 10.00 (10.15)
STORSKÄR 13.10 (13.30)
SKARPÖ 14.25 (14.45)
SILVERÖ 16.15 (17.20)
ÖSTAN 16.55 (17.20)
SILVERÖ 18.05 (18.20)
SKARPÖ 18.40 (19.10)
S: Vad vill du nu veta.
U: ja det var allt jag ville veta tack ska ni ha .
28 February 1994
S: Tack för att du vill delta i det här experimentet. Du kommer att genomföra ett antal uppgifter, som gäller båt-trafik med mera i Stock-olms SJÄRGåD. Du talar till datorn och datorn ger svar. Ibland går det litet långsamt och då får du vänta. Din röst kommer att spelas in. Tryck på start, med hjälp av musen innan du börjar tala och håll den intryckt så länge du talar. Då det står, "VÄNTA", i rutan måste du vänta. För att göra dig bekant med inspelningsproceduren kommer datorn att be dig säga ett antal saker. Om du inte vill säga ditt eget namn kan du välja något annat.
S: Tryck på knappen för att spela in. Släpp knappen för att avsluta inspelningen.
S: Var så god att börja. Tryck på knappen för att spela in.
S: Kan du repetera.
S: Du befinner dig i Stockholm en vacker SÅMARhyD'A:G. Du bestämmer dig för att åka till Waxholm. Din uppgift är att TA reda på när båtarna går dit i kväll.
S: Var så god att börja. Tryck på knappen för att spela in.
U: när går båtarna till stockholm ikväll .
S: Var ifrån vill du åka.
U: från stockholm .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL STOCKHOLM PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST AVG.HAMN ANK.HAMN
ÖSTAN 16.00 (16.00) STRÖMKAJEN SLUSSEN
ROSLAGEN 17.00 (17.00) STRÖMKAJEN SLUSSEN
ROSLAGEN ( 6.50) 7.45 SLUSSEN STRÖMKAJEN
VÄDDÖ ( 7.10) 7.40 SLUSSEN STRÖMKAJEN
ÖSTAN ( 7.15) 7.50 SLUSSEN STRÖMKAJEN
ROSLAGEN ( 7.30) 8.25 SLUSSEN STRÖMKAJEN
S: detta är en tabell över de båtar som går från stockholm till stockholm på en måndag .
U: vilka båtar går efter 17 .
S: det finns inga båtar som går från stockholm till stockholm på en måndag efter klockan 17 .
U: jag vill åka till vaxholm istället .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL VAXHOLM PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST
SKARPÖ 17.30 18.40
NORRSKÄR 18.30 19.45
S: detta är en tabell över de båtar som går från
stockholm till vaxholm på en måndag efter klockan 17.
U: jag vill åka den snabbaste båten dit .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL VAXHOLM PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST
SKARPÖ 17.30 18.40
NORRSKÄR 18.30 19.45
S: detta är en tabell över de båtar som går från stockholm till vaxholm på en måndag efter klockan 17.
U: jag åker med skarpö .
S: FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL VAXHOLM PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST
SKARPÖ 17.30 18.40
NORRSKÄR 18.30 19.45
S: detta är en tabell över de båtar som går från stockholm till vaxholm på en måndag efter klockan 17 .
U: då åker jag med skarpö avgång 17 och 30 .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL VAXHOLM PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST
SKARPÖ 17.30 18.40
NORRSKÄR 18.30 19.45
S: detta är en tabell över de båtar som går från stockholm till vaxholm på en måndag efter klockan 17 .
U: tack .
S: Tack ska du ha.
S: Hitta på en destination och ta reda på om det går att ta sig dit. Ta även reda på var den ligger.
S: Var så god att börja. Tryck på knappen för att spela in.
U: var ligger marö .
S: marö finns på denna karta .
U: jag vill åka till marö ikväll .
S: Var ifrån vill du åka.
U: stockholm .
FÖLJANDE BÅTAR GÅR FRÅN STOCKHOLM TILL MARÖ PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST AVG.HAMN
SJÖBRIS 9.00 (12.00) NYBROKAJEN
S: detta är en tabell över de båtar som går från stockholm till marö på en måndag .
U: tack .
S: Tack ska du ha.
S: Du ska hälsa på en vän på Ramsöberg, och vill stanna så länge som möjligt. Ta reda på när båten går.
S: Var så god att börja. Tryck på knappen för att spela in.
U: när går sista båten från ramsberg till stockholm .
S: Var ifrån vill du åka.
U: från ramsöberg .
S: vilken veckodag vill du åka.
U: idag .
FÖLJANDE BÅTAR GÅR FRÅN RAMSÖBERG TILL STOCKHOLM PÅ MÅNDAGAR :
BÅT AVGÅNG ANKOMST ANK.HAMN
SKARPÖ 10.25 12.10 STRÖMKAJEN
SKARPÖ 15.15 16.55 STRÖMKAJEN
S: detta är en tabell över de båtar som går från ramsöberg till stockholm på en måndag .
U: tack .
S: Tack ska du ha.
Waxholm screen shot(s)
Figure 3. Screen shot from the Waxholm system.