human compuetr interaction design, Assignments of Computer Science

Download human compuetr interaction design and more Assignments Computer Science in PDF only on Docsity!

HUMAN COMPUTER INTERACTION

(CS408)

• LECTURE 1. TABLE OF CONTENTS:
• INTRODUCTION TO HUMAN COMPUTER INTERACTION – PART I
  • L EARNING G OALS
  • 1.1 R IDDLES FOR THE INFORMATION A GE
  • 1.2 R OLE OF HCI..................................................................................................................................
• LECTURE 2.
• INTRODUCTION TO HUMAN-COMPUTER INTERACTION – PART II
  • L EARNING G OALS
  • 2.1 DEFINITION OF HCI........................................................................................................................
  • 2.2 R EASONS OF NON - BRIGHT ASPECTS
  • 2.3 HUMAN VERSES C OMPUTER
  • 2.4 SOFTWARE APARTHEID
• LECTURE 3.
• INTRODUCTION TO HUMAN-COMPUTER INTERACTION – PART III.......................................
  • L EARNING G OALS
  • 3.1 AN I NDUSTRY IN DENIAL
  • 3.2 T ECHNO -R AGE
  • 3.3 SUCCESS C RITERIA IN THE N EW E CONOMY
  • 3.4 C OMPUTER + INFORMATION
  • R EFERENCES
• LECTURE 4.
• GOALS & EVOLUTION OF HUMAN COMPUTER INTERACTION
  • L EARNING G OALS
  • 4.1 GOALS OF HCI
  • 4.2 E VOLUTION OF HCI
• LECTURE 5.
• DISCIPLINE OF HUMAN COMPUTER INTERACTION.....................................................................
  • L EARNING G OALS
  • 5.1 QUALITY
  • 5.2 INTERDISCIPLINARY NATURE OF HCI
  • R EFERENCE:..................................................................................................................................................
• LECTURE 6.
• COGNITIVE FRAMEWORKS....................................................................................................................
• LEARNING GOALS......................................................................................................................................
  • 6.1 INTRODUCTION
  • 6.2 M ODES OF C OGNITION
  • 6.3 HUMAN PROCESSOR MODEL
  • 6.4 GOMS............................................................................................................................................
  • 6.5 R ECENT DEVELOPMENT IN COGNITIVE PSYCHOLOGY
  • 6.6 E XTERNAL C OGNITION
  • 6.7 DISTRIBUTED COGNITION
• LECTURE 7.
• HUMAN INPUT-OUTPUT CHANNELS – PART I..................................................................................
  • L EARNING G OALS
  • 7.1 INPUT O UTPUT CHANNELS
  • 7.2 VISION
  • 7.3 VISUAL PERCEPTION
• LECTURE 8.
• HUMAN INPUT-OUTPUT CHANNELS PART II
  • L EARNING G OALS
  • 8.1 C OLOR T HEORY
  • 8.2 STEREOPSIS
  • 8.3 R EADING
  • 8.4 HEARING
  • 8.5 T OUCH
  • 8.6 M OVEMENT
• LECTURE 9.
• COGNITIVE PROCESS - PART I
  • L EARNING G OALS
  • 9.1 ATTENTION
  • 9.2 M EMORY
  • 9.3 R EVISED M EMORY M ODEL
• LECTURE 10..................................................................................................................................................
• COGNITIVE PROCESSES - PART II........................................................................................................
  • L EARNING G OALS
  • 10.1 L EARNING
  • 10.2 R EADING, SPEAKING AND L ISTENING
  • 10.3 PROBLEM SOLVING, PLANNING, R EASONING AND D ECISION - MAKING
• LECTURE 11..................................................................................................................................................
• THE PSYCHOLOGY OF ACTIONS
  • L EARNING G OALS
  • 11.1 M ENTAL MODEL
  • 11.2 E RRORS
• LECTURE 12................................................................................................................................................
• DESIGN PRINCIPLES................................................................................................................................
  • L EARNING G OALS
  • 12.1 DESIGN PRINCIPLES
