Practical File

Of

Human Computer Interaction

Submitted by

Aakash Raj
1507884

in partial fulfillment for the award of the degree

of

Bachelor of technology
At

Guru Nanak Dev Engineering College

Ludhiana
NOVEMBER & 2017

Signature of the Internal Examiner: Signature of the External Examiner:

Date: Date:
 INDEX
S. Objective Page Signature
No No
1 To understand and design the interaction 1
models.
2 To understand and design the status- 4
event analysis.
3 To design and implement the user 7
interface which takes into consideration
the cognitive models.
4 To design and implement a user support 10
and help system for emergency
conditions.
5 To design and simulate the sensor-based 12
interactive system.
6 To design and implement the eective 14
interface for a system which mitigates the
human errors.
7 To design and implement HCI for a critical 16
system involving human safety.
 University Roll No 1507884

1. To understand and design the interaction models.

What Is an Interaction Model?
What is an interaction model? An interaction model is a design model that binds an application
together in a way that supports the conceptual models of its target users. It is the glue that holds an
application together. It defines how all of the objects and actions that are part of an application
interrelate, in ways that mirror and support real-life user interactions. It ensures that users always
stay oriented and understand how to move from place to place to find information or perform tasks.
It provides a common vision for an application. It enables designers, developers, and stakeholders
to understand and explain how users move from objects to actions within a system. It is like a
cypher or secret decoder ring: Once you understand the interaction model, once you see the pattern,
everything makes sense. Defining the right interaction model is a foundational requirement for any
digital system and contributes to a cohesive, overall UX architecture.
Drawing Some Contrasts
A global template is akin to a design style guide that rigidly enforces exactly where every element
goesnot on just one page or screen, but across many of them. An interaction model, on the other
hand, is more like a foundational design pattern that describes the ways in which objects interrelate,
with many subpatterns that together describe the overall model. The difference is that interaction
models leave room for designers to solve users real problems.
An interaction model describes how to represent an application to users. For example, should our
PC-based, non-mobile application use more Web-portal affordances or desktop-application
affordances? In our case, we decided that, although we would develop a Web application, it would
use only desktop affordances. It would minimize the underlining of links and use more buttons
instead. It would have a Maximize/Restore button that hides or shows the browser chrome, enabling
the application to take up 100% of the usable space on the screen, similar to that on Cooliris, shown
in Figures 1 and 2. The upshot is that, though we are designing the application technology to be
highly performant, we have chosen a desktop application metaphor over a Web portal metaphor for
the application. Often, what model you choose doesnt matter as much as just choosing a model and
sticking with it.

Page No 1
 University Roll No 1507884

An information architecture maps the relationships between pages. I tend to not use the
term information architecture when talking about designing a complex Web portal or application,
because it suggests that we, as designers, are just structuring information. When designing a
complex system, we are defining more than its information architecture. We are defining the way
users move through a system consisting of many complex elements and how they use them to
perform complex transactions, then find their way back.
Defining an Applications Interaction Model
How, then, do you define an applications interaction model? It can take months, but in the end,
when stakeholders look at the model, they typically say, Of course! I get it! Its simple! In this
way, an interaction model is not unlike complex mathematics. You work hard to understand it
maybe for hours or even days or weeksbut then, once you finally understand how to solve a type
of problem, it seems so simple that you wonder why it took so long to understand it in the first
place.
Defining an Interaction Model to Meet UX Goals
Knowing whether an interaction model works requires not only usability testing, but also a very
seasoned designerone who can recognize when a model will not scale and predict what
challenges users would encounter with the model. In the end, for the travel product at HP, I and my
most senior design lead made the final decisions about the interaction model. Only later did our less
experienced designers internalize it. But once they did, it provided a framework for their ongoing
design efforts.
You cannot create an interaction model without first understanding the user experience goals for a
productallowing a team to measure the success of the model and the individual design decisions
youve made within the model. In the case of the travel product that my team and I are designing,
we established metrics around the following goals:

Page No 2
 University Roll No 1507884
