50120130406031

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &
ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME

TECHNOLOGY (IJCET)

ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online)
Volume 4, Issue 6, November - December (2013), pp. 269-283
© IAEME: www.iaeme.com/ijcet.asp
Journal Impact Factor (2013): 6.1302 (Calculated by GISI)
www.jifactor.com

IJCET
©IAEME

HCI FRAMEWORK TOWARDS GAP ANALYSIS AND EVALUATION OF
USABILITY FACTORS IN DISTRIBUTED SOFTWARE PROJECT
DEVELOPMENT
Dillip Kumar Mahapatra1,
1

Tanmaya Kumar Das2

(Head of the Department of Information Technology, Krupajal Engineering College/Biju Patnaik
University of Technology, Rourkela, Odisha, India,)
2
(Assistant Professor, Department of Computer Science & Engineering,
C.V Raman College of Engineering, Bhubaneswar, /Biju Patnaik University of Technology,
Rourkela, Odisha, India,)

ABSTRACT
The science of human-computer interaction (HCI) seeks to understand the constraints and
paradigms that define how people use technology. Cognitive science provides detailed knowledge of
how people perceive, understand, and remember information; HCI applies this knowledge to predict
how people will react to interfaces, and how those interfaces can be optimized for humans. Many of
the basic principles of HCI have a huge impact on usability, and a thorough grounding in these
concepts can help designers bring an informed perspective to unique interface problems. Humancomputer interaction (HCI) is a multi-disciplinary field with a focus on the interaction between
humans and computers. HCI emerged in the 1980s with a focus on usability of computer applications
and productivity of users. With the spread of computing, HCI researchers expanded interests to
include areas such as social computing, ubiquitous computing, creativity, accessibility, and
entertainment.
An interaction designer harmonizes form, content, and behaviour of interactive arte-facts;
both software and hardware, to deliver products that are useful, usable, and desirable. Interaction
designer defines “the structure and behaviour of interactive products and services and user
interactions with those products and services”.
Everyone who has experienced it knows that developing software in teams that are
distributed around the world can be a difficult and frustrating experience. In this paper we have
projected some views on usability factors of HCI framework and its importance in analysing GAP in
developing distributed software project.

269


KEYWORDS: Distributed Software Development, Human Centred Software Engineering, HCI
Process framework, GAP, HCSD Tools,
I.

INTRODUCTION

Like Distributed Software Development, HCI too gives a lot of emphasis on processes to
achieve usability and user experience goals. HCI literature suggests many processes, activities,
methods, skills, and deliverables. A typical HCI design process is made up one or more phases, each
of which may consist of one or more HCI activities. Each activity may be associated with one or
more methods. A method may require specific skills. An activity may result in a specific deliverable
that may be an end in itself, or may be an input for another activity in the HCI design process or the
software development process (Ref.02).
The last decade saw further expansion of the use of software beyond productivity and
automation. Interactive products played a very important role in leisure, entertainment, and
socialisation. In this context, the “quality of experience” afforded by a product to its users became a
broader quality attribute beyond usability. So what emotional responses does a Product trigger in the
users’ minds before, during, and after use? Was using the product a nice experience? Do users trust
the product? Do they feel confident while using it? Do they enjoy the experience? Do they feel
anxious, Proud, Drained? Do they save their time with the product and look forward to their next
session with it, or do they dread the ordeal?
In addition to usability, the answers to these questions determined the successes of products in the
last decade and promise to do so in the next few years as well.

II.
HUMAN COMPUTER
PROJECT DEVELOPMENT

INTERACTION

AND

DISTRIBUTED

SOFTWARE

Since the earliest days of computing, software development tools have been based on a
dangerous stereotype: development is done by a nerd alone in a box. In fact, when one observes
modern software development, it's a very social activity! Members of a development team
collaborate, co-operate, and learn from one another. Even the neediest programmer spends as much
time communicating with colleagues as studying code in an editor(Ref.04).
2.1

Human-Centred Software Development Tools
The Human Interactions in Programming (HIP) Group works at the intersection of Human
Computer Interface (HCI), Common Software Co-operative Work (CSCW), and Software
Engineering which leads to Human Centred Software Engineering (HCSE). HIP group includes
usability and human factors specialists, software and computer engineers, cognitive psychologists,
and artists and are meant for advancing the basic science and technology in human-centered software
systems development, human-computer interfaces engineering, usability and quality in use
engineering, empirical studies for software engineering through a program of fundamental research,
graduate education, as well as technology development (Ref.01).
Approximately half of the development time is spent for studying software development,
either through controlled experiments or hanging out with developers through implementation, and
the rest time is spent in creating new tools to help difficult situations that developers face, like being
a newcomer to a team with a lot of existing code or dealing with the interruptions and task switches
that break up a developer's day (Ref.05).