• LECTURE 13................................................................................................................................................
• THE COMPUTER........................................................................................................................................
  • L EARNING G OALS
  • 13.1 INPUT DEVICES
  • 13.2 T EXT ENTRY DEVICES
  • 13.3 POSITIONING , POINTING AND DRAWING
  • 13.4 DISPLAY DEVICES
  • 13.5 T OUCH , FEEL AND SMELL
  • 13.6 PHYSICAL CONTROLS
  • 13.7 E NVIRONMENT AND BIO SENSING
• LECTURE 14................................................................................................................................................
• INTERACTION............................................................................................................................................
  • L EARNING G OALS
  • 14.1 T HE TERMS OF INTERACTION
  • 14.2 DONALD NORMAN ’S M ODEL
  • 14.3 T HE INTERACTION FRAMEWORK
  • 14.4 FRAMEWORKS AND HCI
  • 14.5 INTERACTION STYLES
• LECTURE 15................................................................................................................................................
• INTERACTION PARADIGMS..................................................................................................................
  • L EARNING G OALS
  • 15.1 T HE WIMP INTERFACES
  • 15.2 INTERACTION PARADIGMS
• LECTURE 16................................................................................................................................................
• HCI PROCESS AND MODELS
  • L EARNING G OALS
• LECTURE 17................................................................................................................................................
• HCI PROCESS AND METHODOLOGIES
  • L EARNING G OALS
  • 17.1 L IFECYCLE MODELS
  • 17.2 L IFECYCLE MODELS IN HCI
• LECTURE 18................................................................................................................................................
• GOAL-DIRECTED DESIGN METHODOLOGIES
  • L EARNING G OALS
  • 18.1 GOAL -DIRECTED D ESIGN M ODEL
  • 18.2 A PROCESS OVERVIEW
  • 18.3 T YPES OF USERS
• LECTURE 19................................................................................................................................................
• USER RESEARCH PART-I
  • L EARNING G OALS
  • 19.1 T YPES OF QUALITATIVE RESEARCH
• LECTURE 20................................................................................................................................................
• USER RESEARCH PART-II......................................................................................................................
  • L EARNING G OALS
  • 20.1 USER-C ENTERED A PPROACH
  • 20.2 E THNOGRAPHY FRAMEWORK
  • 20.3 PREPARING FOR ETHNOGRAPHIC INTERVIEWS
  • 20.4 PUTTING A PLAN TOGETHER
• LECTURE 21................................................................................................................................................
• USER RESEARCH PART-III
• LECTURE 22................................................................................................................................................
• USER MODELING
  • L EARNING G OALS
  • 22.1 W HY M ODEL?
  • 22.2 PERSONAS
  • 22.3 GOALS
  • 22.4 T YPES OF GOALS
  • 22.5 C ONSTRUCTING PERSONAS
• LECTURE 23................................................................................................................................................
• REQUIREMENTS........................................................................................................................................
  • L EARNING G OALS
  • 23.1 NARRATIVE AS A DESIGN TOOL
  • 23.2 E NVISIONING SOLUTIONS WITH PERSONA - BASED DESIGN
• LECTURE 24................................................................................................................................................
• FRAMEWORK AND REFINEMENTS
  • L EARNING G OALS
  • 24.1 DEFINING THE INTERACTION FRAMEWORK
  • 24.2 PROTOTYPING
• LECTURE 25.
• DESIGN SYNTHESIS..................................................................................................................................
  • L EARNING G OALS
  • 25.1 INTERACTION DESIGN PRINCIPLES
  • 25.2 INTERACTION DESIGN PATTERNS
  • 25.3 INTERACTION DESIGN IMPERATIVES
• LECTURE 26................................................................................................................................................
• BEHAVIOR & FORM PART I
  • L EARNING G OALS
  • 26.1 SOFTWARE POSTURE
  • 26.2 POSTURES FOR THE DESKTOP
• LECTURE 27................................................................................................................................................
• BEHAVIOR & FORM PART II.................................................................................................................
  • L EARNING G OALS
  • 27.1 POSTURES FOR THE W EB
  • 27.2 W EB PORTALS
  • 27.3 POSTURES FOR OTHER P LATFORMS
  • 27.4 FLOW AND T RANSPARENCY
  • 27.5 ORCHESTRATION
