Tips & Tricks
Your SlideShare is downloading.
Like this document? Why not share!
How to Make Vision Stick
by Maria Keckler
Capable Web: Chrome Apps and Firefo...
by Fred Lin
Cross channel testing insights an...
by Craig Sullivan
by Wajiha Samreen
Hoe word je een succesvol fashionbl...
by Kirsten Jassies
Email sent successfully!
Show related SlideShares at end
Dec 31, 2013
Comment goes here.
12 hours ago
Are you sure you want to
Your message goes here
Be the first to comment
Be the first to like this
Number of Embeds
Flagged as inappropriate
Flag as inappropriate
No notes for slide
Transcript of "50120130406031"
1. 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print), ISSN 0976 - 6375(Online), Volume 4, Issue 6, November - December (2013), © IAEME 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