270


These two activities are mutually reinforcing: the studies inspire tools to build; and exploring
treatments that teaches more about the problems (Ref.05).
2.2

Distributed Software Development
Large-scale software development is a collaborative activity that requires diverse expertise
and substantial human resources. However, as a software project increases in size, it is often difficult
or impractical to concentrate all the necessary human resources in one location. Furthermore, today’s
advanced telecommunications and collaboration technologies provide an added incentive to
collaborate with geographically distributed colleagues but the fact remains that coordination in
distributed, large-scale software development is still problematic for many organizations because
working from a distance brings increased coordination overhead, reduced richness in communication
media, and more substantial delays (Ref.10).
The increased distance makes communication and coordination much harder. We're
emphasizing the research questions like:
• How can it be that the distant colleagues seem as "real" as local ones?
• How can the team knowledge be spread despite the distance?
• How do newcomers join remote teams when they lack face-to-face connections?
2.2.1 Knowledge Flow in Software Development Teams
Developers keep a lot of critical project information only in their heads. As a result,
developers' work is often blocked to look for information, and developers frequently interrupt each
others' work to ask questions. This approach enjoys certain benefits, like demand-driven production
of information that can be tailored to the asker's needs(Ref.12). But, the downsides are also
significant: knowledge loss due to team attrition; slow on boarding of new team members; and
productivity loss due to information seeking. In order to encourage better knowledge flow, some of
these research questions arise like:
• What are the most difficult and frustrating questions to find answers to?
• How much knowledge can we recover from existing team artefacts?
• How can it be encouraged more knowledge capture without impacting productivity?
• How do newcomers to teams learn from their more experienced colleagues?
2.2.2 Coordination and Processes of Software Development Teams
As Distributed Software Development (DSD) is a highly collaborative activity hence,
Developers work with people on their own team, and teams work with one another to create largescale software products. Within teams, development is split among people of differing roles such as
development, testing and requirements, and is governed by a development life cycle, historically
waterfall, but increasingly Agile. Dependencies between teams require communication, cooperation
and coordination for success, but problems in any of these areas lead to conflicts. In order to
understand how teams work well or poorly together, these research questions are likely to be
answered (Ref.09):
• What are the uses of agile methods?
• What are the work practices that help and hurt inter-team collaboration?
2.2.3 Spatial Representations of Code
As developers are frequently blocked and interrupted in their work, they often have to return
to tasks that have been put aside, sometimes for minutes, sometimes for months. Today's
development took place a large burden on a developer to find the documents they work on by
remembering a lot of symbol names -- the names of projects, files, bug reports, classes, methods, and
271


on and on. This memory tax means that developers spend a lot of time searching to find the
documents they previously worked on. In one line of our research, we are exploring the use of spatial
representations of development documents to allow developers to use spatial memory to find them
(Ref.02). So the questions arise here are;
• How do developers depict their code when they explain it to others?
• What are the navigation patterns, developer’s exhibit when working with code?
• What representations of code and other artefacts best support developers' work?
III.

HUMAN COMPUTER INTERACTION(HCI) PROCESS FRAMEWORK

Here we propose a multi-disciplinary process framework for HCI design as shown in fig.1
that includes phases, activities, methods, skills, and deliverables. This framework is proposed to be a
flexible way of understanding and communicating the work of HCI practitioners in different
contexts. Our objective is not to come up with another prescriptive a universal HCI design process
model, but to articulate the typical HCI activities within which several methods and deliverables can
be assimilated. Not all activities or methods may be essential in each instance of the process(Ref.11).

Figure 1: Framework for HCI design process.

272


This framework is divided into a number of phases. Each phase consists of one or more
activities. Each activity is associated with one or more methods. Each method requires specific skills
and could be associated with a particular discipline. Each activity results in specific deliverables. A
deliverable may be an end in itself, or may be an input for another activity in the HCI design process
or the distributed software development process. For example, usability evaluation is an HCI activity
that is a part of almost every process. Usability evaluation could be performed by several methods
such as a think-aloud test, a performance test, a heuristic evaluation, a cognitive walkthrough, or an
expert review. Performing each method requires a specific set of skills. E.g. the think-aloud test
requires skills in prototyping, qualitative test design, user recruitment, interviewing users, and
analysing data. The activity results in deliverables such as usability problems with the design,
potential ideas to improve the design, and possibly a decision about the future course of development
(Ref.13).
In this framework, eight HCI activities are identified and it is proposed and essential for
integration with Distributed Software Development (DSD) process models. We organise these
activities into four phases, in terms of four questions; what matters? How should we respond? How
should the design be detailed? How are we doing?
While the whole process is iterative, there are two inner loops as shown in Fig.-1: feasibility of the
product definition and redesign of the prototype to fix problems noticed. If required, it may be
necessary to go through these inner loops more than once, but going through them once will be
required for all projects (Ref.02).
3.1