• LECTURE 28................................................................................................................................................
• BEHAVIOR & FORM PART III
  • L EARNING G OALS
  • 28.1 E LIMINATING E XCISE
  • 28.2 NAVIGATION AND INFLECTION
• LECTURE 29................................................................................................................................................
• EVALUATION – PART I............................................................................................................................
  • L EARNING G OALS
  • 29.1 E VALUATION PARADIGMS AND TECHNIQUES
• LECTURE 30................................................................................................................................................
• EVALUATION – PART II
  • L EARNING G OALS
  • 30.1 DECIDE: A FRAMEWORK TO GUIDE EVALUATION
• LECTURE 31................................................................................................................................................
• EVALUATION – PART VII
  • L EARNING G OALS
• LECTURE 32................................................................................................................................................
• EVALUATION IV........................................................................................................................................
  • L EARNING G OALS
  • 32.1 S CENE FROM A MALL
  • 32.2 W EB NAVIGATION
• LECTURE 33................................................................................................................................................
• EVALUATION V
  • L EARNING G OALS
  • 33.1 T RY THE TRUNK TEST
• LECTURE 34................................................................................................................................................
• EVALUATION – PART VI.........................................................................................................................
  • L EARNING G OALS
• LECTURE 35................................................................................................................................................
• EVALUATION – PART VII
  • L EARNING G OALS
  • 35.1 T HE RELATIONSHIP BETWEEN EVALUATION AND USABILITY?.....................................................
• LECTURE 36................................................................................................................................................
• BEHAVIOR & FORM – PART IV
  • L EARNING G OALS
  • 36.1 UNDERSTANDING UNDO
  • 36.2 T YPES AND VARIANTS OF
  • 36.3 INCREMENTAL AND PROCEDURAL ACTIONS
  • 36.4 SINGLE AND MULTIPLE UNDO
  • 36.5 OTHER M ODELS FOR UNDO -L IKE B EHAVIOR
  • 36.6 R ETHINKING FILES AND SAVE
  • 36.7 ARCHIVING
  • 36.8 IMPLEMENTATION M ODEL VERSUS M ENTAL M ODEL
  • 36.9 DISPENSING WITH THE IMPLEMENTATION M ODEL OF THE FILE SYSTEM
  • 36.10 DESIGNING A UNIFIED FILE P RESENTATION M ODEL
• LECTURE 37................................................................................................................................................
• BEHAVIOR & FORM - PART V...............................................................................................................
  • L EARNING G OALS
  • 37.1 UNIFIED DOCUMENT M ANAGEMENT
  • 37.2 C REATING A MILESTONE COPY OF THE DOCUMENT
  • 37.3 ARE DISKS AND FILES SYSTEMS A F EATURE?
  • 37.4 T IME FOR C HANGE
  • 37.5 M AKING SOFTWARE C ONSIDERATE
  • 37.6 C ONSIDERATE SOFTWARE IS POSSIBLE
  • 37.7 M AKING SOFTWARE SMARTS :
  • 37.8 PUTTING THE I DLE C YCLES TO W ORK
  • 37.9 GIVING SOFTWARE A M EMORY
  • 37.10 T ASK C OHERENCE
  • 37.11 ACTIONS TO R EMEMBER
  • 37.12 APPLYING M EMORY TO YOUR APPLICATIONS
  • 37.13 M EMORY M AKES A DIFFERENCE
• LECTURE 38................................................................................................................................................
• BEHAVIOR & FORM – PART VI
  • L EARNING G OALS
  • 38.1 DESIGNING L OOK AND FEEL
  • 38.2 PRINCIPLES OF VISUAL INTERFACE D ESIGN
• LECTURE 39................................................................................................................................................
• BEHAVIOR & FORM – PART VII...........................................................................................................
  • L EARNING G OALS
  • 39.1 PROVIDE VISUAL STRUCTURE AND FLOW AT EACH LEVEL OFORGANIZATION
  • 39.2 PRINCIPLES OF VISUAL INFORMATION DESIGN
  • 39.3 USE OF T EXT AND C OLOR IN VISUAL INTERFACES
  • 39.4 C ONSISTENCY AND STANDARDS
