USABILITY
-From Desire to Design
Tina Celia John
B.S., Jawaharlal Nehru Technological University, India, 2009
PROJECT
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
SOFTWARE ENGINEERING
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
FALL
2011
USABILITY
-From Desire to Design
A Project
by
Tina Celia John
Approved by:
__________________________________, Committee Chair
Ahmed Salem, Ph.D.
__________________________________, Second Reader
Robert Buckley.
____________________________
Date
ii
Student: Tina Celia John
I certify that this student has met the requirements for format contained in the University format
manual, and that this project is suitable for shelving in the Library and credit is to be awarded for
the Project.
__________________________, Graduate Coordinator
Nikrouz Faroughi, Ph.D.
Department of Computer Science
iii
________________
Date
Abstract
of
USABILITY
-From Desire to Design
by
Tina Celia John
Defined by the ISO as "The extent to which a product can be used by specified users to
achieve specified goals with effectiveness, efficiency, and satisfaction in a specified
context of use", Usability came to light when it slowly turned out to be the sole reason for
the failure of several software projects, both big and small. Though simple in definition,
it remains ambiguous in practice since there is no way to measure the human mind and
perception. Studies have shown and researches have proved that Usability is one of the
key factors for a product to thrive and survive in the market. The reason for this is that
Usability that was once restricted to being a measure of how efficient the User Interface
of a product is, has over the years, grown beyond those shackles and now stands
associated with not just the interface but the functionalities of a product as well. This new
face of Usability brings with it the need to reconsider the method in which Usability was
built into a project.
Usability was often discussed as a non-functional requirement during the Requirements
Gathering phase and then shelved until it was brought out while designing the interface
iv
for the product. But today, the whole idea of Usability has changed; it does not just focus
on the final interface, rather on the entire product. Due to this, it becomes essential for
developers to consider the idea of “ease-of-use” while designing the system itself. This
project thus proposes a new approach of incorporating the mental model of a user, as a
factor that needs to be considered while working through the Requirements and Design
phases. I intend to contribute an approach/ a model, which would be supported by a real
time example, to prove the same. In addition to it, I would like to come up with a
prototype of an automated tool that would implement the ideas proposed by my model. It
would help us rethink the generic method of designing, by giving us a new approach of
how to come up with a design that takes the user's mental model of what they do and
what they need to do and translates that into the design of the software. The entire focus
of this approach would be to keep the ultimate end user in mind while not just gathering
requirements or creating an interface but instead during the other phases of the project
development as well.
_______________________, Committee Chair
Ahmed Salem, Ph.D.
_______________________
Date
v
ACKNOWLEDGMENTS
I would like to take this opportunity to thank all the people who have been involved in
this project, without whose professional knowledge, guidance and encouragement, this
project would not have been successfully completed.
I would like to profoundly thank my project advisors, Dr. Ahmed Salem and Prof. Robert
Buckley, for giving me an opportunity to work under their guidance. Their professional
inputs, advice and corrections are the key ingredients that went into making this project a
success.
I would also like to thank Ms. Rachel Hernandez, User Acceptance Test Lead, CGI; for
being supportive and sparing her time to work with me and for accepting to incorporate
the ideas proposed by this project, as part of their work strategy.
I would like to specially thank my friend, Sandeep Pedditi, for contributing innovative
ideas and making my project an interesting experience. Last but not the least; Special
thanks to my family for their constant support and belief in me, though far away, their
every word of encouragement helped me fight all challenges and motivated me toward
successfully completing my project and earning my Masters Degree.
vi
TABLE OF CONTENTS
Page
Acknowledgments.............................................................................................................. vi
List of Tables ..................................................................................................................... ix
List of Figures ..................................................................................................................... x
Chapter
1. INTRODUCTION .......................................................................................................... 1
1.1.
The Need for Usability ......................................................................................... 1
2. BACKGROUND OF THE PROBLEM ......................................................................... 8
2.1. What is Usability? .................................................................................................... 8
2.2. Major Components of Usability ............................................................................... 8
3. REVIEW OF THE LITERATURE and METHODOLOGY ........................................ 15
3.1. User-Centered Design Approach............................................................................ 19
3.2.
User Analysis ..................................................................................................... 22
3.3.
User’s Mental Model .......................................................................................... 25
3.4.
Behavioral Model ............................................................................................... 32
3.5.
Task Analysis ..................................................................................................... 32
vii
3.6. Usability Testing .................................................................................................... 34
4. ‘YOU-I DESIGN’ TOOL ............................................................................................. 37
4.1. Introduction ............................................................................................................ 37
4.3. User Analysis ......................................................................................................... 39
4.4. Requirements .......................................................................................................... 42
4.6. Idea Proposed for “User Case Diagrams” .............................................................. 50
4.7. Paper Prototype ...................................................................................................... 56
4.8. Prototype Screenshots ............................................................................................ 63
5. CONCLUSIONS AND FUTURE WORK ................................................................... 70
5.1. Conclusion .............................................................................................................. 70
5.2. Future Work ........................................................................................................... 71
Appendix A ....................................................................................................................... 72
Bibliography ..................................................................................................................... 78
viii
LIST OF TABLES
Table 1: User Characteristics ......................................................................................................... 41
Table 2: High Level Requirements ................................................................................................ 42
Table 3: List of Detailed Requirements ......................................................................................... 42
Table 4: Hardware Interface Requirements ................................................................................... 44
Table 5: Software Requirements .................................................................................................... 44
Table 6: Login Scenario ................................................................................................................. 48
Table 7: Create Sticky Scenario ..................................................................................................... 49
Table 8: Create Scenarios Scenario ............................................................................................... 50
ix
LIST OF FIGURES
Figure 1: The DOS Prompt ................................................................................................. 3
Figure 2: Windows 1.0 GUI................................................................................................ 4
Figure 3: Windows 95 GUI................................................................................................. 5
Figure 4: The latest GUIs .................................................................................................... 6
Figure 5: Detailed SDLC .................................................................................................. 15
Figure 6: Modern SDLC versus Human Centered Systems Development Methodology 17
Figure 7: Mental Model .................................................................................................... 25
Figure 8: Overall System Design ...................................................................................... 33
Figure 9: System Use Case Diagram ................................................................................ 45
Figure 10: Administrator Functions Use Case Diagram ................................................... 46
Figure 11: User Functions ................................................................................................. 47
Figure 12: Use Case Diagram components ....................................................................... 51
Figure 13: Level 1 User Case Diagram ............................................................................. 52
Figure 14: Level 1 User Case Diagram ............................................................................. 53
Figure 15 : Level 3 User Case Diagram ............................................................................ 54
Figure 16: Login Screen.................................................................................................... 56
Figure 17: Welcome Screen .............................................................................................. 57
Figure 18 : List of options ................................................................................................. 58
Figure 19: Create a Sticky................................................................................................. 59
x
Figure 20: List all Stickies ................................................................................................ 60
Figure 21: Create Scenario................................................................................................ 61
Figure 22: User-Case Diagrams ........................................................................................ 62
Figure 23 : Welcome Screen ............................................................................................. 63
Figure 24 : Create Sticky Group ....................................................................................... 64
Figure 25 : Create New Sticky .......................................................................................... 65
Figure 26 : View Sticky List ............................................................................................. 66
Figure 27 : Create Scenario Group ................................................................................... 67
Figure 28 : List Scenario Groups ...................................................................................... 68
Figure 29 : Create New Scenario ...................................................................................... 69
xi
1
Chapter 1
INTRODUCTION
1.1. The Need for Usability
Defined by the ISO as "The extent to which a product can be used by specified users to
achieve specified goals with effectiveness, efficiency, and satisfaction in a specified
context of use", Usability came to light when it slowly turned out to be the sole reason for
the failure of several software projects, both big and small. Though simple in definition,
it remains ambiguous in practice since there is no way to measure the human mind and
perception. Studies have shown and researches have proved that Usability is one of the
key factors for a product to thrive and survive in the market. The reason for this is that
Usability that was once restricted to being a measure of how efficient the User Interface
of a product is, has over the years, grown beyond those shackles and now stands
associated with not just the interface but the functionalities of a product as well. This new
face of Usability brings with it the need to reconsider the method in which Usability was
built into a project.
Usability was often discussed as a non-functional requirement during the Requirements
Gathering phase and then shelved until it was brought out while designing the interface
for the product. But today, the whole idea of Usability has changed; it does not just focus
on the final interface, rather on the entire product. Due to this, it becomes essential for
developers to consider the idea of “ease-of-use” while designing the system itself. This
2
project thus proposes a new approach of incorporating the mental model of a user, as a
factor that needs to be considered while working through the Requirements and Design
phases. This project contributes an approach and a prototype of a tool, which would be
supported by a real time example, to prove the same. This approach would help us
rethink the generic method of designing, by giving us a new stand of how to come up
with a design that takes the user's mental model of what they do and what they need to do
and translates that into the design of the software. The entire focus of this approach
would be to keep the ultimate end user in mind while not just gathering requirements or
creating an interface but instead during the other phases of the project development as
well.
The four following figures will walk you straight into the importance of Usability and the
evolution of it thereof:
3
Figure 1: The DOS Prompt
4
Figure 2: Windows 1.0 GUI
5
Figure 3: Windows 95 GUI
6
Figure 4: The latest GUIs
Which one would you prefer? The answer is needless to say. The transition of software
products over the years has a story of its own to tell, the moral of which is: Usability lies
not just in impressive appearances but in how efficiently it helps users accomplish their
tasks.
7
1.2. Motivation
During my masters program, I had taken a “Human Computer Interface Design” course,
this course turned out to be an eye-opener. This course introduced to us a concept that
existed but never paid attention to; ‘Understanding the User’. I was very interested in the
concept and tried to research on it. The book, by Alan Cooper; ‘About Face- the
Essentials of Interaction Design’,[1] had very clearly listed what a goal directed design
should be like. My research then led me to find some real good papers that listed means
and methods of adopting the techniques of better Usability. Some of the techniques that
were widely being discussed were that of building a user Persona, creating scenarios,
storyboarding etc. To me, all these were excellent techniques, but there were two
thoughts constantly lingering in my head;
1. Where in the entire Software Development Life Cycle can I fit these
techniques?
2. How can I transform the output of these techniques into a good design?
It was these two thoughts that form the major ideas of my project. I began thinking
critically about how to go about my project when I recalled my professor’s words “When
you start a project, do not delve into the details of ‘How’ to implement it, rather spend
quality time on identifying ‘What’ needs to be accomplished!” Thus without delving
further into the details of how I intend to implement the proposed idea, I began to try to
draw a boundary around my understanding of usability, the outcome of which is listed in
the upcoming chapters of my paper.
8
Chapter 2
BACKGROUND OF THE PROBLEM
2.1. What is usability?
Usability is a quality that the system is built on, which certifies it to be easy to adapt to,
user-friendly, error tolerant, pleasing to the user not just by its looks and feel but also
through its functionality. A more clear and concise definition has been given by ISO as
“the extent to which a product can be used by specified users to achieve specified goals
with effectiveness, efficiency and satisfaction in a specified context of use”. The
methodology employed to achieve usability involves understanding the user that the
system is being built for, trying to relate to the tasks that the user would perform,
prioritizing these tasks to make a list of what’s more essential, designing the interface
keeping in mind all the attributes gathered from the study of the user and his perception
of the system.
2.2. Major Components of Usability
Designing a usable interface requires an understanding of the seven key components of
usability.[2] These seven components pose a challenge to the designers, challenging their
ability to come up with a design that would help users effortlessly work their way
through the product being built. It is these components that many a time serve as a
checklist for the designers as well.
9
The 7 key components are:

Learnability

Consistency

Memorability

Error Prevention

Efficiency

Satisfaction

Accessibility
The benefits of these components are enormous and their impact far reaching.
Considering these components in building a user interface not only assures a good
product but also a longer product lifetime. Designing a system fully using the
components of usability and testing early, often against representative users increases its
overall performance, acceptance, and likelihood of success. A brief overview of each of
these components should give you a better idea of why they stand as pillars that uphold
Usability;
2.2.1. Learnability
The learnability of a system is the ease with which users that are unfamiliar with the
System are able to accomplish their required tasks. From the beginning of the project, the
System’s design should maximize learnability.
10
The idea that learnability must come at the price of efficiency is a myth. In reality, the
two are interrelated. Increasing learnability means structuring tasks in such a way that
they are easy to learn and quick to accomplish. Learnability is often confused with the
idea of intrusive help; ease of learning should be accomplished by the simplicity of the
design, avoiding the need for users to work their way through bulky user manuals and
reference guides. An easily decipherable system speeds up the completion of tasks, even
for the experienced user. Thus designing for learnability involves more than just
providing step-by-step instruction; it calls for designers to pay attention to consistency
and memorability, while proposing the design of the interface.
2.2.2. Consistency
Consistency refers to the uniform application of common metaphors, concepts, terms,
processes, and visual elements across the System. Consistency can increase the
learnability and memorability of the System. Flexibility in the design of user interfaces
provides the developer with multiple ways to represent a given task. What might appear
to be the simplest way to perform a given task may not actually be the easiest if it is
inconsistent with the rest of the System. If a user must remember that a certain action has
two different results based on where they are in the System, the extra mental processing
required far outweighs any short-term savings in the individual task. This brings back the
discussion of a learning curve being involved in being able to adapt to a change in a
product or a new product itself.
11
2.2.3. Memorability
The memorability of a system refers to the ability of the System’s users to remember how
to use it after a period has elapsed, often weeks or months. Functional consistency helps
increase memorability. When users remember how to perform specified commands, they
spend less time searching. The most efficient users are those that know “where to go” to
perform their tasks. Other contributors to memorability include naming choices, logical
site structure/hierarchy, and the spatial arrangement of interface options. Spatial memory
is subtle yet incredibly powerful and should be cultivated wherever possible.
2.2.4. Error Prevention
Systems that prevent users from making mistakes, and allow users to recover if they
make mistakes, are more usable than Systems that do not prevent errors or do not allow
users to recover from mistakes. Users should feel free to explore the System. They should
be able to undo an action and then return to their place of origin. In addition, whenever
the user is about to commit a destructive action that cannot be undone (one that
permanently changes data or erases their previously entered data), they should be
presented with an appropriate opportunity to stop or confirm the action. Rather than slow
the user down, this undo option allows the user to feel comfortable and confident in their
environment, knowing that minor changes can be undone and that changes with a larger
impact do not occur without confirmation.
12
The goal is not to clutter the interface with alert boxes verifying at every corner that a
user is sure they want to do something, but rather to provide users with the ability to
avoid or easily correct their mistakes.
2.2.5. Efficiency
The efficiency with which the user can complete their tasks in the System affects its
usability. The previous four components all contribute to efficiency in a number of ways.
Users that are comfortable with their environment and its ability to help them prevent
errors tend to spend much less time contemplating their actions. Users that are familiar
with the System’s navigation and interface spend less time trying to master the mechanics
of the System and more time completing their tasks. Interface structure, navigation, data
representation, and text readability are additional factors that increase efficiency.
2.2.6. Satisfaction
Users’ subjective satisfaction with the System contributes directly the overall success of
the System. Users should perceive the System as an enabling tool rather than a barrier
between themselves and the tasks they need to accomplish. Under no circumstance
should users feel like the System is second-guessing their decisions. Most importantly,
users need to feel like they are in control of the System. Considering ease of use,
13
aesthetic design, and proper tone of language can help mitigate this disparity and increase
overall satisfaction.
2.2.7. Accessibility
Accessibility refers to the ability of a system to accommodate the largest possible
audience, including those users who may be disabled or who must access the System
using special assistive technologies. Accessibility involves more than providing a textonly version of the System. Accessibility means understanding all users and their needs.
Taking the steps to make the System accessible to all users increases the usability of the
System, not only for those individuals with special needs or disabilities, but also for all
users.
These 7 components clearly and concisely outline the importance of usability and the
factors that need to be considered therein.
The myth that does the rounds states that close communication with the user helps the
designer. Communicating with the user might help a designer or the usability team,
understand the problems a user faces, they may be able to figure out how to prevent
errors or how simple to make the interface but mere communication will not give the
designer any idea of the learnability, memorability, efficiency or satisfaction. To be able
to understand all that, a designer should go beyond words, he should observe the users,
14
their regular tasks, how they interact with the system or a similar system, actions
certainly speak louder than words! The kind of inputs that can be received from
observing and working with the user cannot be matched by even the best questions posed
to them.
“ Kenneth
Craik suggested in 1943 that the mind constructs "small-scale models" of
reality that it uses to anticipate events.”[15] This idea crept into the Human Computer
Interface world too and researchers started working on identifying a means to understand
the user’s mental models in order to build a system closest to their expectations.
Similar research and work have been covered by authors like Scott McDaniel, Alan
Cooper, Craig Tomlin and other researchers who have written articles and papers to
propose easy techniques to work with users and understand them better. Alan Cooper’s
team, at Cooper are working research and come with strategies that have formed a basis
for the ideas used in this project.[16]
“As designers and developers of a product, we are often too close and too attached to
what we make to see how something may not be obvious to an uninformed user.” – Pek
Pongpaet.[4]
15
Chapter 3
REVIEW OF THE LITERATURE and METHODOLOGY
A clear understanding of the components of Usability encouraged me to think further into
the two ideas I was to work on; the next step for me was to be able to incorporate the
usability piece into the SDLC so that it is introduced much earlier into the lifecycle of the
project, ensuring that it grows as the project grows. A study of the existing SDLC, made
me feel it’s complete, and that there was more than just a reason behind the software
industry to follow this rigid pattern of a life cycle model.
Figure 5: Detailed SDLC
16
There have been countless articles and numerous studies on the SDLC and researchers
have given it their best shot, trying to modify it seemed nothing but impossible to me; It
was then that I stumbled upon a white paper, one I consider very well written;
‘Integrating HCI in SDLC’[4]. Written by a group of professors, this article clearly
chalks out the ideology of incorporating, in their case Human Computer Interaction, into
the SDLC. They proposed a new SDLC model, named ‘Human-Centered Systems
Development Life Cycle (HCSDLC) Model’.
There is a lack of clarity about Usability (precisely Human Computer Interaction) and its
role in the systems development life cycle (SDLC). One pre-existing myth that has
blinded the software industry is that usability is only about the final user interface design,
such as format, menu layouts, choice of colors, icon design, and screen layouts etc. Many
popular textbooks and courses contain only one or two chapters in the design stage of
SDLC to cover user interface issues. What we often overlook is the fact that users are
most frustrated or annoyed by problems that are way beyond the computer screen level.
Illogical overall organization of data/information in the system, lack of task support,
misfit between the nature of the task and the support provided, difficulty of navigation,
and inconsistent mental models of system operation are among the major problems or
difficulties users’ experience.[4] These incompatibilities may affect user reaction,
acceptance, and use of the system. These issues critically affect users’ interaction with
the system, they can even lead to the system being completely rejected by the users,
17
leading to failure of the entire project. This can be avoided by addressing such issues
during usability development practices. A better understanding of various human
cognitive, affective, and behavioral factors involved in users’ tasks, problem solving
processes and interaction contexts is required to address these problems. The new
‘Human-Centered Systems Development Life Cycle (HCSDLC) Model’ proposed versus
the already existing model is well depicted in the figure below:
Figure 6: (a) Modern SDLC versus (b) Human Centered Systems Development Methodology
18
This model sparked new thoughts as the future work of this paper welcomed anyone to
think further and implement detailed steps into each of these phases.
I studied the model further and came to a consensus that this was indeed a perfect step for
developers/designers not just to start thinking about usability but also to start involving
the users, only then can usability be a effectively designed as part of the System design.
The only point that I did not quite agree with was the position of the User Acceptance test
phase, I would rather have it after the Task Analysis step. Having a good understanding
of the user, the tasks intended to be performed and the functionality the system is entitled
to comprise of, would give the developers a clearer mindset of the kind of test cases to
come up with and also lets them anticipate the users’ expectations.
Now that we have seen how and where in the SDLC, the feature of Usability designing
can be incorporated, the rest of the paper focuses on outlining a strategy to accomplish it.
In a nut shell, this paper talks about:

Adopting the User-Centered Design approach

Techniques of understanding the users ( ie. Users’ Mental models and Behavioral
Models)

Methods of communicating users’ needs

Actions to validate that the designers are moving in the right direction and

Finally, a prototype of a potential tool that will help capture all the above
mentioned actions.
19
3.1. User-Centered Design approach
The User-Centered Design Approach, can be defined as ‘a process that emphasizes on the
end user, his needs, his wants and his expectations toward the system being built.’ These
desires of the user are given extensive attention through each stage of the design process,
as designers work to design a system that best fits the identified requests. The usercentered design process in no magic, it has been built by understanding the psychology of
the users’. This approach was proposed after years of research and several experiments,
which resulted in not just a theoretical process but also outlines a set of practical steps
that can be put to use instantly.
User-Centered Design encompasses 3 key features:
1. Observing and understanding the users of the system – This step is the most critical in
the UCD process since it forms a bases for the rest of the process. It is the goal of the
designers or usability team, to observe the users and the activities they perform. This
kind of observation is done in the users’ natural environment, so that he is
comfortable with his surroundings and works normally. All conclusions and
observations are drawn from looking at the users work; this limits the need for
designers to make assumptions.
This step can be considered complete when
designers are able to answer the following questions:

Who are the users of the system?
20