ANALYZING THE FRAMEWORK
In the framework, not all elements are mandatory. While all activities are essential, the
specific methods mentioned above need not be used to do those activities. These methods are only
suggestive, and alternatives could be found (Ref.08).
Further, the deliverables are of two types: essential and optional. Some deliverables are
related to a particular method, and will emerge only if that method is used (e.g. work models,
affinity). Other deliverables are internal work products often preferred by HCI practitioners (such as
personas and storyboards), but not mandatory. However, some deliverables are essential for
completing the HCI design process (Ref.07).
The deliverables that could be considered essential in this framework from an HCI
perspective and the process framework maps on to the divergence, transformation, convergence
design stages. Many of the methods or techniques that help answer the question “what matters” and
some that help answer the question “how should we respond” are the ones that help the team in
divergence and problem setting. Many of the methods and techniques that help answer the questions
“how should we respond” and some of “how the design should be detailed” help in the transforming
the problem space so that a solution become evident(Ref.14).
Finally, the methods and techniques that help answer the questions “how should the design be
detailed” and “how are we doing” help in converging to a particular solution. These ideas are
summarised in Fig.2.

273


Figure 2: Divergence, transformation and convergence and the HCI design techniques and methods.
This framework describes the activities done by a multi-disciplinary team, including the HCI
disciplines, technology, business analysis, domain experts, and marketing. It should be seen as a
framework to design interactive products rather than a process framework to be followed by
designers.
IV.

ANALYZING GAPS

4.1

Human Computer Interaction Related Gaps
Distributed Software development(DSD) evolved in the context of the IT industry with the
objective of developing “methods and procedures for software development that can scale up for
large systems and that can be used to consistently produce high-quality software at low cost and with
a small cycle time”. Over the same period, computer software made its journey from high-end
scientific equipment to pervasive, almost invisible consumer products of the new millennium that
touch the lives of a large number of people. In the early 1990s, it was estimated that almost half of
the code in systems and 37-50% of efforts are related to the system's user interface. The share has
probably gone up today as computing has become more pervasive. As a result, the importance of
user centred design approaches has gained ground (Ref.15).

274


The fields of HCI and DSD have evolved independently in the past two and a half decades,
apparently almost completely unaware of each other until recently. There still exist major gaps
between HCI and DSD, both in academic institutions and in the industrial practice. The standard
curricula for each field make little if any reference to the other field and certainly do not teach how
to interact with the other field. There are major gaps of communication between the HCI and DSD
fields: the architectures, processes, methods, and vocabulary being used in each community are often
foreign to the other community.” Deliverables of one group are not evidently useful to the other,
hampering workflows. There is an apparent disconnect between the priorities of the two groups
(Ref.15). These gaps could lead to communication and coordination problems, duplication of effort,
compromises in the process, and eventually the quality of the output. There is a need to have shared
processes, common techniques, nomenclature, checkpoints, and measures for success).
The main goal of HCI activities is the same as that of Software process models, viz. to deliver
a high quality product to the end user to satisfy a human need or to solve a human problem.
However, skills and techniques required for doing HCI activities are quite different from the ones
required for doing the DSD activities (Ref.15).
As HCI activities utilise a specialised set of abilities, viz. broad-based designer aptitudes
such as sensitivity, creativity, ability to synthesise form, visualise, sketch and present ideas,
specialised HCI skills such as conducting user studies, analysing user needs, visualising scenarios,
user interface design, information visualisation, prototyping, and usability evaluation, and knowledge
in the areas such as cognitive psychology, ergonomics and social and cultural issues. These abilities
are themselves derived from several disciplines and each may take a lifetime to master. Quite clearly,
HCI is a specialisation distinctly different from traditional software engineering and having the
people with these skills in the team is important. The HCI practitioners must have process support
before they can deliver good quality usable software (Ref.15).
Firstly, skills must be converted into actionable activities. It is a common complaint by HCI
practitioners working in very process-compliant companies that they are seldom called upon to do
user studies or carry out usability evaluations or even allowed to meet the users. This happens
because the prescribed DSD processes adopted by the organisation do not demand that these HCI
activities need to happen (Ref.15).
Secondly, the activities must be done at the right time. For example, if requirements have
already been frozen before the HCI person is involved in the project, and if the use cases already
specify the strategy, scope and structure levels of user experience of the product, doing the activities
related to user needs identification, interaction design or information architecture at this stage may be
irrelevant.
Thirdly, the activities must result in the right kind of deliverables that must be used by the
rest of the team in the intended manner. Though the final deliverable is the user interface design, the
HCI team needs to produce several intermediate deliverables. Some of these are for use internally by
the HCI team members, for example analysis reports of individual interviews, a description of a
persona, or a set of screens tied together through a low-fidelity prototype. Some others are for
stakeholders from marketing, technology, or business to respond, for example findings from an
affinity diagram, or scenarios in the life of the persona. In addition, some others may be elements
that need to be incorporated in the product as is, for example the information architecture, hierarchy,
labels in a menu, colour, font, and size specifications, icons and layouts, or raw html pages. All these
outputs must be planned for and used appropriately(Ref.15).
Tools and techniques need to be put together to enable the HCI team to control their output
depending on the results of their own evaluations. Such tools need to go beyond the usual separation
of the presentation layer from the business logic.
Finally, there is a need for mutual trust and
respect between the team members from both disciplines for each other’s activities, deliverables, and
275