• LECTURE 40................................................................................................................................................
• OBSERVING USER.....................................................................................................................................
  • L EARNING G OALS
  • 40.1 W HAT AND WHEN TO OBSERVE
  • 40.2 H OW TO OBSERVE
  • 40.3 DATA C OLLECTION
  • 40.4 INDIRECT OBSERVATION: TRACKING USERS ' ACTIVITIES
  • 40.5 A NALYZING, INTERPRETING, AND PRESENTING THE DATA
• LECTURE 41................................................................................................................................................
• ASKING USERS...........................................................................................................................................
  • L EARNING G OALS
  • 41.1 I NTRODUCTION
  • 41.2 ASKING USERS: INTERVIEWS
  • 41.3 ASKING USERS : QUESTIONNAIRES
  • 41.4 A SKING EXPERTS : WALKTHROUGHS
• LECTURE 42................................................................................................................................................
• COMMUNICATING USERS
  • L EARNING G OALS
  • 42.1 E LIMINATING E RRORS
  • 42.2 POSITIVE FEEDBACK
  • 42.3 NOTIFYING AND C ONFIRMING
  • 42.4 ALERTS AND C ONFIRMATIONS
  • 42.5 ELIMINATING CONFIRMATIONS
  • 42.6 R EPLACING DIALOGS: R ICH M ODELESS F EEDBACK
  • 42.7 R ICH VISUAL MODELESS FEEDBACK
• LECTURE 43................................................................................................................................................
• INFORMATION RETRIEVAL
  • L EARNING G OALS
  • 43.1 AUDIBLE FEEDBACK
  • 43.2 OTHER C OMMUNICATION WITHUSERS
  • 43.3 IMPROVING D ATA R ETRIEVAL
• LECTURE 44................................................................................................................................................
• EMERGING PARADIGMS........................................................................................................................
  • L EARNING G OALS
  • 44.1 ACCESSIBILITY
• LECTURE 45................................................................................................................................................
• CONCLUSION
  • L EARNING G OALS
  • 45.1 W EARABLE C OMPUTING
  • 45.2 T ANGIBLE B ITS
  • 45.3 ATTENTIVE E NVIRONMENTS

Lecture 1.

Introduction to Human Computer Interaction

• Part I

Learning Goals

As the aim of this lecture is to introduce you the study of Human Computer Interaction,

so that after studying this you will be able to:

Answer what is the significance of Human Computer Interaction (HCI)

Discuss and argue about why Human computer Interaction (HCI) is important with

reference to the way in which technology has developed during past forty years

Describe a formal definition of HCI.

At the end of this lecture you will be told about the course contents. This will be a brief

overview of the topics that we will discuss in this course and the structure of the course.

Run for your lives---invasion has begun---the computers are invading.

Now it is twenty first century and during the past thirty years technology has advanced to

such an extent that almost everyone come in contact with computers in one way or

another. Look around yourself how many things are there which have some kind of

computer embedded in them? Think about a minute about what you use in a typical day;

ATM, cell phone, VCR, remote control, ticketing machine, digital personal organizers,

calculator, watch, photocopier, toaster, bank, air conditioner, broadcasting, satellite,

microwave, medical equipment, factories, companies….the list is endless. Computers are

everywhere. We are surrounded by computers. Now they are part of our everyday life.

Traditional notion of computers is no more. Unlike in the early days of computing, when

only highly skilled technical people used computers, nowadays the range of knowledge

and experience of different users is very broad. Computers are no more just on your table.

Now computer has become a tool of everyday use. They are everywhere, at everyplace

and in everything. They are penetrating in every aspect of our life. They are taking our

lives.

When computers first appeared on the commercial scene in the 1950s, they were

extremely difficult to use, cumbersome and at times unpredictable. There were a number

of reasons for this;

They were very large and expensive machines, so that by comparison human labor (that

is, ’people time’) was an inexpensive resource.

They were used only by technical specialists – scientists and engineers – who were