What are the users’ tasks and goals?

What are the users’ experience levels with the system or similar systems?
These three questions are summed up as the Users’ Mental Models and Behavioral
Models. These aspects are discussed in detail in the User Analysis section. Based on
the observations made, designers are required to come up with a Persona or in other
words, a ‘Virtual User’ of the system. This persona has a name and a form; this gives
it a more realistic edge. The persona is considered to be the perfect user of the system,
some of the characteristics are:

It portrays all the requirements proposed by the users

Has the skill set and experience level of the users

Meets the demographic constraints and cognitive intelligence similar to that
observed in the users.
2. Designing for the Persona - All the effort put into reading the users and building a
persona gets paid off here. Designers now need not consider the hundreds of users;
they can just keep the one persona in mind. They can build prototypes and validate it
against the persona’s limitations and traits; they can question the designs built as well,
before presenting it to the user himself. This step is considered complete when the
designer can clearly see through the following questions:
21

What functions do the users need from the system?

What information might the users need, and in what form do they need it?

How do users think the system should work?
3. Working with the users throughout the designing process – The glue that binds this
entire process is the user. Working with the user is thus the key to the user-centered
design approach. The only golden rule that is followed throughout this process is
‘Involve the user by consulting, validating and questioning every action and
assumption that will transform into the final system design.’ Once the design is built
right, the system will follow pursuit.
These are the simple steps of adapting the User-Centered Design approach.
The myth that does the rounds in the development world is the only limitation to this
approach ‘This approach is cumbersome and the level of detail is not required for every
project.’ Agile Development teams have adapted this approach and certify that this
preliminary work saves tons of ‘trace back and revert’ time in the end, thus conserving
cost and resources.
22
3.2. User analysis
User Analysis simply implies, studying the user and coming to a consensus of who he is,
what he desires versus what he needs and his expectations. The more effort put into
identifying these traits will reap fruitful results, ensuring a smooth flow of the
development process. It is via this process that the usability team needs to identify the
target users and their characteristics.
These characteristics include Demographic data, such as age, gender, education,
occupation, cultural background, any special needs, computer training and knowledge,
experience with similar systems/products, etc. Traits and intelligence, such as cognitive
styles, affective traits, and skill sets or capability; and Job or task related factors, such as
job characteristics, knowledge of application domain and job familiarity, frequency of
computer use for the job and usage constraints.[5]
Surveys and questionnaires can be useful in collecting demographic data. They can help
determine the users' prior knowledge and level comfort with the tasks to be performed.
Another technique known as Contextual Inquiry, involves observation at the user's work
site. This method is used because a user’s understanding of his work often depends on
being in the actual work environment. Users may not accurately describe the work that
they do correctly or comprehensively, during an interview or via a research, most of their
work may be implicitly understood or performed in a habitual manner. In contextual
inquiry, evaluators observe and record a user's actions as they go about a typical work
23
day. A great deal of information can be gathered about the user's environment, workflow,
business processes, and use of technology.
While all the above mentioned traits give you an understanding of whom the system will
be presented to, it is also very important to understand ‘what is the users’ expectation of
the system that is going to be presented to them’. It is certainly a challenge for the
usability team to understand the users’ perceptions, since these are more so impalpable
characteristics that are innate in a person’s mind. Listed below are the three factors that
play a key role in forming an idea in a person’s mind, they are:
1. Perception - Perception relates to the way people acquire and organise sensory
information. It involves the acquisition of information through the classic five
senses (sight, hearing, smell, taste, touch) and processing it to relate it to a past
memory or in creating a new memory of it. Of the 5 senses, ‘sight’ is the primary
sense used in many situations and the one that is most relevant for the design of
computer-based systems. Usable systems recognise the users’ perceptual abilities
and limitations and allow them to use this sense in adapting to the tasks to be
performed.
2. Decision making - People believe that decisions are made in a logical way by
evaluating options and making rational decisions. In practice, most decisions are
not made this way, we rather satisfy ourselves by accepting the first reasonable
24
answer that fits the situation. Designers of systems that help people to make
decisions (such as information systems) should thus recognise that users are likely
to use the first set of information they see, they may not read beyond that, much
less go scrambling around looking for a hidden function. It is very unlikely for
them to want to read pop-ups or corrective messages that would flair off the idea
of them being wrong each time.
3. Information seeking behaviour - Most information seeking behaviour is one of
two types:
a. Known-item: People know exactly what information they are looking
for, know that it exists and know how to describe what they are
looking for.
b. Exploratory (unknown item): People are not sure what information
they are looking for, may not know how much information there is and
do not know how to describe what they want.
Some methods of information retrieval suit some tasks better than others,
requiring an understanding of how people will approach a particular set of
information.[6] These guidelines thus help streamline the minds of the designers,
leading them to think more critically about the users they are to design the system
25
for. Once this thought process in brought to action, the next step would be to
identify the User’s Mental Model.
3.3. User’s Mental Model
The latest new invention is that of a tablet; imagine you are the user and you are asked to
read a book on the tablet. The very first thing that comes into your mind is a book and
you would try to find a similar approach of reading it on your new device as you had read
it the traditional way. This perception is nothing but the mental model of the user.
Figure 7: Mental Model
26
Susan Carey’s 1986 journal article, Cognitive science and science education, most aptly
describes mental models: A mental model represents a person’s thought process for how
something works (i.e., a person’s understanding of the surrounding world). Mental
models are based on incomplete facts, past experiences, and even intuitive perceptions.
They help shape actions and behavior, influence what people pay attention to in
complicated situations, and define how people approach and solve problems.
3.3.1.
How Can Mental Models Be Applied in Software Design?
Software interfaces should be designed to help users build productive mental models
of a system. [7] Common design methods employed to support and influence users’
mental models include: simplicity, familiarity, availability, feedback, safety, and
affordances.
i. Simplicity
Since mental models simplify reality, interface design should simplify actual
computer functions. A function should only be included if a task analysis shows it is
needed. Basic, most frequently used functions should be more apparent and easily
accessible, while advanced functions should be less obvious to users. Cluttering an
interface with many advanced functions only distracts users from accomplishing their
27
goals. A well-organized interface that supports users’ tasks fades into the background
and allows the user to work efficiently.
Experiment:

Aim: To observe how users react to different User Interfaces.

Process: Present the user with the two search engines, Google and Yahoo.
Observe their reaction and work strategy with each.

Target users: Users of the age groups 17, 47, 77 who have basic computer
skills.

Date conducted: 06/20/2011

