-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
1/15
Milestone 3 Tempus Fugit
1
Milestone ThreeTempus Fugit
12 April 2011
Casey Gordon - Austin New - Paul Prae - Hal Tift
INTRODUCTION ....................................................................................................................................................... 2
DESCRIPTION OF OUR SYSTEM PROTOTYPE .......... ........... .......... .......... ........... .......... ........... .......... ........... .. 2
SYSTEM SUMMARY .................................................................................................................................................... 2
SYSTEM WALKTHROUGH ........................................................................................................................................... 3 DIFFICULTIES OF DEVELOPMENT ................................................................................................................................ 6
EVALUATION PLAN ................................................................................................................................................ 8
CURRENT STATE OF THE INTERACTIVE-DESIGN LIFE CYCLE ....................................................................................... 8 GOALS OF OUR EVALUATION:..................................................................................................................................... 8 THE APPROACHES OF OUR EVALUATION ..................................................................................................................... 9 DATA GATHERING TECHNIQUES THAT WILL BE USED ................................................................................................. 9 QUESTIONS WE WILL CONSIDER DURING EVALUATION: ............................................................................................ 11
Efficiency ............. .......... .......... ........... ........... .......... ........... .......... .......... ........... .......... ........... .......... ........... ....... 11 Memorability .......... .......... ........... .......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... ..... 11 User errors .......................................................................................................................................................... 11 Satisfaction ......................................................................................................................................................... 11 Prototype Specific .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... ........... .......... ........... ....... 12
USABILITY SPECIFICATIONS ............................................................................................................................ 13
USABILITY SPECIFICATIONS ON INITIAL TARGET PERFORMANCE TIME ..................................................................... 13 USABILITY ATTRIBUTES ........................................................................................................................................... 14
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
2/15
Milestone 3 Tempus Fugit
2
Introduction
We have now completed the first prototype of our Tempus Fugit time and event management
application. This first interactive version was created from the common components of our first
four designs. This prototype either provides most of the core functionalities that are necessary tomeet our most important user requirements, and this report will provide an overview of that
functionalities. In addition to providing a description and walkthrough of the system itself, the
report will summarize our evaluation plan and list our usability specifications.
Description of our system prototype
System summary As we began to realize during the last phase of our development process, the system we set outto build would require many iterations of the interactive-design life cycle to become a
successfully innovative and robust system. While this is true of any endeavor within the realm of
interactive design, it is especially true when even the simplest foundation of the system is a fully
functioning calendar, a system that by itself can be very complex. For this reason, much of our
allotted implementation time during this initial design iteration was spent grappling with third-
party, open-source software and learning ways to integrate our functionality into it.
Our first goal in implementation was to find customizable software for a calendar, so that we
could manipulate it for our own needs. We chose a JQuery-based calendar from www.web-
delicious.com that was designed primarily to mimic the functionality of Google Calendar, an
online calendar that we have considered since phase one to be the most similar existing solution
to our own. More importantly, though, was the ability for us to get our own version of the
software and get our hands into its nuts and bolts. We were quickly able to connect the software
with out own database, but from that point forward, progress was a slow and difficult trudge. The
JavaScript was very dense and more advanced, for the most part, than any of us have worked
with in the past.
In the end, we were able to manipulate the software to provide users with a basic prototype,
which embodies the much of the primary functionality that we envisioned at the onset of the
implementation phase.
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
3/15
Milestone 3 Tempus Fugit
3
System Walkthrough
Taking overall simplicity as one of our highest priorities, we considered it imperative to limit our
interface to as few views as possible. Accordingly, we limited our prototype to a single view.
The view consists of two primary windows: the calendar view and the Someday/Maybe list view
(Figure 1). The Someday/Maybe list is visualized as a list of tasks or goals that are important tothe user but have no scheduled time for completion. Such a list may contain traditional bucket-
list items, such as bungee jumping, or it could contain less grandiose goals, such as eating at a
particular restaurant — the key is that the event has no set time (yet).
Figure 1
Standard View. Left window: Someday/Maybe List. Right window: Calendar view.
Above the calendar view is the application control bar. This bar allows users to view the calendar
as either a daily view or a monthly view. In the daily view, as time precision is a primary
usability concern, the calendar view grows in size to accommodate a detailed time line. The
calendar view is nevertheless contained within a scrollable window to ensure that the top of the
Someday/Maybe list is always visible — this is important since a future implementation goal is
for the list to self-prioritize, with the most appropriate event being on top.
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
4/15
Milestone 3 Tempus Fugit
4
Figure 2
Comparison of dialogues. Left: enter a timed event. Right: enter an untimed event.
One of the most important implementation goals we had was to differentiate between a timed
task/event and an untimed one, a process that begins with the user’s entry of an event. Figure 2
above illustrates that we approached this goal by providing the user with two different dialogue
boxes for entry of an event: one for a timed event (when the user clicks “New Event” in thecontrol bar) and one for an untimed or Someday/Maybe event (when the user clicks “New ‘Some
Day’”). Behind the scenes, the primary difference between the dialogue boxes is that the
“untimed” events are actually given a time of zero but placed in the same database table as timed
events. When viewing the application, the Someday/Maybe list is a list of all the items that have
this attribute (time of zero), so that aspect of the implementation is simple, elegant and
functional.
In addition to clicking the “New Event” button, a user can add a timed event at a specific time by
simply clicking the timeline at the appropriate spot (Figure 3) or easily edit an existing event by
clicking it (Figure 4). This provides the user to alter his/her schedule via direct manipulation.
Figure 3 Figure 4
Above: add a new event by clicking timeline.
Right: Edit an existing event by clicking it.
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
5/15
Milestone 3 Tempus Fugit
5
Figure 5
One of the great strengths of the design we
conceptualized is that it also brings this concept
of direct manipulation to the more intangible, yet
important, aspects of time management, primarily
through implementation of a drag-and-drop
interface. Direct manipulation in time
management is not a new concept in general —
even the traditional to-do list on a legal pad
utilizes a satisfying form of direct manipulation
when a user scratches off an accomplished task.
However, there is much power in the potential
application of direct manipulation whereby a user
sees his or her goals laid out in a concrete list that
is fully integrated with a calendar and can move
those items in real time to slots in the calendar.
The link between “could do” and “will do”
becomes that much smaller when a system
marries an abstract goal to a real-world calendar.
Bridging that gap was one of our primary goals in
taking on this project.
We do believe that the foundation for that design
is there in our prototype. However, for reasons
discussed already in brief and at length below, bringing this vision fully to life was not feasible
given our constraints. Still, our programmers
worked for hours implementing a semi-functional
representation of the vital drag-and-drop feature
of the Someday/Maybe list (Figure 6).
While the total functionality is not there, having
this visual representation will be invaluable
during our evaluation of this initial design. Users
will be able to see exactly what our intention is
with this feature and provide us with relevant
feedback, thus ensuring that our efforts aren’t
misguided when trying to tackle the full drag-
and-drop implementation down the road.
Drag-and-drop visual demo—Bungee jumping
between lunch and a work meeting? Of course!
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
6/15
Milestone 3 Tempus Fugit
6
Difficulties of development Production of our prototype was limited by many factors. Coordinating the actual software
development was our primary concern. It was very difficult to find times in our schedules where
we were able to work on the prototype together. We were able to meet on an average of twice a
week. During these meetings, we mostly focused on making sure that each team member had acohesive vision of what we were each working on. We would first go over the main development
plan and made sure we understood the direction we are all working towards. We would then
make sure that we all agreed upon what are our priorities were. We then would decide what each
of us should work on until the next meeting. In between meetings we would send out email
updates and share code as was necessary. Despite these numerous meetings and constant
communication, it was still hard to coordinate our development efforts. The work we
accomplished individually would often not be able to be integrated together. The progression of
our development moved very slowly.
Time was definitely one of the most constraining factors. We knew we had a little over fourweeks, not counting spring break, to complete the prototype. Redesigning the system with our
newly realized limitations in mind took a week in itself. This first week was stressful because we
were trying to figure out exactly what we were going build. Our original four designs were too
complex and beyond our capabilities to produce in such a short amount of time. This redesign
phase was immediately followed by a week of figuring out what technologies and tools we were
going to use to create the new design. There were so many choices that we were struggled to
choose which ones. Each team member had different backgrounds and opinions that influenced
each of our preferences. Once these decisions were made, we began development with only two
weeks left and many more hurdles ahead.
We have stressed since the first research phase that our solution must include a mobile version.
Indeed, in the design phase we envisioned mobile interfaces almost exclusively. However,
because of the aforementioned constraints on our abilities to implement this system, that aspect
of the design will have to wait for hypothetical iterations of implementation that lie ahead.
As mentioned, the first issue we ran into during the early planning stages was the decision of
which design to produce. We came up with four unique designs prior to this stage of the
interactive-design life cycle. Each one had its benefits and problems. The first problem we
realized was that we did not have enough time, knowledge, or resources to finish any of our firstoriginal designs. We decided that there was not a single design, or definite subset of a design,
that stood out as the one that we should use to create our prototype. We decided to come up with
a fifth design that combined the basic functionalities of all of our designs. We knew that our time
was limited. We made sure to begin producing a design that had a foundation, which could then
be expanded with more features if time permitted. We wanted to make sure the most important
user requirements for our software system were met. Unfortunately, the functionality that we
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
7/15
Milestone 3 Tempus Fugit
7
were able to implement was not very unique in comparison to other systems in the market.
Though we did create a solid and mostly-functional prototype, it did not turn out to include as
many of the fun characteristics that we hoped.
After we settled on a design to create, the next set of decisions involved choosing the right
technologies to use in order to create and run our prototype. We had to decide on everything
from the language it will be written in to the server it will run on. We had to figure out how the
full stack was going to be handled. We knew that we had to choose how to build both the front-
end interface and the back-end functionality. We wanted to focus on the look and feel of the
interactive components of the front-end but knew that much of that relied on the data handled by
the back-end. We decided to look through several open source implementations of calendar
management applications in order to find a system that had much of the back-end taken care of
for us. We went through several calendar systems in depth until we found a system that we could
redesign into the model we had imagined. We read through a lot of code and tried many different
systems before we found one that would be the right foundation for the rest of our development.
After figuring out what tools and technologies to use, we then had to put them all together. The
more experienced software engineers on our team had to put in many long hours of development.
Some of the most basic functionality took much longer than expected. The development team
members spent many evenings dedicated to creating each piece of functionality. After each piece
of functionality was added in, we had to then make sure the system looked good and felt
satisfying to use. We knew that working aesthetics into our prototype was a priority for this
project, and we certainly wish we had had more time to sculpt the user interface into a more
beautiful and fluid creation. Our difficulties caused our design evolve over time. We had to
change directions several times as we ran into various issues. Our final prototype is not asmagnificent as any of our original designs but it still encompasses our primary ideas. This
prototype is good enough for us to move on to the next phase of our interactive-design life cycle.
The ideas that are currently in software form are now ready to be evaluated.
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
8/15
Milestone 3 Tempus Fugit
8
Evaluation plan
Current state of the interactive-design life cycle This evaluation will occur during the first stage of development of the first prototype. We are
still within the first iteration of the interaction-design life cycle. During this iteration of thedevelopment process, the system will be partially complete and will only have basic
functionality. The current prototype represents the core structure that will act as the foundation
for more advanced features. This core functionality must be evaluated before we can decide what
features to add, what features to keep, and what features to discard.
This evaluation will occur during the early design of the system to clarify our current design
ideas. We will be exploring some new design concepts and some traditional ones. Some aspects
of the current prototype, such as the “Some day, Maybe” list, are unique and must be tested
before further development is to take place. We must completely assess the current prototype to
decide what the top priorities are during the next analysis and redesign phases of our interaction-
design life cycle. Acquiring this kind of feedback and data this early in the iterative design
process will be an essential ingredient for a successful final design. It will confirm which current
ideas we should continue to develop and which ideas we should not. It will also help discover
new ideas for future designs.
Goals of our evaluation: ●
To discover how our design could change the way people manage their time, goals, andtasks.
● To help identify the opportunities where our technology can improve current practices.
● To discover how efficient our system is.
● To discover how satisfying our system is.
● To discover how learnable and memorable our interactive design is for our users.
● To find out where users of our system make errors.
● To make sure that we are fully prepared for a redesign of the system.
● To plan for improvements to the current design based on our findings.
● To be sure that we are considering the user needs and requirements that have been
established earlier in our design life cycle.● To be sure that we continue to refine our understanding of our potential users’ needs and
requirements by defining more as we go through our evaluation process.
● To see how unique our system is in the market.
● To see how our system compares to our competitors in regards to efficiency,
satisfiability, learnability, memorability, and percentage of user errors.
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
9/15
Milestone 3 Tempus Fugit
9
The approaches of our evaluation We will be combining multiple forms of evaluation. We will primarily be focusing on formative
and heuristic forms of evaluation. These evaluation techniques are intended to ensure that the
prototype is meeting our users’ needs, and we will take into account our user requirements and
our usability specifications when evaluating the system. Our evaluation will take intoconsideration our target user groups and how they will use the system. For the heuristic
components of our evaluation, we will compile a set of heuristics, including our usability
specifications, that we will use to evaluate our system.
Data gathering techniques that will be used We will be combining the approaches of usability testing, field studies, and analytical evaluation.
We plan to focus most of our efforts on usability testing. During most of the usability testing, we
will control the test environment and the format of the testing. We will be generating a mix ofquantitative and qualitative data. Our first goal during usability testing will be to quantify users’
performance while using our software. For this portion of testing we will study each participant’s
interactions with the system in great detail. We will quantitatively evaluate our system and other
competing or similar systems and then compare the results. We will measure typical users’
performances on typical tasks while noting the number and kinds of errors that the users make.
Our usability tests will create more detailed user specifications that could aid in evaluating future
prototypes. These specifications will also help us compare our system to competing systems.
Optimal performance levels and minimum levels of acceptance will be established. More
quantitative data and all of the qualitative data will come from user questionnaires and
interviews.
We will create user satisfaction questionnaires and interviews to elicit users’ opinions. Our
questionnaires and interviews will have both open and closed questions. We want to make sure
we are collecting the information that we are explicitly looking for while also allowing the
participant and user to guide us to other important findings. This will help us to stay on a path
that ensures a user-centered approach. Questionnaires and interviews will be used in conjunction
to clarify, deepen, and confirm our understanding of users’ needs. Interviews will be given in a
controlled environment while questionnaires will be given in both a controlled environment and
also wherever is convenient to the user. Each participant will use the system before participatingin the questionnaires and interview. The questions given to the participants will help us gain a
greater understanding of the entire user experience.
Our evaluation will also include field studies. We will observe people using our system in the
setting that they would normally use our system. This will depend on each participant. It will be
important for us to see how different demographics use our system in multiple contexts. We will
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
10/15
Milestone 3 Tempus Fugit
10
do this with the aim to understand how people will naturally use our prototype and for what
purposes. These field studies will help us learn how to deploy our system in different contexts.
The main focus of our field studies will be on direct observation. This will help us investigate
how well our developing prototype supports the users’ contexts, tasks, and goals. Watching
different participants will give our team a personal account of how our system is performing and
how it will be used. Contextualizing the users and our interactive product will help us reflect on
the appropriateness of our design. It will make flaws more noticeable. Direct observation will
help us realize why activities happen the way they do. We will be able to observe the tendencies
of the participants in an everyday context.
We will follow each direct-observation study with interviews. These will vary the interviews
given during our usability testing because they will be given out in the field rather than a
controlled environment. Interviews are the best way to allow users to portray their experiences to
our team. We will be conducting semi-structured interviews. The use of open questions willensure that the most important issues, as perceived by participants, are considered. These open-
ended questions will help us recognize how the user is reacting to our new design ideas. The
closed questions will ensure that we are assessing the aspects of our design that have proved to
be important according to our established requirements. These structured questions will help us
gain feedback concerning particular design features. Our field studies should leave us with
valuable information for improving our design during the next iteration of our life cycle.
Our team also plans to perform an analytical evaluation. We will be conducting multiple
inspections of our system, which will include a heuristic evaluation and walkthrough that is
completed by a team member as well as an expert in the field. Each inspector will walk throughspecific scenarios with the prototype of the application. During heuristic evaluation, the
inspectors will use knowledge of typical users, coupled with guidelines and standards, to identify
usability problems. We will analyze various mental operations that are needed to perform
particular tasks and operationalize them in terms of quantitative measures. Our inspections will
provide highly specific information that will help rate our system in easily comparable terms.
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
11/15
Milestone 3 Tempus Fugit
11
Questions we will consider during evaluation:
Learnability
● Is our current system easy to learn?
■
Is it consistent?■ Is it reliable?
■ Is it predictable?
● Is navigation through our current system straightforward and well supported?
● How easy is it for users to accomplish basic tasks the first time they encounter the
design?
● Does the user understand the terms we are using to describe objects and concepts?
Efficiency
●
Can users perform tasks on our current system faster than performing those same tasks ona similar or competing system?
■ How long does it take for a user to:
● add a new task to the daily view of the calendar?
● add a new task to the “Some day, Maybe” list view?
● edit a task from either the daily view of the calendar or the “Some day,
Maybe” list view?
Memorability
● Does our design encourage further use of our system?● Once users have learned the design, how quickly can they perform tasks?
● When users return to the design after a period of not using it, how easily can they
reestablish proficiency?
User errors
● How many errors do users make, how severe are these errors, and how easily can they
recover from the errors?
Satisfaction
● How does the system respond to the user?
● Does our design make the user feel good?
● Does our current system save the user time?
● Does our current system accomplish all the tasks that a user may need to perform when
managing his/her time?
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
12/15
Milestone 3 Tempus Fugit
12
● Is our current system causing the users to manage their time better?
● Does our system take into consideration the emotions that could arise while the user is
managing his/her time and events?
● Is our current system available to the user whenever s/he may need it?
● Is our current system providing a good user experience for people in our target audience?
● Is our current system aesthetically pleasing?
○ Are the colors used pleasing?
Prototype Specific
● Is our current system making it easier for a user to keep track of items that do not have a
certain time associated with them?
● Is a user able to keep track of more task items on our current system compared to other
systems?
● At what points does our current system intrude on users’ lives?
○ Is this happening too much?
● Does our current system take into consideration all of the important attributes of
scheduling or listing an event?
● Does the current system allow for a user to be able to search and sort events in all of the
ways that typical users would need to?
● Does it consider all possible contexts in which an event can be scheduled or
accomplished?
● Are users able to distinguish between events that occur at work and events that occur
outside of work?● Does our current system take into account the varying levels of importance that each
event may have?
● What are our common tasks (those 20% of all tasks that account for 80% of the usage of
all tasks)?
○ Do they take priority over uncommon tasks?
● What are our critical business tasks (the tasks that can cause serious problems if they are
not performed accurately)?
○ Are they safeguarded to make sure that their use does not create a mistake?
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
13/15
Milestone 3 Tempus Fugit
13
Usability specifications
Usability specifications on initial target performance time
Task Number
of actions
Time
(seconds)
Errors
Add a new goal into the calendar view at a specific time
and day by clicking on the timeline. Add just a title to the
description.
3 4 0
Add a new goal into the calendar view at a specific timeand day by clicking on the timeline. Add a title and a
remark to the description.
5 6 0
Add a new goal into the calendar view at a specific time
and day by clicking on the timeline. Add a title, location,and a remark to the description.
6 7 0
Add a new goal into the calendar view by clicking on the
add new goal button. Add just a title to the description.
5 4 0
Add a new goal into the calendar view by clicking on the
add new goal button. Add a title and a remark to the
description.
6 6 0
Add a new goal into the calendar view by clicking on the
add new goal button. Add a title, location, and a remark tothe description.
7 7 0
Add a new goal onto the “Some day, Maybe” list. Add
just a title to the description.
3 4 0
Add a new goal onto the “Some day, Maybe” list. Add a
title and a remark to the description. 5 6 0
Add a new goal onto the “Some day, Maybe” list. Add atitle, location, and a remark to the description.
6 7 0
Transfer a goal from the “Some day, Maybe” list to the
calendar view
2 2 0
Edit a goal from the calendar view. Edit the title. 4 4 0
Edit a goal from the calendar view. Edit the title and a itsremark.
5 6 0
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
14/15
Milestone 3 Tempus Fugit
14
Edit a goal from the calendar view. Edit the title, itsremark, and the location.
6 7 0
Edit a goal from the “Some day, Maybe” list. Edit the
title.
4 4 0
Edit a goal from the “Some day, Maybe” list. Edit the titleand a its remark.
5 6 0
Edit a goal from the “Some day, Maybe” list. Edit the
title, its remark, and the location. 6 7 0
Search for a goal. 4 3 0
Sort the “Some day, Maybe” list 3 2 0
Find the best goal to do at any given moment. 1 2 0
Switch from the daily view to the monthly view of the
calendar or vice versa. 1 1 0
Usability attributes
Learnability - Our system should be extremely easy to learn. The user should know how to use
most of the system after examining the interface for just a few seconds. The only aspects of the
system that may require explanation are the more unique aspects such as the “Some day, Maybe”
list. These unique functions and aspects of the system should be able to be explained to the userin only a few seconds. This system should be especially easy to learn because we can use many
concepts that are identical to a physical calendar. A high level of affordance should be
implemented. Certain aspects, such as creating and editing events, are typical of digital calendar
applications. Users of digital calendars should already know how to use most of the interface.
Memorability - This system should be a very simple system. It should be highly memorable. This
memorability will need to stem directly from the fact that the system should be easy to learn in
the first place. After the system is learned the first time, the user should be able to remember how
to use all the functionality for every time afterwards. This type of system needs to be designed to
be used often. The memory of how it functions should stay fresh in the users’ minds. A limitedamount of functionality will contribute to how easy it will be to remember how to use the
system. There should not be too much for the user to remember. Additionally, the familiarity of
concepts concerning this time and event management application should also make the system
highly memorable.
-
8/13/2019 Tempus Fugit: Prototype Evaluation and Usability Specifications
15/15
Milestone 3 Tempus Fugit
15
Efficiency – Use of this system must be efficient in all aspects. One of our main goals in creating
this application was to save the user time. We want to make the system accessible enough that
any user can perform any given task in under five seconds. The main tasks include adding a goal
to the calendar and retrieving a goal from the calendar. Our system must meet or exceed our
competitors in all performance time measures.
User errors - Our goal is to have a system that is so simple and straightforward to use that our
users rarely perform errors, if ever. There should be very few steps in all of our user tasks for this
system. By limiting the steps required to complete a task, we live as little room for error as
possible.