familiar with the intricacies of off-line programming using punch cards.

Computers are annoying us

They are infuriating us

They even kill a few of us.

In turn, we will be tempted to kill our computers, but we won’t dare because we are

already utterly, irreversibly dependent on these hopeful monsters that make modern life

possible. So we will have to think about them. We will have to think how we can make

them better. We need to fundamentally rethink how human and machines interact. And

rethink the relationship in deep and novel ways, for the fault for our burgeoning problems

lies not with our machines, but with us.

1.1 Riddles for the Information Age

What do you get when you cross a computer with an Airplane?

In December 1995, American Airlines Flight 965 departed from Miami on a regularly

scheduled trip to Cali, Columbia. On the landing approach, the pilot of the 757 needed to

select the next radio navigation fix, named “ROZO”. He entered an “R” into his

navigation computer. The computer returned a list of nearby navigation fixes starting with

“R” and the pilot selected the first of these, whose latitude and longitude appeared to be

correct. Unfortunately, instead of “ROZO”, the pilot selected “ROMEO”, 132 miles to the

northeast. The jet was southbound descending into a valley that runs north-south, and any

lateral deviation was dangerous. Following indications on the flight computer, the pilots

began an easterly turn and slammed into a granite peak at 10,000 feet. One hundred and

fifty two passengers and all eight crewmembers aboard perished. Four passengers

survived with serious injuries.

What do you get when you cross a computer with a Camera?

Here is a riddle for the information age: what do you get when you cross a computer with

a camera? Answer: A computer! Thirty years ago, a 35mm Pentax Model H, had a small

battery in it that powered the light meter. Like a wristwatch battery, I merely swapped in

a new one every couple of years. Fifteen years ago, an electronic camera, a 35mm Canon

T70, used two AA batteries to power its rather simple exposure computer and its

automatic film drive. It had a simple On/Off switch, so that the batteries wouldn’t wear

down needlessly.

Five years ago, a first-generation digital camera, had a similar On/Off switch, but this

time it had the smarts of a rudimentary computer inside it. So if I forgot to turn it off, it

automatically shut down after one minute of inactivity.

One year ago, second-generation digital camera, a Panasonic PalmCam, had an even

smarter computer chip inside it. It was so smart that its On/Off switch had evolved into an

Off/Rec/Play switch. It now had modes: it had to put into Rec mode to take pictures and

Play mode to view them on its small video display.

The newest camera, a Nikon CoolPix 900, is a third-generation digital camera and the

smartest yet. In fact, it has a full-blown computer that displays a Windows-like hourglass

while it “boots up”. Like some mutant fish with extra heads, its On/Off switch has now

grown to have four settings: Off/ARec/MRec/Play. “ARec” means “automatic record”

and “MRec” means “manual record.” as far as I can figure out how to turn it on without a

lengthy explanation.

The new camera is very power-hungry, and its engineers thoughtfully provided it with a

sophisticated computer program that manages the consumption of battery power. A

typical scenario goes like this: I turn the evil off/etc. switch to “MRec,” wait about seven

long seconds for the camera to boot up, then point it at my subject. I aim the camera and

zoom in to properly frame the image. Just as I’m about to press the shutter button, the

camera suddenly realizes that simultaneously running the zoom, charging the flash, and

energizing the display has caused it to run out of power. In self-defense, it suspends its

ability to actually take pictures. But I don’t know that because I’m liking through the

viewfinder, waving my arms and saying “Smile” and pressing the shutter button. The

computer detects the button press, but it simply cannot obey. In a misguided effort to help

out, the power management program instantly takes over and makes an executive

decision: shed load. It shuts down the power-greedy LCD video display. I look at the

camera quizzically, wondering why it didn’t take the picture, shrug my shoulders, and let

my arm holding the camera drop to my side. But as soon as the LCD is turned off, there is

more battery power available for other systems. The power management program senses

this increase and realizes that it now has enough electricity to take pictures. It now returns

control to the camera program, which is waiting patiently to process the command it

received when I pressed the shutter button, and it takes a nicely auto-focused, well-

exposed, high-resolution digital picture of my kneecap.