Results: The final observation showed how the users instantly used the search
functionality in Google whereas they got distracted by the news bits and other
links on the Yahoo page. The 77 yr old was hesitant to click on any link on
the Yahoo page as he feared that some irrevocable change would occur. The
completely filled web page was distracting in comparison Google which was
clear and had limited, relevant options.
ii. Familiarity
The ability to relate to an object seen, used or come across in the past makes a person
feel that he is familiar with it. This concept should be adapted in design as well; an
interface should allow users to build on prior knowledge, or experience gained from
interacting with objects in the real world. The use of concepts and techniques that
28
users already understand from their real world experiences creates a level of comfort
instantly, this allows them to relate to the system and adapt to it easily. Creating this
kind of a comfort zone, not only gives the user the courage to use the system, it also
encourages him to explore more without the fear of him going wrong.
Advance concepts and techniques can be learned as and when the requirement arises.
By choosing to be consistent with something the user already understands, an
interface can be made easier to learn, more productive, and even fun to use. [8]
iii. Availability
An interface should provide visual cues, reminders, lists of choices, and other aids,
either automatically or on request. Humans are much better at recognizing things than
at recalling them. Users should never have to rely on their own memory for
something the system already knows, such as previous settings, file names, and other
interface details. The availability of the required options clearly presented adds to the
ease of usage tremendously. A user need not have a skill set in order to use a well
designed and clearly built interface.
iv. Feedback
A system should provide complete and continuous feedback to the user, about the
results of his actions. Any feedback a user gets that supports their current mental
model strengthens it. Feedback that contradicts the current mental model should be
29
presented by supportive error messages, warnings or responses that will help the user
to learn from it and adapt to the change. Immediate feedback should be available as
that’s the only way a user can assess if his expected outcome was the result of his
actions or not. A system that does not give feedbacks poses a risk of being considered
as a ‘non-responsive’ interface.
v. Safety
A user's actions should yield expected results. Let’s take an example: If a user sees a
but-con with number on it, clicking it should generate a number on the screen, if a
character appears or some unexpected symbol, it would only surprise the user and
confuse him. Users should feel confident in exploring, knowing they can try an
action, view the result, and undo the action if the result is unacceptable.[8] Users feel
more comfortable with interfaces in which their actions do not cause irreversible
consequences.
vi. Affordances
An affordance refers to the properties of an object; it provides clues to how an object
can be used. Perceived affordance is what a person thinks can be done with an object.
When an interface is built, taking into consideration the affordances by using realworld representations of objects in the interface, users will intuitively know what to
do with the object just by looking at it. For example, the camera application in the
30
latest mobiles; a camera in the real world has specific functions like clicking a photo,
focusing, zooming etc. the components that are used to perform these functions are a
lens, click button, zoom in and zoom out switches, power on and off. Using similar
kind of an interface and interaction keys will help users relate to it immediately and
they will be able to use their mobiles without much effort or learning. This is an
instance of how affordances can be used to better design an interface. [10]
3.3.2. Working with Users to Capture and Validate Users' Mental Models
Mental models are a result of people's tendency to form explanations of things they
see, interact with or perceive in the world.
“Users tend to assume causal relationships when one event immediately follows
another. For example, you download a file from the Internet and then your computer
crashes. Most people will blame the downloaded file for the crash. The timing of
events seems to infer a cause and effect relationship. In reality, there may be no
connection at all between the two events.
Users tend to create anthropomorphic mental models when interacting with software.
They will describe the system as "reading" what is typed in, or "asking me to save."
Even more advanced users will curse at their computers when they don't get the
expected response.” [1]
31
Another innate behavior is that people tend to blame themselves when they have
difficulties using a system, especially when they believe that others are able to use the
system and that the task is not very complex. In fact, the problem may be a design
flaw and many people may have the same problems but they would have just
accepted it and try to find a work around or maybe just ignore the issue sometimes.
Sometimes it could simply be that the users feel guilty assuming it is their lack of
skill and do not want to admit that they are having trouble or do not understand how a
system works.[13]
In order to decipher the mental models of the users and to be able to look at the
product from their point of view, several techniques have been devised. Some of the
top rated techniques, that have proven to draw tremendous results, are listed below:
Design walk through sessions, Paper prototyping, Blue prints of the design and finally
leading into User Acceptance testing. But before stepping into user acceptance
testing, some other parameters need to be determined. All this while we have been
focusing on understanding the user’s mental model, an effort needs to be put in to
understand how to translate these ideas into concrete functionalities. To determine
this, the designers need to understand what tasks are intended to be performed by the
users. The behavior model and task analysis help unravel this aspect.
32
3.4. Behavioral Model
It does not suffice if the mental model of a user is understood, we need to bridge the gap
between the user and the system; this bridge came in the form of a Conceptual /
Behavioral model. In order to understand why mental models are so important to
designing user interfaces, you have to also understand what a behavioral model is. A
conceptual model is the actual model that is given to the user through the interface of the
product. Consider the example of an eBook; you have a mental model about what reading
a book will be like on the Kindle, how it will work, and what you can do with it. But
when you sit down with the Kindle, the “system” (the Kindle) will display what the
conceptual model of the book actually is. There will be screens, and buttons, and things
that happen. The actual interface is representing the conceptual model. Someone
designed a user interface and that interface is communicating to you the conceptual
model of the product. Understanding this behavioral model and synchronizing it with the
mental model of the user will help in efficient and smart design. Task analysis is a good
place to start working on the Behavior model. What then is Task Analysis?
3.5. Task Analysis
Task analysis is the process of identifying and understanding users' goals and tasks, the
strategies they use to perform the tasks, the tools they currently use, any problems they
experience, and the changes they would like to see in their tasks and tools. Tasks may
include those that involve the computer and those that are manually performed.[11] For
33
example, a task analysis of a camera app on a mobile, the main tasks the user can relate to
it are focusing on a point, zooming in and out, taking a picture, recording a video, etc.
Thus looking at all the above mentioned models and how they lead into design, we have a
proposed new design module for User Interface design that takes shape from the
combination of the Mental model and the Behavioral model.
Figure 8: Overall System Design
34
3.6. Usability Testing
As important as it is to be able to build usability into the system, that important it is to be
able to rightly test the usability of a system. Thus it does not suffice if a system is
considered to be user friendly after all the requirements are gathered and after following
the above specified standards, we also need to perform the right tests to confirm that we
have indeed met all our requirements. I believe that the test would be complete only when
it is validated by the users themselves.
A team that has been working on understanding the user’s mental model, behavioral
model and part took in the Persona building and story boarding kind of activities,
according to me are the ones that would form a good test team to validate usability. This
Usability team should perform testing early on. Usability testing should involve the
following:

A group of test users who are a representative sample of the user population and who
are not involved with the design of the project

A prototype model with which the users may interact

A set of scenarios that prompt the users to interact with the prototype

A facilitator to introduce and administer the test