decisions. The problems of communication and power within the project existed between developers
and designers as each group defended their discipline. If the HCI design needs to be changed for
some reason, the HCI team must be consulted and given an opportunity to propose an alternative
rather than implementing a design that was deemed right by the programmers. In turn, the HCI team
must review the ongoing development work (Ref.15) regularly to keep track of changes and respond
to new situations quickly to match development cycles.
One obstacle is the deep-rooted myth that usability is not a central topic of DSD. Usability
activities are considered easily dispensable by a software project manager when the project is short
on budget or time. Another obstacle is the ambiguity associated with usability, the different
meanings it presents to different people. Claims about usability methods are hard to prove using
classical scientific techniques because of the difficulty in collecting statistically valid empirical
evidence.
Further obstacles come because HCI activities represent a paradigm of outside-in and holistic
development of products. The parts facing the users are developed first, the system internals later.
Organisations used to DSD paradigm of inside-out and modularised (or reductionist) design have a
natural tendency to resist this major paradigm shift. The social and cultural differences between the
people with HCI and DSD backgrounds do not help(Ref.15).
Gaps exist also in HCI and DSD research. Social and cultural differences play a role there as
well. Sutcliffe is sceptical about whether synthesis will ever emerge in DSD and HCI research for
social rather than intellectual reasons. Disciplines tend to have self perpetuating mechanisms since
they form communities that mutually support individual survival via peer review. Both HCI and
DSD have well developed areas of research, but many researchers in either field rarely reference the
other field, and the research seems to be motivated by quite different ideas (Ref.16).
4.2

Gaps in Real-Life Practices
The situation, where HCI practitioners and software Developers do collaborate, the main
impediment in implementing the HCI recommendations is actually the non-availability of time in the
projects. Infrequent contact leads to misperceptions and miscommunications between groups. There
appear to be important differences in how software Developers and HCI practitioners to answer the
question regarding who could done the testing of the usability of software. Software Developers
think quality assurance or software engineers themselves conducted these tests, while HCI
practitioners do think that they can handle it. To g(Ref.05)et a first-hand experience of the gap
between HCI and DSD, The following questions need to be answered;
• How and when do HCI design decisions happen in the SE process?
• What role do the HCI practitioners play? How do they influence the DSD process?
• What are the common objects between HCI and DSD process in use today?
• How are the concerns raised above about HCI and DSD integration handled?
4.3

HCI Inputs Are Not Taken During Requirements Specifications
The main issue that pointed out is that HCI inputs are needed early in the process before
requirements are finalised. Use cases in requirements documents routinely over-specified the HCI
design, including details such as the sequence and the contents of dialog boxes in the application.
This over-specification is happened possibly because there is a physical and cultural distance
between the developers and users, the development teams are less familiar with the context of users,
and the requirements specifiers want to have a control on the user interface (Ref.11).
HCI design process is not followed during requirements specification and HCI skills are not
used in most cases. Several participants have complained that customers do not state many usability
requirements explicitly or in responses to questionnaires. It is well known to the HCI practitioners
276