That old mechanical Pentax had manual focusing, manual exposure, and manual shutter-

speed, yet it was far less frustrating to use than the fully computerized modern Nikon

CoolPix 900, which has automatic focusing, exposure, and shutter-speed. Camera may

still take pictures, but it behaves like a computer instead of a camera.

What do you get when you cross a computer with a car?

A computer! Porsche’s beautiful new high-tech spots car, the Boxster, has seven

computers in it to help manage its complex systems. One of them is dedicated to

managing the engine. It has special procedures built into it to deal with abnormal

situations. Unfortunately, these sometimes backfire. In some early models, if the fuel

level in the gas tank got very low---only a gallon or so remaining---the centrifugal force

of a sharp turn could cause the fuel to collect in the side of the tank, allowing air to enter

the fuel lines. The computer sensed this as a dramatic change in the in coming fuel

mixture, and interpreted it as a catastrophic failure of the injection system. To prevent

damage, the computer would shut down the ignition and stop the car. Also to prevent

damage, the computer would not let the driver restart the engine until the car had been

towed to a shock and serviced

When owners of early Boxsters first discovered this problem, the only solution Porsche

could devise was to tell them to open the engine compartment and disconnect the battery

for at least five minutes, giving the computer time to forget all knowledge of the hiccup.

The sports car may still speed down those too-lane black top roads, but now, in those

turns, it behaves like a computer.

What do you get when you cross a computer with a warship?

In September of 1997, while conducting fleet maneuvers in the Atlantic, the USS

Yorktown, one of the Navy’s new Aegis guided-missile cruisers, stopped dead in the

water. A Navy technician, while calibrating an on-board fuel valve, entered a zero into

one of the shipboard management computers, a Pentium Pro running Windows NT. The

program attempted to divide another number by that zero---a mathematically undefined

operation---which resulted in a complete crash of the entire shipboard control system.

Without the computers, the engine halted and the ship sat wallowing in the swells for two

• =

• =

hours and fifty-five minutes until it could be towed into port. Good thing it wasn’t in a

war zone.

What do you get when you cross a computer with a warship? Admiral Nimitz is rolling

in his grave! Despite this setback, the Navy is committed to computerizing all of its ships

because of the manpower cost savings, and so deflect criticism of this plan, it has blamed

the “incident” on human error. Because the software creation process is out of control, the

high-tech industry must either bring its process to heel or it will continue to put the blame

on ordinary users while ever-bigger machines sit dead in the water

So here you saw the result of integrating computers in our lives. As I said early,

computers will annoy us, infuriate us, and even kill a few of us. In turn, we will be

tempted to kill our computers, but we won’t dare because we are already utterly,

irreversibly dependent on these hopeful monsters that make modern life possible. So we

will have to think about them. We will have to think how we can make them better. We

need to fundamentally rethink how human and machines interact. And rethink the

relationship in deep and novel ways, for the fault for our burgeoning problems lies not

with our machines, but with us.

1.2 Role of HCI

Here comes the role of HCI. Human designed the interfaces we hate; human continue to

use dysfunctional machines even as the awkward interfaces strain their eyes, ache their

backs, and ruin their wrist tendons. HCI plays a role to bridge up the gape between the

interfaces of machines and human understanding that we have seen in the previous

examples.

Definition of HCI

“Human-Computer Interaction is a discipline concerned with the design, evaluation and

implementation of interactive computing systems for human use and with the study of

major phenomena surrounding them”

-ACM/IEEE

The front panel of the airplane’s navigation computer showed the currently selected

navigation fix and a course deviation indicator. When the plane is on course, the needle is

centered, but the needle gives no indication whatsoever about the correctness of the

selected radio beacon. The gauge looks pretty much the same just before landing as it

does just before crashing. The computer told the pilot he was tracking precisely to the

beacon he had selected. Unfortunately, it neglected to tell him the beacon the selected was

a fatal choice.

The flight computer on Flight 965 could easily have told the pilots that ROMEO was not

an appropriate fix for their approach to Cali. Even a simple hint that it was “unusual” or

“unfamiliar” could have saved the airplane. Instead, it seemed as though the computer