A group of observers who document the users’ behavior
35
3.6.1. Low-Fidelity Testing
Low-fidelity testing makes use of a paper prototype to test early decisions made in the
design of the user interface. The user interacts with the drawings as though they were the
pages of a System application by writing on the prototype where they would normally
type and by pointing to buttons they would normally click. Detailed prototypes are
difficult to create, whereas low-fidelity paper prototypes are quick and inexpensive to
create. Screens are hand-drawn with pen and ink and deliberately made to look
spontaneous and imprecise. It is important that the level of detail in the prototypes invite
the right kind of feedback. Prototypes that are too precise and look as though someone
has painstakingly drawn them invite the user to scrutinize the details of the prototype
rather than its content. The user will point out that the fields are out of alignment, that the
colors do not match, or that not enough spacing exists between sections, rather than the
more useful feedback that information is missing from the page, or that the order of
events does not make sense. Low-fidelity testing not only makes the System more usable,
it reveals the kinds of errors early that are very expensive to fix later in the design
process.
3.6.2. High-Fidelity Testing
In high-fidelity testing, users interact with a detailed computer-based prototype, such as a
HyperText Markup Language (HTML) mockup of the application, rather than paperbased prototypes. High-fidelity testing focuses on the details of the interface that a hand-
36
drawn prototype cannot convey. High fidelity testing sessions should begin shortly after
low-fidelity testing, when opportunities still exist to modify the application with minimal
expense.
37
Chapter 4
‘YOU-I DESIGN’ TOOL
4.1. Introduction
The entire concept of the UI designing thus far was presented to the User Acceptance
Test team at ACS, Xerox. The team lead, Ms. Rachel Hernandez was very impressed
with the ideas proposed but pointed out the issue that most often, the user acceptance
community tries to follow these methods but due to tight timelines, constraints in budgets
and less availability of the right tools, it gets dropped and traditional methods are
adapted. Well the tight timelines and budget issues are managerial concerns but the nonavailability of a tool is a resolvable constraint. Thus I proposed the idea of a tool, the
‘You-I Design’ tool, to handle UAT concerns.
The first step of the process was to have a meeting with the team to understand the
problems they are facing currently and what issues would they like for the tool to
incorporate. Apart from this, I began to research some of the common problems UAT
teams face in their normal work processes. Some of the common problems are listed
below;

The Problem:
o Requirements are documented in never ending paragraphs
o Wordy requirements are ambiguous
38
o Sticky notes are used and then placed on a white board, to refer to these
notes, you need to go to the white board each time
o All discussions and decisions are made during meetings, ideas that come
up during other times need to wait for the next meeting to be presented
o The option of scenarios was not considered or more so verbally discussed
to a brief extent.
o Diagrams are drawn to present ideas to the users, these diagrams have no
formal representation, or standard that’s followed. Thus they vary
according to the requirement.

The solution:
Taking into consideration all these high level requirements, I proposed to come
up with a prototype of a tool that can resolve if not all, at least some of the issues
faced by not just the ACS UAT but the user acceptance test teams in the industry
as a whole. The main focus of this tool would be to serve as a simple level one
documentation tool. It merely replaces processes that need a paper or a white
board. After all the decisions are made through using this tool, the final ideas can
be documented in a well formulated business process tool like DOORS or RQM.
39
4.2. Scope
This project presents the requirements, design and a working prototype of the
proposed system. The main aim of this tool is to satisfy and provide a simple
checklist to the teams working on user acceptance tasks. The requirements for this
tool were gathered from the client, in this case, the user acceptance test team from
ACS. The work process of this tool follows the ideas proposed by the paper.
4.3. User Analysis
i. Method:
The users are a set of 5 team members who are part of the user acceptance test
team. They have good knowledge of the technical world and have been working
with computers, having hands on experience with tools. They have a clear idea of
the techniques that can be used for user acceptance. Most of them are good in
analysis and documentation but not in technical stands. I have observed this group
working in their regular work environments, this gave me a better understanding
and insight into what best would suit their needs. As we sat to have lunch one day,
I put forth a question: “If you were to create a tool that would help assist the UA
team, what would it be like?” This was an open question and they did not know
that their inputs would indeed be seriously considered. This was a good way to
get information as they were not formal or very critical about what they said; each
one proposed what they thought was a good way of improving the process and
40
proposed their ideas. I think instead of starting off with formal meetings and
throwing the users in the limelight, its better to pose a question as to what they
would do if given a choice. This should not impact the designer but it would
certainly help him understand the mental model of the user.
To get concrete results and validate them instantly with the user, later on, a formal
meeting was organized, where I put forth my idea to the team, the team instantly
liked the proposal, accepting to give inputs, feedbacks and be the clients for the
project. The requirements gathered from them are documented as High Level
Requirements.
ii. Observations:
In a nut shell; from the discussions we had and observations made, I noticed that
this team relies on the white board the most. Since it is a test team, they go
through the following process:

Get test requirements from the development team

Build their test matrix and come up with the detailed requirements

Verify these requirements with the users to confirm that its apt
Internal process:

List out the requirements that they think are critical, on a white board
41

Have a discussion about each requirement and group them into categories
that can be used for future analysis.

The team lead assigns a member to keep track of the listed requirements;
that are then copied into DOORS, an IBM rational tool that they use to
track requirements.

Meetings are held with the design team and paper prototypes are created.

Meetings are arranged with users to validate these designs and
requirements.

The inputs are communicated with the design team from time to time and
prototypes are built to support the improvements.
The user’s mental model relates to the tasks performed on paper or via a white board
so a simple design of the tool which can resemble the same will be apt to solve the
purpose.
User Characteristics:
Table 1: User Characteristics
Administrator
Team
●
Create users for the tool
●
Logs in to the tool
●
Performs all activities as a
●
List requirements
42
Administrator
Team
member of the team
●
Create Scenarios
●
Link use case diagrams
●
Link prototypes
4.4. Requirements
Table 2: High Level Requirements
Requirement ID
Requirement Description
R1
Tool that can be shared among the team
R2
List requirements and classify them as groups
R3
Create scenarios based on the group of requirements
R4
Draw or link diagrams to represent the tasks and
functions identified for the user.
R5
Upload and link prototypes
4.4.1. Detailed Requirements:
Table 3: List of Detailed Requirements
43
ID
Description
Input
Input
Method
Input
Validity
User ID
Password
Manual
Not
NULL
R 2 List requirements and create
groups
 Create a new requirement by
typing it in as a sticky
 Assign a group to the sticky
 View all the stickys
Requirement Manual
Group
Not
NULL
R 3 Create scenarios based on the
group of requirements
 View sticky groups,
 Create a scenario for each
group to determine the tasks
associated with each
Scenarios
Manual
Not
NULL
R 4 Draw or link diagrams to
represent the tasks and functions
identified for the user.
 Draw diagrams to represent
the tasks associated with the
user
 Save diagrams and upload