among the participants that such requirements could be captured by ethnographic user studies though
no such studies are carried out in most projects. Inappropriate HCI design decisions specified in use
cases seemed to have a ripple effect in many areas of user experience. HCI practitioners remarked
that once something is written up in a requirements document it gets “set in stone” and subsequent
changes, however desirable, become uphill. The only way solve this problem seems to be to involve
the HCI practitioners early in the project, certainly before freezing UI design, and possibly before
freezing on requirements. Early investment in HCI design makes business sense for users, customers
and the vendors. However, this happened in only 1 of the 8 cases. One related business problem
seemed to be particularly difficult to resolve to several participants. Requirements were typically
specified before a project contract was drawn up between the vendor and the customer.
Requirements were the basis on which project budgets and timelines are worked out. Rarely were
these services paid for, and there was a push on the part of the vendors to go through this phase as
soon as possible so that a concrete project materialised with minimum up-front investment. This has
implications not only on the HCI decisions made during this phase, but also to the other
commitments. However, this does not seem to be an insurmountable problem and some vendors have
managed to modify their business process to resolve this issue (Ref.15).
V.

PORTING PROJECTS GET MINIMAL HCI INPUTS

Every software project represents an opportunity to improve the user experience. Conversely,
every project also represents a risk of degrading the user experience. This applies even to porting and
migration projects. Less importance was given to requirements gathering in general and usability
requirements in particular in such projects. It was assumed that most requirements were wellunderstood and had to be “copied over” from earlier version. However, such ports often involve a
change of delivery platform, a change of context, or a change of users. Either of these can have a big
impact on HCI design and the corresponding requirements (Ref.11).
In one of the experiments (cases), the quality of user experience deteriorated significantly.
This project was to port a product from a legacy platform to a web-based application. The HCI team
studied screenshots of the existing application and reproduced them as closely as possible in a web
browser. They could not meet real users or observe them using the application. A particularly
important HCI issue was missed out completely. The application was a frequent use product and the
users often used keyboard shortcuts. This problem was discovered very late, after the client
representative had signed off and the first version of the product was delivered to the users. The task
completion times in the new software went up substantially, and the users rejected the product
altogether (Ref.09)
5.1

Client Representatives Take Design Decisions
In practice, a client representative routinely drives many HCI design and usability
considerations. Such a person may have never been a user himself or may have moved out of that
role a long time ago. His / her sign-off may not imply that the product is usable. This can be revealed
only by usability evaluations with real users. In the above case, users in the client organization
rejected the product even though the client representative had given his acceptance. The vendor had
to go in for a major re-write to introduce the keyboard shortcuts. The project was delayed
substantially (Ref.03).
5.2

HCI Skills Do Not Have Process Support
This point argued in the literature reviewed above was reinforced. Merely having skilled HCI
practitioners on the team did not resolve all HCI issues automatically. They also needed process
277


support to do their work. While most projects studied had some involvement of HCI practitioners,
they still ended with unresolved usability issues that they knew could be solved. A multi-disciplinary
team needs to work together. The team needs to be armed with appropriate user inputs and needs a
common set of work products and a common process to approach the product development
holistically and add value. Role of each discipline needs to be mutually understood and respected,
first within the team and then across the organization (Ref.16).
5.3
Too little and Too Late is Not Good Enough
In some projects, HCI practitioners were pulled in towards the end when too many obvious usability
problems surfaced (as seen by the client contact person). One HCI practitioner described these as
“last straw” projects, while another described his job as akin to “running an ambulance service”. In
these situations, HCI practitioners worked under severe constraints. Typically, the project would
have already spent its allotted budget and time and the HCI practitioners needed to hit the road
running. They had no time to understand the scope of the project and no budget to do usability
activities they wanted to do. Even if some HCI activities were done, most of the recommendations
they could come up to improve the UI seemed too impractical to implement in the given situation.
Few cosmetic changes would be made, mainly to satisfy the client representative, and the project
would be “pushed through” (Ref.08).
VII.

HCI AND USABILITY