discoverabilityCan users quickly find the models primary object and understand how to perform
the actions they care about? Can they use the system successfully the first time?
learnabilityHow long does it take for users to internalize how to use the system competently?
Even consumer products often have a slight learning curve today. For example, my company just
gave me a new smartphone, and it took me a bit of exploration to understand how to use all of its
cool features not to mention how to avoid draining the battery in three hours.
user efficiency and productivityOnce users are competent using the system, how easy is it for
them to perform common or repetitive tasks? Can they perform bulk actions all at once, or do they
have to perform dozens or even hundreds of separate actions?
system response timeOnce users take an action, how long does the system take to respond? In a
production environment, user efficiency and system response time combine to define the total task
time. Designers have a responsibility to understand the expectations and constraints on system
response time and design a product that meets or exceeds those expectations.
delightHow cool does the product feel to users? Do users like using it? How much do they like it
especially in comparison to other products? I set up a Customer Listening organization, and well be
systemically gathering this type of dataalong with Net Promoter Score datato drive the top five
to seven product improvements each quarter
Conclusion
Defining an interaction model is a foundational requirement for a digital system. By first defining
interaction models for our products, we crafted a product vision that our peers, senior leaders,
designers, stakeholders, and users could understand and rally around. When I showed our
interaction model and application simulations to customers back in November, they wanted to move
directly to talking about product schedules.

Page No 3
 University Roll No 1507884

2. To understand and design the status-event analysis.

Applications want to cause events for users and use various presentation techniques to do this.
However, these techniques must be matched to the timescale of the desired event. For example, if a
stock of 6 mm bolts is running low, this requires reordering within days or weeks. On the other
hand, a coolant failure in a nuclear power plant may require action within seconds.
The presented form of the event for the user must match these timescales both causing events too
fast or too slow is wrong. It is fairly obvious that too slow an event is wrong. An email message to
the power plant operator would be ineffectual; the operator and the computer would both be so
much radioactive waste. However, the opposite fault can be equally damaging. Red flashing lights
and alarm bells when the last box of 6 mm bolts is opened would be annoying, and could also
distract the operator from more important tasks, such as dealing with that coolant.
E-R Diagram:

Page No 4
 University Roll No 1507884
DATA FLOW DIAGRAM
A graphical tool used to describe and analyze the moment of data through a system manual or
automated including the process, stores of data, and delays in the system. Data Flow Diagrams are
the central tool and the basis from which other components are developed. The transformation of
data from input to output, through processes, may be described logically and independently of the
physical components associated with the system. The DFD is also know as a data flow graph or a
bubble chart. DFDs are the model of the proposed system. They clearly should show the
requirements on which the new system should be built. Later during design activity this is taken as
the basis for drawing the systems structure charts. The Basic Notation used to create a DFDs are
as follows:
Context Level DATA FLOW DIAGRAM:
CONTEXT LEVEL DATA FLOW DIAGRAM

Registraions

Data Base
Data Output Stages

Banks

AdministratorDataData Input
Input Stages
Stages
Career
Data Output Stages UI Screens

Mails

Authenticated
Data Input Stages
User

Data Output Stages Reports

PasPorts

Pancard

Highly Confidentidla Security System

System Process

Page No 5
 University Roll No 1507884
ADMIN:

CONTEXT LEVEL DATA FLOW DIAGRAM

Data Base
Data Output Stages

USERD

User Account
Accepted Data Output Stages UI Screens

Administrator Data Input Stages

Profile

Data Output Stages Reports

Change
PAssword

HCSS

System Process

Page No 6
 University Roll No 1507884

3. To design and implement the user interface which

takes into consideration the cognitive models.
Cognitive modeling is an area of computer science that deals with simulating human problem
solving and mental task processes in a computerized model. Such a model can be used to simulate
or predict human behavior or performance on tasks similar to the ones modeled. Cognitive
modeling is used in numerous artificial intelligence ( AI ) applications, such as expert
system s, natural language programming, and neural network s, and in robotics and virtual
realityapplications. Cognitive models are also used to improve products in manufacturing segments
such as human factors engineering, and computer game and user interface design. Research into
cognitive modeling is currently being conducted by academic and industry groups, including MIT,
IBM, and Sandia National Laboratories.
An advanced application of cognitive modeling is the creation of cognitive machine s, which are AI
programs that can be said to think for themselves. One of the goals of Sandia's project is to make
human-computer interaction more like the interaction between two humans. According to Sandia's
cognitive psychologist, Chris Forsythe, "We had the massive computers that could compute the
large amounts of data, but software that could realistically model how people think and make
decisions was missing," Forsythe says the problem was that early models followed logical processes
that humans don't always adhere to, and failed to take into account variables that affect human
cognition, such as fatigue, emotion, stress, and distraction.
Some highly sophisticated programs model the intellectual processes of specific individuals;
techniques such as discrepancy detection are used to improve these complex models. Discrepancy
detection systems signal when there is a difference between the individual's actual state or behavior
and the expected state or behavior as per the cognitive model; that information is then used to
increase the complexity of the model.
Actors are external entities that interact with the system. Examples of actors include users like
administrator, bank customer etc., or another system like central database.
1. system Use Case Diagram