them to link them to the
scenario and sticky group
Diagrams
File
Upload
R 5 Create/Upload and link prototypes Diagrams
(This is an additional requirement
that was proposed as a good idea for
File
Upload
R 1 Tool to be shared among the team
The tool must provide the ability to
have user logins.




Assign user id
Create default passwords for
logging in to user accounts.
Deletes user accounts
Resets Passwords
44
ID
Description
Input
Input
Method
Input
Validity
future enhancements)
4.4.2. Hardware Interface
Required hardware configuration must satisfy at a minimum, the following:
Table 4: Hardware Interface Requirements
CPU
1GHz or higher
RAM
2GB or higher
INPUT
Standard Keyboard & Mouse
Monitor
Output
Communication interface
RJ45 connector (for Ethernet)
4.4.3. Software Interface
Required software must satisfy at a minimum the following:
Table 5: Software Requirements
OS
4.5. Use Case Models and Use Case Scenarios
o
Windows XP or higher,
o
Mac OS 10 or higher, or
o
Ubuntu 7.04 or higher
45
4.5.1. System Use Case Diagram
Figure 9: System Use Case Diagram
4.5.2. Administrator Functions
46
Figure 10: Administrator Functions Use Case Diagram
4.5.3. User Functions:
47
Figure 11: User Functions
Use Case Scenarios:
48
i. Login Scenario
Table 6: Login Scenario
Login
Use Case
Name:
Login
Use Case # 1:
Ref (4.5.2: Multi-User Account Administration)
Actors:
Tool administrator and Team Member
Overview:
This use case describes the login process.
References:
R1
Typical Flow Description 1) Enter user name
1:
2) Enter password
3) System performs user authentication
4) Successful authentication and log in complete
Pre-condition:
User wants to log in to system.
Post-condition:
User is successfully logged in.
Alternative
Description:
Flow 1) Enter user name
2) Enter password
3) System performs user authentication
4) User authentication fails
5) System displays an error message
Pre-condition:
User wants to log into the system.
Post-condition:
User re-enters user name and password.
49
ii. Use Case Scenario to Create Stickies
Table 7: Create Sticky Scenario
Creating Stickies
Use Case
Name:
Login
Use Case # 1:
Ref (4.5.3: Sticky note user function)
Actors:
Team Member
Overview:
This use case describes the process of saving requirements
References:
R2
Typical Flow Description 1) Key in the requirement
1:
2) Click Save
3) System saves the requirement
4) Successful requirement capture
Pre-condition:
User wants to save requirements for the project.
Post-condition:
User successfully saves requirement.
Alternative
Description:
Flow 1) Key in requirement
2) Click Cancel
3) System cancels the save and clears the requirement field
iii. Use Case Scenario to Create Scenarios
50
Table 8: Create Scenarios Scenario
Creating Scenarios
Use Case
Name:
Login
Use Case # 1:
Ref (4.5.3: Scenarios user function)
Actors:
Team Member
Overview:
This use case describes the process of saving scenarios
References:
R3
Typical Flow Description 1) Key in the scenario
1:
2) Click Save
3) System saves the scenario
4) Successful scenario capture
Pre-condition:
User wants to save scenarios for the project.
Post-condition:
User successfully saves scenario.
Alternative
Description:
Flow 1) Key in scenario
2) Click Cancel
3) System cancels the save and clears the scenario field
4.6. Idea Proposed for “User Case Diagrams”:
4.6.1. Use Case diagrams:
A use case diagram is best described as a diagram that represents a set of scenarios that
describe an interaction between a user and a system. A use case diagram displays the
51
relationship among actors and use cases. The two main components of a use case
diagram are use cases and actors.
Figure 12: Use Case Diagram components
4.6.2. Transitioning Use Cases to User Cases:
On the same lines as use case diagrams, a new concept of user case diagrams can be
introduced. These diagrams are quite similar to the use cases except that they are adapted
to capture the user’s requirements with respect to the user interface. These diagrams will
follow the same rules as use cases but the only difference comes in the levels these
diagrams flow into and the kind of information they represent. These diagrams flow into
3 levels;

Level 1: Captures the tasks that the user intends to perform with the system;

Level 2: Captures the functions/icons that will be interfaced to perform the
particular tasks

Level 3: Captures the detailed levels of nested functions/ butcons on the screen
that will be needed to perform the tasks requested by the user.
52
Let’s take an example of the You-I Design tool and see how the requirements can be
captured in a User Case Diagram and how its different levels can be determined;
4.6.2.1. Level 1:
Figure 13: Level 1 User Case Diagram
53
4.6.2.2. Level 2:
Figure 14: Level 1 User Case Diagram
54
4.6.2.3. Level 3:
Figure 15 : Level 3 User Case Diagram
55
These are some simple example of the levels of user cases that can be created. If it were a
complex system, the different nested sets of buttons and options would be listed as well;
this gives the designer as well as the user an idea about the complexity of the interface.
The designer can also arrange the icons and options of top priority in the first set and nest
the advance features. All this can be represented clearly to the user before building the
prototype. Once the user gives his consensus, the designer can build his prototypes and
explicitly show the user how he intends to place the options on the screen and the benefits
of nesting the other features.
56
4.7. Paper Prototype:
Figure 16: Login Screen
57
Figure 17: Welcome Screen
58
Figure 18 : List of options
59
Figure 19: Create a Sticky
60
Figure 20: List all Stickies
61
Figure 21: Create Scenario
62
Figure 22: User-Case Diagrams
63
4.8. Prototype Screenshots
Figure 23 : Welcome Screen
64
Figure 24 : Create Sticky Group
65
Figure 25 : Create New Sticky
66
Figure 26 : View Sticky List
67
Figure 27 : Create Scenario Group
68
Figure 28 : List Scenario Groups
69
Figure 29 : Create New Scenario
70
Chapter 5
CONCLUSIONS AND FUTURE WORK
5.1. Conclusion
This project thus helps rethink the generic method of designing, by proposing a new
approach that takes the user's mental model of what they do and what they need to do and
translates that into the design of the software. The entire focus of this approach was to
keep the ultimate end user in mind while not just gathering requirements or creating an
interface but instead during all the other phases of the project development as well.
The contributions of this project are:

An approach to incorporate the concepts of usability in design, into the SDLC;

A step by step wise approach to be able to build usability into the design of the
system;