HCI and usability have their origins in the falling prices of computers in the 1980s, when for
the first time, it was feasible for many employees to have their own personal computer (a.k.a PC).
For their first three decades of computing, almost all users were highly trained specialists of
expensive centralised equipment. A trend towards less well trained users began in the 1960s with the
introduction of timesharing and minicomputers. With the use of PCs in the 1980s, computer users
increasingly had no, or only basic, training on operating systems and applications software.
However, software design practices continued to implicitly assume knowledgeable and competent
users, who would be familiar with technical vocabularies and systems architectures, and also possess
an aptitude for solving problems arising from computer usage. Such implicit assumptions rapidly
became unacceptable. For the typical user, interactive computing became associated with constant
frustrations and consequent anxieties. Computers were obviously too hard to use for most users, and
often absolutely unusable. Usability thus became a key goal for the design of any interactive
software that would not be used by trained technical computer specialists. Popular terms such as
“user-friendly” entered everyday use. Both usability and user-friendliness were initially understood
to be a property of interactive software (Ref.11). Software either was usable or not. Unusable
software could be made usable through re-design.
Usability is a quality attribute that assesses how easy user interfaces are to use. The word
"usability" also refers to methods for improving ease-of-use during the design process. Usability is
defined by 5 quality components:
Learn ability: How easy is it for users to accomplish basic tasks the first time they encounter the
design?
• Efficiency: Once users have learned the design, how quickly can they perform tasks?
• Memorability: When users return to the design after a period of not using it, how easily can
they re-establish proficiency?
• Errors: How many errors do users make, how severe are these errors, and how easily can they
recover from the errors?
• Satisfaction: How pleasant is it to use the design?
278


There are many other important quality attributes. A key one is utility, which refers to the design's
functionality: Does it do what users need?
Usability and utility are equally important and together determine whether something is useful: It
matters little that something is easy if it's not what it is required. It's also no good if the system can
hypothetically do what we want, but we can't make it happen because the user interface is too
difficult. To study a design's utility, we can use the same user research methods that improve
usability.
Definition: Utility = whether it provides the features we need.
• Definition: Usability = how easy & pleasant these features are to use.
• Definition: Useful = usability + utility.
On the Web, usability is a necessary condition for survival. If a website is difficult to use,
people leave. If the homepage fails to clearly state what a company offers and what users can do on
the site, people leave. If users get lost on a website, they leave. If a website's information is hard to
read or doesn't answer users' key questions, they leave. Note a pattern here? There's no such thing as
a user reading a website manual or otherwise spending much time trying to figure out an interface.
There are plenty of other websites available; leaving is the first line of defence when users encounter
a difficulty (Ref.07).
The first law of e-commerce is that if users cannot find the product, they cannot buy it either.
For intranets, usability is a matter of employee productivity.
Current best practices call for spending about 10% of a design project's budget on usability.
On average, this will be more than double a website's desired quality metrics and slightly less than
double an intranet's quality metrics. For software and physical products, the improvements are
typically smaller, but still substantial — when we emphasize usability in the design process.
For internal design projects, think of doubling usability as cutting training budgets in half and
doubling the number of transactions employees perform per hour. For external designs, think of
doubling sales, doubling the number of registered users or customer leads, or doubling whatever
other desired goal motivated the design project. (Ref.05).
7.1

Improvising the Usability
There are many methods for studying usability, but the most basic and useful is user testing,
which has 3 components:
• Get hold of some representative users, such as customers for an e-commerce site or
employees for an intranet (in the latter case, they should work outside the department).
• Ask the users to perform representative tasks with the design.
• Observe what the users do, where they succeed, and where they have difficulties with the
user interface. Shut up and let the users do the talking.
It's important to test users individually and let them solve any problems on their own. If it is required
to help them or direct their attention to any particular part of the screen, then the test results are
contaminated. To identify a design's most important usability problems, testing 5 users is typically
enough. Rather than run a big, expensive study, it's a better use of resources to run many small tests
and revise the design between each one so that we can fix the usability flaws as we identify
them. Iterative design is the best way to increase the quality of user experience. The more versions
and interface ideas we test with users, the better. User testing is different from focus groups, which
are a poor way of evaluating design usability. Focu(Ref.04).s groups have a place in market research,
but to evaluate interaction designs we must closely observe individual users as they perform tasks
with the user interface. Listening to what people say is misleading: we have to watch what they
actually do.

279


7.2

Evaluating the Usability
Stability plays a role in each stage of the design process. The resulting need for multiple
studies is one reason we suggest making individual studies fast and cheap. Here are t(Ref.02).he
main steps:
1.Before starting the new design, test the old design to identify the good parts that should keep
or emphasize, and the bad parts that give users trouble.
2.Unless we work on an intranet, test our competitors' designs to get cheap data on a range of
alternative interfaces that have similar features to our own.
3.Conduct a field study to see how users behave in their natural habitat.
4.Make paper prototypes of one or more new design ideas and test them. The less time we
invest in these design ideas the better, because we need to change them all based on the test
results.
5.Refine the design ideas that test best through multiple iterations, gradually moving from lowfidelity prototyping to high-fidelity representations that run on the computer. Test each
iteration.
6.Inspect the design relative to established usability guidelines whether from earlier self studies
or published research.
7.Once we decide on and implement the final design, test it again. Subtle usability problems
always creep in during implementation.