was utterly unconcerned with the actual flight and its passengers. It cared only about its

own internal computations

Joke in Computer Industry

There is a widely told joke in the computer industry that goes like this: A man is flying in

a small airplane and is lost in the clouds. He descends until he spots an office building

and yells to a man in an open window, “Where am I?” The man replies, “You are in an

airplane about 100 feet above the ground.” The pilot immediately turns to the proper

course, spots the airport and lands. His astonished passenger asks how the pilot figured

out which way to go. The pilot replies, “The answer the man gave me was completely

correct and factual, yet it was no help whatsoever, so I knew immediately he was a

software engineer who worked for Microsoft and I know where Microsoft’s building is in

relation to the airport.”

When seen in the light of the tragedy of Flight 965, the humor of the joke is macabre, yet

professionals in the digital world tell it gleefully and frequently because it highlights a

fundamental truth about computers:

They may tell us facts but they don’t inform us.

They may guide us with precision but they don’t guide us where we want to go. The flight

computer on Flight 965 could easily have told the pilots that ROMEO was not an

appropriate fix for their approach to Cali. Even a simple hint that it was “unusual” or

“unfamiliar” could have saved the airplane. Instead, it seemed as though the computer

was utterly unconcerned with the actual flight and its passengers. It cared only about its

own internal computations

Communication can be precise and exacting while still being tragically wrong. This

happens all too frequently when we communicate with computers, and computers are

invading every aspect of our modern lives. From the planes we fly to just about every

consumer product and service, computers are ubiquitous, and so is their characteristically

poor way of communicating and behaving.[1]

I-Drive Car Device

It takes automotive computer power to a whole new level. Computer systems provide the

car with BMW's most powerful engine, a silky smooth ride and what is supposed to be

the simplest in-dash control system available. But what is created for the sake of

simplicity can often time creates the most confusion.

Many controls are operated with a single large, multifunction knob located in the console

between the front seats. The control consists of a combination rotary and push button for

selecting functions. Confirmation of the selected mode is displayed on a dash-mounted

screen.

Users can change functions -- from communications to climate control, navigation or

entertainment -- by pushing the console knob forward or back, or side-to-side. By

twisting the knob, they can scroll through menus. And by clicking a button located in the

middle of the knob, they can select functions.

"iDrive" takes into account the fact that comfort, communication and driver assistance

functions are only rarely adjusted while driving. The operating unit in the center console

gives the driver direct access to many other driving functions and information and

communication options. Several hundred functions can be controlled with this device.

A computer-type monitor is positioned directly within the driver's line of vision to the

road ahead. The large monitor in the center of the dashboard displays all the information

the driver needs, apart from the speedometer and tachometer, which are conventional

analog instruments.

The driver slides the dial to choose between multiple control menus

displayed on an in-dash LCD screen. The driver rotates the dial to move

through lists and pushes the dial axially to select a list item.

After reading that I didn't feel like I had any sort of idea what 'axially' meant, but I

suppose this video helps. What concerns me about this is the interaction with this little

device requires the driver, hurtling down the road, to look at a screen. They say there is

force feedback that indicates the menu, but that's only half the equation, because there are

things in the menus. So, I'm guessing the driver needs to memorize the menus, which are

sure to be short, so think about the mental modeling here.

To really keep your eyes on the road, you have to be able to do everything by feel and

pattern. Is this easier than hot-cold air sliders, vent selection buttons and radio dials?

And fortunately or unfortunately they make mistakes. They make mistakes which some

time become fatal for them and some time they become blessing for them.

Computer species

On contrast, computers are the invention of human being. They are also complex but they

are also pretty dumb. It can also think but it can’t think on its own will, it thinks how it

has been directed to think. No doubt its speed is marvelous. It does not tire. It is

emotionless. It has no feelings, no desires. It works how it has been commanded to work.

And they do not make mistakes.

Before penetration of computers in our daily life, human beings were performing their

tasks at their on responsibility. In a business domain human beings were dealing and

interacting with each other’s. For example a store manager was dealing with all the

workers performing their different duties in the store. Some one was registering the new