System

Administrator

Highly Confidential Security System

Authenticated User

Page No 7
 University Roll No 1507884
2. Administrator Use Case Diagram

Delete Users

<<include>>
View RegisteredUsers
Accept/RejectUsers Request

<<include>>

Authenticated Users
View Requested Users

Delete User
<<include>>

Profile

Administrator view Profile

UpdateProfile

<<include>>

Change Password

Logout

3. User Use Case Diagram

Update Study Details

Add StudyDetails
Delete Studey Details
View Studey Details

Add Bank UpdateBank Details

Education
View Bank Delete BankDetails
<<include>>
Bank <<include>>

Add Mails Details Update Mails Details

Mails
view Mails Details deleteMails Details

<<include>>
<<include>>
Add Passport Details
PassPort Details
update Passport Details
View Passport Details

<<include>> delete PassportDetails

Authendicated User
<<include>>
Pancard Details
AddPancard Details

View Pancard Details Update Pancard Details

Insurance
<<include>> deletePancard Details
<<include>>
Add Insurance
License
View Insurance Update Insuracne Details

<<include>> Delete Insuracne Details

<<include>>
Other Files
Add License

view License Update License

Profile <<include>> delete License

<<include>>
Add Files

View Files update Files

<<include>> deleteFiles
<<include>>
view Profile
Logout

UpdateProfile
<<include>>
Change Password

Page No 8
 University Roll No 1507884
4.User Use Case Diagram

login

UsernameCheck
new Registration
<<include>>

User <<extend>>

ForgetPassword NewPassword

Site Information

Page No 9
 University Roll No 1507884

4. To design and implement a user support and help

system for emergency conditions.
There is often an implicit assumption that if an interactive system is properly designed it will be
completely intuitive to use and the user will require little or no help or training. This may be a grand
ideal but it is far from true with even the best- designed systems currently available. It is even
perhaps an unhelpful ideal: a com- puter is a complex piece of equipment what other such
equipment do we expect people to use without instruction or help? A more helpful approach is to
assume that the user will require assistance at various times and design this help into the system.
The type of assistance users require varies and is dependent on many factors: their familiarity with
the system, the job they are trying to do, and so on. There are four main types of assistance that
users require:
quick reference
task-specific help
full explanation n tutorial.
REQUIREMENTS OF USER SUPPORT
Availability
The user needs to be able to access help at any time during his interaction with the system. In
particular, he should not have to quit the application he is working on in order to open the help
application. Ideally, it should run concurrently with any other application. This is obviously a
problem for non-windowed systems if the help system is independent of the application that is
running. However, in windowed systems there is no reason why a help facility should not be
available constantly, at the press of a button.
Accuracy and completeness
It may seem obvious to state that the assistance provided should be accurate and complete. But in an
age where applications are frequently updated, and different versions may be active at the same
time, it is not a trivial problem. However, if the assistance provided proves not to match the actual
behavior of the system the user will, at best, become disillusioned with the help facilities, and, at
worst, get into difficulties. As well as providing an accurate reflection of the current state of the
system, help should cover the whole system. This completeness is very important if the help
provided is to be used effectively. The designer cannot predict the parts of the system the user will
need help with, and must therefore assume that all parts must be supported. Finding no help
available on a topic of interest is guaranteed to frustrate the user.
Consistency
As we have noted, users require different types of help for different purposes. This implies that a
help system may incorporate a number of parts. The help provided by each of these must be
consistent with all the others and within itself. Online help should also be consistent with paper
documentation. It should be consistent in terms of content, terminology and style of presentation.
This is also an issue where applica- tions have internal user support these should be consistent
across the system. It is unhelpful if a command is described in one way here and in another there, or
if the way in which help is accessed varies across applications. In fact, consistency itself can be
thought of as a means of supporting the user since it reinforces learning of system usage.
Robustness
Help systems are often used by people who are in difficulty, perhaps because the system is behaving
unexpectedly or has failed altogether. It is important then that the help system itself should be
robust, both by correct error handling and pre- dictable behavior. The user should be able to rely on
being able to get assistance when required. For these reasons robustness is even more important for
help systems than for any other part of the system.
Page No 10
 University Roll No 1507884