Fig.3: Usability Evaluation Star Model.
Don't defer user testing until we have a fully implemented design. If so, it will be impossible
to fix the vast majority of the critical usability problems that the test uncovers. Many of these
problems are likely to be structural, and fixing them would require major re-architecting. The only
way to a high-quality user experience is to start user testing early in the design process and to keep
testing every step of the way(Ref.09).There exist multiple methods of evaluating usability depending
on available resources (time facilities and labor), evaluator experience, ability and preference, and
the stage of development of the tool under review. In broad terms it is worth making the following
distinctions between evaluation methods:
280


1. User-based: where a sample of the intended user tries to use the application.
2. Expert-based: where an HCI or usability expert makes an assessment of the application
3. Model-based: where an HCI expert employs formal methods to predict one or more criteria
of user performance
Finally, there are good reasons for thinking that the best approach to evaluating usability is to
combine methods e.g., using the expert-based approach to identify problems and inform the design
of a user-based test scenario, since the overlap between the outputs of these methods is only partial,
and a user-based test normally cannot cover as much of the interface as an expert-based method.
Obviously, where usability evaluation occurs throughout the design process, the deployment of
various methods at different stages is both useful and likely to lead to greater usability in the final
product (Ref.10).
7.3

Interaction Cost and Usability:
The interaction cost is the sum of efforts mental and physical efforts that the users must
deploy in interacting with a site in order to reach their goals. Ideally, we’d like users to go to a site
and find the answer they’re looking for right there, in front of their eyes. That would mean zero
interaction cost and is the holy grail of usability as a field. Unfortunately, zero interaction cost is
rarely attainable, since most sites and apps offer many things that users may want to do. Most of the
time, users have to look around, read, possibly scroll, find a promising link, click on it, wait for the
page to load, and then repeat the process all over. Someti (Ref.07).mes a new window may pop up on
top of the existing one, and in that case users have to switch attention to the new window and
perhaps also look back to the old one to integrate information in both windows. In other situations,
users may need to remember information on one page and apply it on a different one. All these
actions require cognitive effort and make up the interaction cost.
Usable sites minimize the interaction cost required to attain a variety of user goals. That is, they
minimize:
• reading
• scrolling
• looking around in order to find relevant information
• comprehending information presented
• clicking or touching (without making mistakes)
• typing
• page loads and waiting times
• attention switches
• Memory load – the information that users must remember in order to complete their task.
These user actions contribute differently to the total interaction cost. Their relative
importance may depend on the user – for example, dyslexic users may have a harder time reading
than clicking around, whereas users with motor impairments may find clicking more difficult. They
also depend on the device — a page load on a desktop connected to a high-speed network may be
insignificant, but a page load on a mobile device may take forever if the cellular coverage is slow.
Many usability guidelines address the question of minimizing the different components of the
interaction cost. For instance, the rules of writing for the web lower the cost of reading by
recommending bullet points and short, to-the-point sentences and paragraphs (Ref.06).
Marketing and branding usually have the job of increasing the user motivation and expected
benefits for engaging with a particular site or brand; usability deals with lowering the interaction
cost. Both methods are ultimately addressing the issue of increasing the expected utility of using a
site or a piece of software.

281


Reason for emphasizing Interaction Cost
Interaction cost is a direct measure of usability. In fact, the concept was introduced back in
the early days of Human-Computer Interaction to evaluate the us (Ref.13).ability of a software
system. All usability heuristics minimize the interaction cost for the user.
A quick assessment of the interaction cost of a design can save a lot of money on the long
run, as it can give us a good measure of how difficult the interface is going to be for the user. It can
also serve as a comparison tool between design alternatives: usually, the one that minimizes the
interaction cost has better chances of success.
VIII. CONCLUSION
"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. Large-scale software development is a collaborative activity that requires diverse
expertise and substantial human resources. However, as a software project increases in size, it is
often difficult or impractical to concentrate all the necessary human resources in one location. As
Distributed Software Development (DSD) is a highly collaborative activity hence, Developers work
with people on their own team, and teams work with one another to create large-scale software
products. Within teams, development is split among people of differing roles such as development,
testing and requirements, and is governed by a development life cycle.
A HCI framework is proposed in this paper which will be a flexible way of understanding
and communicating the work of HCI practitioners in different contexts. This is not to come up with
another prescriptive a universal HCI design process model, but to articulate the typical HCI activities
within which several methods and deliverables can be assimilated. Not all activities or methods may
be essential in each instance of the process. This framework is rather more suitable to address the
GAPs in the field of conducting distributed software development projects. Usability is a quality
attribute that assesses how easy user interfaces are to use can be assessed w.r.t. User-based, Expertbased and Model-based criterion where HCI plays important role under distributed software
environment.
REFERENCE
1.
2.
3.
4.