arrivals of products, some one was numbering the products and many more…and store

manager has to interact with all these human beings. If some one was a salesperson, he

used to interact with different clients and used to deal with them according to their mood

and desire. He could judge their mood with their tone, their attitude and with their body

language. He could provide answers relevant to their questions.

But now in this age of information technology we are expecting computers to mimic

human behavior e.g. ECommerce systems, now there is no need for a salesperson. Web

sites are behaving as a salesperson or as a shopping mal. That is now; a dumb,

unintelligent and inanimate object will perform the complex task which was performed by

some human being.

2.4 Software Apartheid

Apartheid

Racial segregation; specifically: a policy of segregation and political and economic

discrimination against non-European groups in the Republic of South Africa. [Definition

of apartheid]

Software Apartheid

Institutionalizing obnoxious behavior and obscure interactions of software-based

products. [Definition of software apartheid]

Programmers generally work in high-tech environments, surrounded by their technical

peers in enclaves like Silicon Valley. Software engineers constantly encounter their peers

when they shop, dine out, take their kids to school and relax, while their contact with

frustrated computer users is limited. What’s more, the occasional unfocused gripes of the

users are offset by the frequent enthusiasm of the knowledgeable elite. We forget how far

removed our peers and we are from the frustration and inability of the rest of the country

(not to mention the world) to use interactive tools.

We industry insiders toss around the term “computer literacy”, assuming that in order to

use computers; people must acquire some fundamental level of training. We see this as a

simple demand that is not hard and is only right and proper. We imagine that it is not

much to ask of users that they grasp the rudiments of how the machines work in order to

enjoy their benefits. But it is too much to ask. Having a computer literate customer base

makes the development process much easier—of their can be no doubt—but it hampers

the growth and success of the industry and of society. Apologists counter with the

argument that you must have training and a license to drive a car, but they overlook the

fact that a mistake with software generally does not. If cars were not so deadly, people

would train themselves to derive the same way they learn excel.

It has another, more insidious effect. It creates a demarcation line between the haves and

have-nots in society. If you must master a computer in order to succeed in America’s job

Market beyond a burger-flipper’s carriers, then the difficulty of mastering interactive

systems forces many people into menial jobs rather than allowing them to matriculate into

more productive, respected and better-paying jobs.

Users should not have to acquire computer literacy to use computer for common,

rudimentary task in everyday life. Users should not have to possess a digital sensitivity to

work their VCR, microwave oven, or to get e-mail. What’s more, should not have to

acquire computer literacy to use computer for enterprise applications, where the user is

already trained in the application domain. An accountant for example, who is trained in

the general principles of accounting, should not have to become computer literate to use a

computer in her accounting practice. Her domain knowledge should be enough to see her

through.

As our economy shifts more and more onto information bases, we are inadvertently

creating a divided society. The upper class is composed of those who have mastered the

nuances of differentiating between “RAM” and “Hard Disk”. The lower class is that who

treat the difference inconsequential. The irony is that the difference really is

inconsequential to any one except a few hard-core engineers. Yet virtually all-

contemporary software forces its users to confront a file system, where your success fully

dependent on knowing the difference between RAM and disk.

Thus the term “computer literacy” becomes a euphemism for social and economic

apartheid. Computer literacy is a key phrase that brutally bifurcates our society.

But about those people who are not inclined to pander to technocrats and who can not or

will not become computer literate? These people, many by choice, but most by

circumstances, are falling behind in the information revolution. Many high-tech

companies, for example, would not even consider for employment any applicant who

does not have an e-mail address. I’m sure that there are many otherwise qualified

candidates out there who cannot get the hired because they are not yet wired. Despite the

claims of the Apologists, using e-mail effectively is difficult and involves a significant

level of computer literacy. Therefore, it artificially segregates the work force. It is the

model equivalent of the banking technique of “red lining”. In this illegal procedure, all

houses in a given neighborhood are declared unacceptable as controller for a housing

loan. Although the red lines on the map are ostensibly drawn around economic contours,

they tend to follow racial lines all too closely bankers protest that they are not racists, but

the effect is the same.