Flexibility
Many help systems are rigid in that they will produce the same help message regard- less of the
expertise of the person seeking help or the context in which they are work- ing. A flexible help
system will allow each user to interact with it in a way appropriate to his needs. This will range
from designing a modularized interactive help system, through context-sensitive help, to a full-
blown adaptive help system, which will infer the users expertise and task.
CLASS DIAGRAM
Class diagrams describe the structure of the system in terms of classes and objects. The servlet api
class diagram will be as follows.

Page No 11
 University Roll No 1507884

5. To design and simulate the sensor-based interactive

system.
In incidental interactions it is very likely that sensors are not used solely for their original purpose.
This suggests the need for quite open architectures. For example, onCue uses a very open
blackboard-style architecture for exchanging information between self-discovering and self-
configuring components. Unfortunately, at the level of individual applications it is far harder to get
contextual information without writing special code for each potential application. This is one of the
reasons for using copy/cut to the clipboard as the main trigger it is one of the few cross-
application standards.
Furthermore, many of the contextual interactions envisaged in this area occur in domestic or other
private environments. If we are not careful, architectural openness could violate privacy imagine
if the can of beans (with intelligent food label) you just bought communicated back to the
manufacturer the contents of your food cupboard.
Highly contextual interactions must also take on board the fact that many of the most important
phenomena are not events (things that happen at specific moments), but status (things that always
have some measurable value). Statusevent analysis highlights common phenomena that can be
used to understand such systems, but this also impacts on the underlying system architectures.
Although there are many research and commercial systems being produced using sensors, there are
no clear standard architectures like the Seeheim model or MVC developed for traditional
interfaces. However, there are some fea- tures that are likely to be present in many systems.
Some sensor-based systems may employ quite simple sensors, for example the door open/closed
sensor for car courtesy lights. However, where the raw sensors are capturing richer data it may well
be that there is too much data to process fully. In these cases, the sensors may have to somehow
filter or pre-process their outputs before passing on their data. For example, the MediaCup senses
the temperature of the cup and pressure on the bottom of the cup, and has ball bearing sensors to
give approximate tip in two xy directions, all of which could be sensed many times per second and
at high resolution. However, only a small bit-mask with indicators such as hot/cold, moving/still is
sent via the infrared link to the network.
Component Diagram:

!
Page No 12
 University Roll No 1507884
Often the results from several sensors may need to be processed together to give a usable output.
For example, several heat sensors may be averaged. This is a form of data fusion bringing
together multiple data sources to build a more accurate
picture. This data fusion stage may also reduce the information; for example, the single average
from 10 individual temperature readings.
These processed sensor readings are then used to drive some form of inference. This may be a few
hand-coded rules: when Alisons MediaCup is moving she is in the office; more sophisticated
rule-based systems; or some form of neural network. This inference will typically interact with
some form of model of the users context built up over time. For example, if in the past the
ultrasound sensors have detected movement in a room and the pressure sensors under the doormat
have not been triggered, then the system knows there is likely to be someone there, even though
the ultrasound sensors currently detect no movement.
Finally, this contextual information has to be used. It may be used directly to drive some controlled
output, for example, the lights in the car or room heater. Alternatively, it may be used to modify the
effects of users actions based on the inferred context. For example, depending on who is believed
to be in the house and the time of day, the TV may default to different channels when it is turned on.

Page No 13
 University Roll No 1507884

6. To design and implement the eective interface for a