A prototype of a tool to help teams use techniques like sticky notes, scenario
building, user cases and prototyping efficiently.
71
5.2. Future Work
This project brings to light different ideas both theoretical, in the form of research and
practical, in the shape of the prototype of the You-I Design tool. These ideas can be
enhanced further, by researching in the domain of human computer interaction, usability
and concepts of mental models. The paper written by Dr. Zhang, “Integrating HCI in
SDLC”, can also be contributed to. With respect to the tool, it is just a prototype, work
can be done in building it into a concrete tool. Modules such a virtual white board for
sticky note management, drawing pane to be able to draw use case diagrams and create
prototypes through the tool can be added, to make this tool complete. Such enhancements
will definitely contribute to a very large extent since no single tool has been implemented
or exists that has all these features under one hood.
Contributions of ideas and tools in this domain will not just add to the work done in the
past but will also bring promising changes to the way work is done in the future…
72
APPENDIX A
import org.springframework.roo.addon.entity.RooEntity;
import org.springframework.roo.addon.javabean.RooJavaBean;
import org.springframework.roo.addon.tostring.RooToString;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;
import com.csus.entites.StickyGroup;
import javax.persistence.ManyToOne;
@RooJavaBean
@RooToString
@RooEntity
public class Sticky {
@NotNull
@Size(max = 4000)
private String Req;
@ManyToOne
private StickyGroup StickyGroupName;
}
import org.springframework.roo.addon.entity.RooEntity;
import org.springframework.roo.addon.javabean.RooJavaBean;
import org.springframework.roo.addon.tostring.RooToString;
import javax.validation.constraints.NotNull;
import javax.persistence.Column;
import javax.validation.constraints.Size;
import com.csus.entites.SecGroup;
import javax.persistence.ManyToOne;
@RooJavaBean
@RooToString
@RooEntity
public class Sec {
@NotNull
@Column(unique = true)
73
private String Name;
@Size(max = 4000)
private String desr;
@ManyToOne
private SecGroup SecGroupName;
}
import org.springframework.roo.addon.entity.RooEntity;
import org.springframework.roo.addon.javabean.RooJavaBean;
import org.springframework.roo.addon.tostring.RooToString;
import javax.validation.constraints.NotNull;
import javax.persistence.Column;
import com.csus.entites.SecGroup;
import javax.persistence.ManyToOne;
@RooJavaBean
@RooToString
@RooEntity
public class UseCase {
@NotNull
@Column(unique = true)
private String Name;
@ManyToOne
private SecGroup SecGroupName;
}
import org.springframework.roo.addon.entity.RooEntity;
import org.springframework.roo.addon.javabean.RooJavaBean;
import org.springframework.roo.addon.tostring.RooToString;
import javax.validation.constraints.NotNull;
@RooJavaBean
@RooToString
@RooEntity
74
public class StickyGroup {
@NotNull
private String StickyGroupName;
}
import org.springframework.beans.factory.annotation.Configurable;
privileged aspect StickyGroup_Roo_Configurable {
declare @type: StickyGroup: @Configurable;
}
import com.csus.entites.StickyGroup;
import java.lang.Integer;
import java.lang.Long;
import java.util.List;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.EntityManager;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.PersistenceContext;
import javax.persistence.Version;
import org.springframework.transaction.annotation.Transactional;
privileged aspect StickyGroup_Roo_Entity {
declare @type: StickyGroup: @Entity;
@PersistenceContext
transient EntityManager StickyGroup.entityManager;
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "id")
75
private Long StickyGroup.id;
@Version
@Column(name = "version")
private Integer StickyGroup.version;
public Long StickyGroup.getId() {
return this.id;
}
public void StickyGroup.setId(Long id) {
this.id = id;
}
public Integer StickyGroup.getVersion() {
return this.version;
}
public void StickyGroup.setVersion(Integer version) {
this.version = version;
}
@Transactional
public void StickyGroup.persist() {
if (this.entityManager == null) this.entityManager = entityManager();
this.entityManager.persist(this);
}
@Transactional
public void StickyGroup.remove() {
if (this.entityManager == null) this.entityManager = entityManager();
if (this.entityManager.contains(this)) {
this.entityManager.remove(this);
} else {
StickyGroup attached = StickyGroup.findStickyGroup(this.id);
this.entityManager.remove(attached);
}
}
@Transactional
public void StickyGroup.flush() {
if (this.entityManager == null) this.entityManager = entityManager();
76
this.entityManager.flush();
}
@Transactional
public void StickyGroup.clear() {
if (this.entityManager == null) this.entityManager = entityManager();
this.entityManager.clear();
}
@Transactional
public StickyGroup StickyGroup.merge() {
if (this.entityManager == null) this.entityManager = entityManager();
StickyGroup merged = this.entityManager.merge(this);
this.entityManager.flush();
return merged;
}
public static final EntityManager StickyGroup.entityManager() {
EntityManager em = new StickyGroup().entityManager;
if (em == null) throw new IllegalStateException("Entity manager has not been
injected (is the Spring Aspects JAR configured as an AJC/AJDT aspects library?)");
return em;
}
public static long StickyGroup.countStickyGroups() {
return entityManager().createQuery("SELECT COUNT(o) FROM StickyGroup o",
Long.class).getSingleResult();
}
public static List<StickyGroup> StickyGroup.findAllStickyGroups() {
return entityManager().createQuery("SELECT o FROM StickyGroup o",
StickyGroup.class).getResultList();
}
public static StickyGroup StickyGroup.findStickyGroup(Long id) {
if (id == null) return null;
return entityManager().find(StickyGroup.class, id);
}
public static List<StickyGroup> StickyGroup.findStickyGroupEntries(int firstResult,
int maxResults) {
return entityManager().createQuery("SELECT o FROM StickyGroup o",
77
StickyGroup.class).setFirstResult(firstResult).setMaxResults(maxResults).getResultList()
;
}
}
import java.lang.String;
privileged aspect StickyGroup_Roo_JavaBean {
public String StickyGroup.getStickyGroupName() {
return this.StickyGroupName;
}
public void StickyGroup.setStickyGroupName(String StickyGroupName) {
this.StickyGroupName = StickyGroupName;
}
}
import java.lang.String;
privileged aspect StickyGroup_Roo_ToString {
public String StickyGroup.toString() {
StringBuilder sb = new StringBuilder();
sb.append("Id: ").append(getId()).append(", ");
sb.append("StickyGroupName: ").append(getStickyGroupName()).append(", ");
sb.append("Version: ").append(getVersion());
return sb.toString();
}
}
78
BIBLIOGRAPHY
1. Cooper, Alan (1995). “About Face - The Essentials of User Interface Design”.
2. John Britsios, “Why Usability is Important to you?”
Available online: http://www.webnauts.net/usability.html
3. Pek Pongpaet, “The Importance of Usability”
Available online: http://blog.roundarch.com/2009/07/24/the-importance-ofusability/
4. Zhang, et al. “Integrating HCI in SDLC”; Proceedings of the Americas
Conference on Information Systems, New York, New York, August 2004
Available online:
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2
&ved=0CCQQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2
Fdownload%3Fdoi%3D10.1.1.64.2693%26rep%3Drep1%26type%3Dpdf&ei=yq
fCToOJAoK3tgeJvrWrDQ&usg=AFQjCNEG6GA9pgd3FSBAHUfw_MrA1VZ
Wvw&sig2=AGe_3HvT7X1-PvmBgYk8ew
5. Shneiderman, B. (1998) “Designing the User Interface - Strategies for Effective
Human-Computer Interaction” Addison-Wesley.
6. Step Two Design; “What is Usability?” by Donna Spencer.
Available at: http://www.steptwo.com.au/papers/kmc_whatisusability/index.html
79
7. Preece, Jenny (1994). “Human-Computer Interaction”. Addison-Wesley.
8. Mental Models and Usability; Depaul University, Cognative Psychology 404
November 15, 1999. Mary Jo Davidson, Laura Dove, Julie Weltz
9. “Dokeos User Interface Guidelines”
Available online:
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0
CCIQFjAB&url=http%3A%2F%2Fwww.dokeos.com%2Fdoc%2Fsource%2Fdui
g-1.0.doc&ei=gqnCTtlwj-q2B-dmMsN&usg=AFQjCNGAKp9JtvSSp2J8Bv7qYrT8V9XqmQ&sig2=94s1mHT6
iOA0jnb7zA3bRA
10. “Apple Human Interface Guidelines”
Available online:
http://developer.apple.com/library/mac/#referencelibrary/GettingStarted/GS_User
Experience/_index.html
11. Hix, Deborah and Hartson, H. Rex (1993). “Developing User Interfaces Ensuring Usability Through Product and Process.”
12. Mental Models, Instructional Design.
Available online: http://www.instructionaldesign.org/concepts/mentalmodels.html
13. James Kirk, Becky Cannon, Laura Burke. “Mental Models: The Food for
Thought.”
80
Available online: http://www.eric.ed.gov/PDFS/ED410393.pdf
14. Bill Buxton. “Sketching User Experiences.” Microsoft Research, 2007.
15. Mental Models – Wikipedia.
Available online: http://en.wikipedia.org/wiki/Mental_model
16. Cooper, “Design + Strategy for a digital World”.
Available online: http://www.cooper.com/#approach:research