Tempus Fugit: Prototype Evaluation and Usability Specifications

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


2/15


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.


3/15


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.


4/15


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.


5/15


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!


6/15


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


7/15


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/15


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.


9/15


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


10/15


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.


11/15


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?


12/15


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?


13/15


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 new goal button. Add a title and a remark to the

description.

6 6 0


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


14/15


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.


15/15


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.

Tempus Fugit: Prototype Evaluation and Usability Specifications

Documents

Transcript of Tempus Fugit: Prototype Evaluation and Usability Specifications