system which mitigates the human errors.
Reducing human error involves far more than taking disciplinary action against an individual. There
are a range of measures which are more effective controls including the design of the equipment,
job, procedures and training.
The design guidance developed consists of two forms: design principles and a three step process for
systematically addressing human errors in design. The relationships between the guidance
developed, human error occurrence and consequence in system operation, and conventional
engineering design and design change processes are shown in Figure below.
Human capability for interpreting and manipulating information is quite impres- sive. However, we
do make mistakes. Some are trivial, resulting in no more than temporary inconvenience or
annoyance. Others may be more serious, requiring substantial effort to correct. Occasionally an
error may have catastrophic effects, as we see when human error results in a plane crash or nuclear
plant leak.
Why do we make mistakes and can we avoid them? In order to answer the latter part of the question
we must first look at what is going on when we make an error. There are several different types of
error. As we saw in the last section some errors result from changes in the context of skilled
behavior. If a pattern of behavior has become automatic and we change some aspect of it, the more
familiar pattern may break through and cause an error. A familiar example of this is where we
intend to stop at the shop on the way home from work but in fact drive past. Here, the activ- ity of
driving home is the more familiar and overrides the less familiar intention.
Other errors result from an incorrect understanding, or model, of a situation or system. People build
their own theories to understand the causal behavior of sys- tems. These have been termed mental
models. They have a number of characteristics. Mental models are often partial: the person does not
have a full understanding of the working of the whole system. They are unstable and are subject to
change. They can be internally inconsistent, since the person may not have worked through the
logical consequences of their beliefs. They are often unscientific and may be based on super- stition
rather than evidence. Often they are based on an incorrect interpretation of the evidence.

Page No 14
 University Roll No 1507884

Page No 15
 University Roll No 1507884

7. To design and implement HCI for a critical system

involving human safety.
Safety analysis is a method for evaluating the hazards and risks posed by a system and ways to
minimize them. Many guidelines exist to guide safety analyses, but all study two main areas.
Hazard analysis is the first stage, in which the system is studied for situations in which potential
harm could result, and the frequency with which those situations occur. Risk analysis is the second
stage, in which the possible outcomes of the hazards and the frequency of appearance of each
outcome is determined. This allows sources of potential harm in the system to be prioritized and
dealt with to increase the safety of the system. Many standards exist for acceptable levels of safety
in different industries, but sometimes it is a judgement call as to when the system is safe enough. In
many cases, the best safety analyses are performed by those expert in the analysis techniques, and
novices are best tutored in the techniques before performing them independently. For embedded
systems in which there is the potential for harm to a person or the environment safety analysis can
be a useful way to quantify that potential and minimize it, but its most effective use lies in the hands
of those familiar with it.
We recognise that research involving human participants is an essential part of developing an
understanding of the factors underpinning health and diseases, and of assessing the safety and
effectiveness of biomedical and social interventions.
We support such research as a key part of our vision to achieve improvements in health. The first
priority for researchers should always be the protection of the rights, interests and safety of research
participants and we expect that research involving human participants should be undertaken in
accordance with the appropriate standards.

Page No 16
 University Roll No 1507884
Research & Teaching Involving Human Subjects
All research or teaching conducted under the auspices of UNBC involving the use of human
subjects, human tissue, human stem cells or data collected on human subjects must conform to the
UNBC Policy on Research Involving Human Participants and must have the prior approval of the
UNBC REB. In Canada, all human subject research is guided by the Tri-Council Policy Statement
on the Ethical Conduct for Research involving Human Subjects.
Please note that research involving human subjects, either directly or indirectly, even if non-
invasive to the person, should be submitted for prior approval by the REB. This includes all
research involving interviews, focus groups, aptitude testing, internet surveys, telephone polls or
psychological experiments.
Note also that this includes research conducted as part of a classroom project and work by students.
Faculty members who are in any doubt as to whether REB approval is necessary must consult the
Chair of the REB well before students begin classroom projects.
The Interagency Advisory Panel on Research Ethics has developed an Online Tutorial, TCPS 2:
Course on Research Ethics (CORE). It was designed to support the Canadian research community's
implementation of the 2nd edition of the Tri-Council Policy Statement for the Ethical Conduct for
Research Involving Humans (TCPS 2).
Northern Health
If you are conducting research in conjunction with Northern Health, please contact their Research
Review Committee for information on their review processes or visit their webpage at the link
below. You are also required to complete and attach the Northern Health Authority Supplement
form to your UNBC REB application, which can be found on our Forms page.

Page No 17