5.
6.
7.
8.

Joshi Anirudha, Sarda NL and Tripathi Sanjay Measuring Effectiveness of HCI Integration in
Software Development Processes,
Journal of Software Systems, 2010.
Nielsen J Agile Development Projects and Usability, November 17, 2008, Accessed March 7,
2009,
Joshi Anirudha HCI + SE Integration – Case Studies from Offshore Development Projects,
Workshop on increasing the impact of usability work in software development, ACM CHI,
2007.
Lifecycles, in Human Centred Software Engineering, Seffah A, Gulliksen J, and Desmarais
M (eds.), Springer, 2005.
Pressman R Software Engineering – a Practitioner’s Approach (6th Edition), McGraw Hill,
2005.
Shneiderman B Designing the User Interface: Strategies for Effective Human-Computer
Interaction (4th Edition), Addison Wesley, 2004.
Book: Harrison, Andrew, Paul Wheeler, and Carolyn Whitehead. The distributed workplace
sustainable work environments. London: Spon Press, 2004.
282


9.
10.
11.

12.
13.
14.
15.

16.

17.

18.

19.

20.

Hinds, P. J., & Bailey, D. E. (2003). Out of sight, out of sync: Understanding conflict in
distributed teams. Organization Science, 14(6), 615-632.
Royce W Managing the Development of Large Software Systems, IEEE WESCON, TRW,
1970.
Nelson E Extreme Programming vs. Interaction Design, 2002, Accessed August 8, 2009,
http://web.archive.org/web/20070313205440/http://www.fawcette.com/interviews/beck_coop
er/. http://www.useit.com/alertbox/agile-methods.html.
Nielsen J Usability Engineering, Morgan Kaufmann, 1993.
Olson, G. M. & Olson, J. S. (2000). Distance matters. Human-Computer Interaction, 15(2-3),
139-178.
Maznevski, M., & Chudoba, C. (2000). Bridging space over time: Global virtual team
dynamics and effectiveness. Organization Science, 11(5), 473-492.
Krauss, R. M. & Fussell, S. R. (1990). Mutual knowledge and communicative effectiveness.
In J. Galegher & R. E. Kraut, et al. (Eds.), Intellectual teamwork: Social and technological
foundations of cooperative work (pp. 111–145). Hillsdale, NJ, England: Lawrence Erlbaum
Associates
Clark, Herbert H. & Brennan, Susan E. (1991). Grounding in communication. In L. B.
Resnick, R. M. Levine, & S. D. Teasley (Eds.). Perspectives on socially shared cognition.
(pp. 127–149). Washington, DC: American Psychological Association.
Tanmaya Kumar Das, Dillip Kumar Mahapatra and Gopakrishna Pradhan, “An Integrated
Framework for Interoperable and Service Oriented Management of Large Scale Software”,
International Journal of Computer Engineering & Technology (IJCET), Volume 3, Issue 3,
2012, pp. 459 - 483, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
Dillip Kumar Mahapatra, Tanmaya Kumar Das and Gopakrishna Pradhan, “Guidelines for
Managing Distributed Software Project Under Deployment”, International Journal of
Computer Engineering & Technology (IJCET), Volume 4, Issue 1, 2013, pp. 34 - 45,
ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
Dillip Kumar Mahapatra and Gopa Krishna Pradhan, “Selection Criterion and
Implementation of Case Tools in Gap Analysis Towards Distributed Software Development”,
International Journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 3,
2013, pp. 389 - 409, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
Dillip Kumar Mahapatra and Tanmaya Kumar Das, “Towards Preventing Software from
Becoming Legacy: A Road Map”, International Journal of Computer Engineering &
Technology (IJCET), Volume 4, Issue 4, 2013, pp. 170 - 184, ISSN Print: 0976 – 6367,
ISSN Online: 0976 – 6375.

283

50120130406031

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (9)

Similaire à 50120130406031

Similaire à 50120130406031 (20)

Plus de IAEME Publication

Plus de IAEME Publication (20)

Dernier

Dernier (20)

50120130406031