Anais do IHC'2001 - Departamento de Informática e Estatística - UFSC
Anais do IHC'2001 - Departamento de Informática e Estatística - UFSC
Anais do IHC'2001 - Departamento de Informática e Estatística - UFSC
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Anais</strong> <strong>do</strong> IHC’2001 - IV Workshop sobre Fatores Humanos em Sistemas Computacionais 43<br />
switching back and forth between topics), we are now completely unconstrained (except<br />
due to technological limitations such as memory capacity, which we will not consi<strong>de</strong>r<br />
here). This can be a major source of confusion and frustration to inexperienced users, for it<br />
<strong>do</strong>es not have any parallel in human-to-human conversation.<br />
4.4 Interaction Specifications<br />
In or<strong>de</strong>r to compare the interaction in the three different environments, as specified in Dahis’<br />
specification language, LECI, we reproduce below the specifications, where the semantic<br />
types (shown previously between parentheses) have been omitted for the sake of clarity:<br />
Phone ATM Web<br />
Task<br />
GetAccountBalanceViaPhone<br />
sequence<br />
{<br />
Dialog AccountNumber<br />
Dialog AccountPassword<br />
Dialog AccountBalance<br />
Dialog ServicesSelection<br />
}<br />
Task GetAccountBalanceViaATM<br />
sequence<br />
{<br />
Dialog AccountNumber<br />
Dialog AccountPassword<br />
Dialog ServicesInfo<br />
Dialog ServicesSelection<br />
Dialog<br />
InfoServicesSelection<br />
Dialog Vi<strong>de</strong>oInfoSelection<br />
Dialog ConfirmPassword<br />
Dialog AccountBalance<br />
}<br />
Task GetAccountBalanceViaWeb<br />
sequence<br />
{<br />
Dialog AccountNumberPassword<br />
Dialog ServicesSelection<br />
Dialog AccountServices<br />
<br />
Dialog AccountBalance<br />
<br />
}<br />
From the interaction specifications, we may notice that, on the phone, the <strong>de</strong>fault<br />
operation is to verify the account balance, and thus no user selection must be ma<strong>de</strong>. This is<br />
probably due to the limitations of the linearity of the channel, coupled with cost<br />
consi<strong>de</strong>rations. Moreover, all the services in this system are for information retrieval only; no<br />
transactions can be ma<strong>de</strong> without a human attendant. In contrast, on the ATM and on the web,<br />
a whole range of services is offered. A couple of things are worthy of comment: how user<br />
i<strong>de</strong>ntification was handled, how on-screen and printable versions of the information were<br />
accessed, and how the navigation between selection options could be ma<strong>de</strong>.<br />
User i<strong>de</strong>ntification took place differently in each environment. In phone banking<br />
and web banking, the user provi<strong>de</strong>d the account number, whereas in the ATM, the card<br />
itself provi<strong>de</strong>d the i<strong>de</strong>ntification. In both systems the user had to confirm his/her id by<br />
means of a password. On the phone system, the account number and the password were<br />
requested in two consecutive moments, whereas, on the web, they were provi<strong>de</strong>d at the<br />
same interaction exchange. As soon as the i<strong>de</strong>ntification took place, the range of possible<br />
conversations was constrained by both user profile and technological consi<strong>de</strong>rations.<br />
The forms of access to on-screen and printable versions of information also differed<br />
between systems. On the web, the information was displayed on-screen, and the user could<br />
print it through extra-system features of the browser. On the ATM, the user had to<br />
prematurely choose the media in which the information should be provi<strong>de</strong>d. This difference<br />
reveals an absence of an un<strong>de</strong>rlying high-level interaction mo<strong>de</strong>l common to both systems.<br />
As to the navigation structures, which somewhat reflect the dialog structures, we<br />
find a narrow and shallow structure on the phone system, i.e. few options are presented at<br />
once, and there are few options overall. On the ATM, we have many services options, but<br />
due to display size limitations, few are presented at any given moment. In other words, the<br />
ATM presents a narrow but <strong>de</strong>ep structure. The web system, virtually unconstrained,<br />
presents a wi<strong>de</strong> and shallow structure, in addition to a persistent menu of services, which<br />
provi<strong>de</strong> direct access to any second-level menu in the system.