A.R.C. Usability Evaluation

h

CS2003 Usability Engineering Report For A.R.C.

by Jan P.C. Hanson

2014

StudentID: 1339404Level 2

Abstract

A.R.C. (Augmented Reality Communicator) is a project, in its infancy, that tries to providesocial media functionality with a focus on professional collaboration. This puts it somewherebetween Google's suite of tools and LinkedIn. This document provides some backgroundto the project ostensibly from a usability engineering perspective, as well as the coveringthe requirements gathering procedure as well as usability testing of the application and therami�cations thereof.

1

Table of contents

1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Research Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Requirements Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.1 Pre-Existing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.2 Semi-Structured Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.3 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.4 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Prototype Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3.1 Internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3.2 External . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3.3 In-Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Presentation of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.1 Requirements Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.1.1 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.1.2 Brainstorming & Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2.1 Internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2.2 External . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2.3 In-Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Discussion of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 References & Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7.1 questionnaire questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.2 Test text for 'create post' test task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157.3 Programme of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2

1 Background

ARC stands for Augmented Reality Communicator. It is an attempt to produce a social networkingapplication that uses augmented reality (in the form of live camera preview overlays and mapoverlays) to visualise a social network aimed at making professionals' lives easier.

It is widely known that Social Networking Sites (SNS's) have become widely used in the last 15years, and based on anecdotal evidence, LinkedIn appears to be the SNS of choice for users wantingto engage in social networking in a professional setting. (Duggan & Smith 2013) recorded that42% of adults now use multiple SNS's, of the online population measured in this study 71% useFacebook making this by far the most popular SNS on the list, while 22% use LinkedIn(in additionto, or as their sole SNS).

(Hampton et al.,2014) noted that when it came to the Snowdon NSA scandal, 58% of Facebookusers and 59% of twitter users were unwilling to discuss the topic of government surveillanceprograms, while 35% of people would be unwilling to discuss it at work. By extension this may gosome way to explaining the divide in usage; LinkedIn is by de�nition an SNS used by employersand employees for the purpose of people marketing themselves to each other, and thus only 'worksafe' communications are generally posted.

(Quan-Haase & Young 2010) reported Facebook users primarily using the site for maintainingpre-existing relationships and keeping in touch with school friends, in this same paper they alsoexplain that instant messaging ful�lls di�erent needs to that of a social networking site such asfacebook; that of maintaining and supporting relationships with distant others. Facebook currentlyincorporates instant messaging also. Couple this multi-mode communication with the percievedopeness of communication (anecdotal), and it is small wonder why Facebook is the more ubiquitousSNS.

With ARC I would like to attempt to bridge the divide between LinkedIn and Facebook, to provicdea social networking application that can be used in a professional context without the apparentrestrictive feel that comes with knowing one is in full view of any potential employer.

I believe that one way to achieve this is to make the experience enjoyable, to this end, the resultsof (Saket et al., 2015) show that users enjoy information visualisation more when graphs areembellished. This lead to my choice to incorporate AR as a central part of this project. The papergoes on to explain the use of a modi�ed Flow model to explain and partially quantify how andwhy certain tasks are enjoyed more than others:

� Challenge - Generally, enjoyment occurs when the challenge in an activity matches theskill of the participant.

� Focus - Enjoyable activities require complete attention on the task at hand.

� Clarity - Enjoyment occurs when the goals of the activity are clearly understood, and theusers knows what he/she is working towards.

� Feedback - Enjoyement occurs when the task undertaken provides immediate feedback.

� Control - An application should provide a feeling of control over the environment specie�ed.

� Immersion - The participants should lose themselves in an activity.

(ISO 9241-11, 1998) de�nes usability as:

3

�The extent to which a product can be used by speci�ed users to achieve speci�edgoals with e�ectiveness, e�ciency and satisfaction in a speci�ed context of use.�

(Speicher, M., 2015) expands on this de�nition by specifying what is meant by :product, speci�edusers, speci�ed goals and speci�ed context, as well as de�ning the level of usability metric used:

usability 2 LEVEL � PRODUCT � USERS � GOALS � CONTEXT

This provides a useful semi-formalism to de�ne, more consistnatly, the parameters for this usabilityevaluation.

LEVEL Internal External In Use

PRODUCT application code prototype's and mobile applicationand comments. screenshots.

USERS Programmers test participants test participants

GOALS implementing new completion of test (reading posts, creating posts,functionality tasks, adding friends, viewing

friend information), usingall available visualisationmethods

CONTEXT eclipse and provided observation in real world,documentation plus controlled interviews, questionaireinterviews environment plus

interviews

Table 1.

(Speicher, M., 2015) de�nes LEVEL under three distinct catagories:

� �Internal metrics , which measure a set of static attributes (e.g., related to software archi-tecture and structure).� In the context of this evaluation this would refer to the ability fora programmer to maintain and modify the code.

� �External metrics , which relate to the behavior of a system (i.e., they rely on execution ofthe software).� This would be a simple measure of whether the software performs the speci�ctasks set out in the requirements.

� �In-use metrics, which involve actual users in a given context of use.� This last entry wouldthen refer to the application used in 'real life' context.

2 Aims and Objectives

2.1 Aims

The aim of this usability evaluation is three-fold: Firstly to determine potential user's most wantedfeatures; Secondly to determine potential user's e�cacy with the proposed interface and lastly todiscover usability pitfalls with the system.

4

2.2 Objectives

� Undertake a literature review

� Determine requirements gathering tools

� Collect user requirements

� Create basic prototype

� Evaluate basic prototype

� Analyse results

� Design Java application for Android platform

� Evaluate application with potential users.

� Analyse results

� Write usability report.

3 Research Methods

3.1 Requirements Gathering

(M.F. DiAngelo & C.J. Petrun, 1995) work through a very detailed and well speci�ed methdologyknown as CRTS (Custormer Requirements and Task Speci�cation), which focuses on gainingrequirements based solely on customer input, through an extensive series of expert-led sessions.Unfortunately utilizing this in its full capacity would have taken a restrictive amount of time. Iwould like to take some key points from this and apply them to my own requirements gatheringmethods, namely: that user requirements should come entirely from the customer (with the caveatthat, there exist some pre-existing requirements for this project), and that requirements shouldbe developed into a 3-tier system with top tier attributes of the system(i.e. the system shouldbe: consistant etc), middle tier indicators for these attributes(i.e. no down time), and lower tiermeasurables (i.e. monthly down time).

3.1.1 Pre-Existing Requirements

At the outset of this project some arbitrary requirements were prescribed for the project (DavidBell, 2014) Which include the use of augmented reality, and the requirement that the project mustbe completed using Google's Java Android framework. The justi�castion for the use of AR in thisparticular context is given in the background section.

3.1.2 Semi-Structured Interviews

The �rst method that I elected to use for the purpose of requirements gathering is a set of semistructured interviews performed on a test population of potential users. (Doody & Noonan, 2013)building on the work of (Holloway & Wheeler, 2010), describe the e�ective use of semi-structuredinterviews to allow a free �ow of ideas and context, di�cult to obtain via structured interviews,to be developed; while allowing the researcher to eliminate some of the observational bias inherent

5

in unstructured interviews. The question themes used to direct the course of the interview, withinthe context of this project where as follows: What role do you think an SNS could play in yourday to day professional activities, how comfortable are you using GPS/Sensors, What features doyou use most/would you most like.

3.1.3 Brainstorming

In conjunction with the method speci�ed above it was decided upon to use brainstorming. Both(M.F. DiAngelo & C.J. Petrun, 1995) and (AL-Hothali, 2012) describe it's use for the elicitation ofrequirements in software developement. In the context of ARC, this was performed by a group of 9Potential users and the system developer using the group passing technique described in (Osborne,1963)

3.1.4 Survey

Lastly a survey was released onto Facebook and Twitter, asking a series of descriptive, true/false,selection and Likert style questions. These questions attempt to ascertain(amongst other things)potential users' most favoured/wanted features from an SNS and users current SNS usage (Hanson,2014).

3.2 Prototype Design

A series of prototypes was used to aid both the design process and the usability of this project. Thisprocess was started by using the POP application to produce an interactive paper-style prototypeas advised by (Wilson Fletcher, 2014). Following this a HTML mockup was created to more closelysimulate the look and feel of the end product (Van Buskirk & Moroney, 2003).

The look and feel of these prototypes was deliberately left rough while engaged in usability testingas (Van Buskirk & Moroney, 2003) noted that by doing so it is possible for the test user toconcentrate more on the functional usability, as they are less likely to forgive errors because of apolished appearance.

3.3 Usability Testing

As explained in the 'Background' section of this paper, and recommended by (Speicher, 2015), theactual usability is evaluated acording to three metrics (internal, external and in-use).

3.3.1 Internal

This is the metric that is hardest to quantify, and from the consumers point of view, the leastimportant. However, if this project were to continue in the long run, maintainable, easy to readcode ultimately aids usability as new features are less likely to be prone to crippling bugs, andthose bugs that do crop up should (by de�nition) be easier to �nd and �x.

Because of this, I have decided to spend some time evaluating these attributes of ARC by givingthe source code to 5 developers not involved with this project and asking them to implement sometest functionality. A time limit of one week was given to them, after which their code was submittedand the developers interviewed.

The developers were of varying skill levels and asked to implement a new text based view with for-ward and backward buttons to view the next/previous post based on chronological order. The onlyinformation available to the developers was the sourcecode documentation and a brief description

6

amounting to what is contained in the �rst paragraph of this report. The code that they submittedwas not used in the �nal product.

3.3.2 External

This metric de�ned the testing of the initial POP prototypes and the HTML Mockup. Test par-ticipants were asked to review these prototypes in the context of completing a series of test tasksaimed at assessing the 4 aspects of usability proposede by (Shackel, B., 1991). These test taskswere performed under observation in laboratory conditions and the time taken to complete thetasks was recorded. The same tests(where applicable) where performed on facebook and linkedin.No information was given to the test subjects other than what is contained in the �rst paragraphof this report. Semi-Structured interviews were then carried out given the theme of (Shackel, B.,1991)'s 4 criterion: e�ectiveness, learnability, �exibility and attitude. (appendix 7.1))

3.3.3 In-Use

This context de�nes the usability in a real word scenario, therefore the app was given to testparticipants, and they were asked to use it o� site as if it were any other mobile application. A timelimit of two days was set after which they were given a questionnaire based on a modi�ed set ofquestions from (Thuseethan et al, 2014) to ascertain the usability of the product in its current state.

Lastly unstructured interviews were conducted (Doody & Noonan, 2013) where participants wereasked for there overall thoughts on the product. Test participant comments were used to drive theinterview in an attempt to reduce researcher bias. (appendix 7.1))

4 Presentation of Results

4.1 Requirements Gathering

4.1.1 Survey

Figure 1. Which of these social networks do you use

7

Figure 2. How often do you check your network(s)

Figure 3. How often do you post messages

Figure 4. Which of these features would you �nd useful in a professional context

8

Figure 5. Password Security

Figure 6. GPS usage

Figure 7. Connectivity

Figure 8. Movement Sensors

4.1.2 Brainstorming & Interviews

As a result of Brainstorming and interviews the following points where made regarding featuresand behaviour

i. A map view that has posts shown at the geographical location where they were createdwhen clicking on them, should expand to show post.

ii. There should be a timeline view for those times where GPS availability is limited (tubestations, inside certain buildings etc), this should be the default page.

iii. A view that shows a live feed from the camera, overlayed with posts bassed on geographicallocation, when clicked on they should expand to show the conent of the post.

iv. There should be di�erent levels of relationship (colleague, friend, employer), to limit andcontrol who gets access to particular information.

9

v. User Info should contain geographical information, but you should be able to chose whoviews it.

vi. Location should be monitored and recorded, so that other users can get see status inform-ation in real time.

vii. Views should be made easily accessible, maybe placing icons prominently on all screens, atthe top of the screen.

viii. Any view should be accessible from inside any other view, to make it easy to navigate.

ix. There should be no cap on how large a post entry should be, after a certain size the postshould be folded.

4.2 Usability Testing

4.2.1 Internal

4 out of the 5 developers where able to complete the task in the alotted time. Implementing a textbased post view with forward and back buttons to view the next/previous post in chronologicalorder.

After interviews with the developers, the following points where concluded:

� After realising that the project conformed to an MVP architecture, and that the strategypattern (Gamma et al, 1994) had been used to implement the Views portion of the MVParchitecture; it was conceptually straightforward to �t new functionality into the framework.

� Sourcecode documentation was good but a little inconsistant, with some functionality welldocumented, while other functionality had comments missing or incomplete, leading to delayin �nishing the test task.

� The use of a dummy model caused some confusion, as it was unclear by the speci�cation ofthe test task as to whether this was meant to be used or not.

� Naming conventions were slightly mixed, similar to the documentation, leading to a smallmeasure of confusion in which method parameters where being passed and which were usedinternally to certain classes.

4.2.2 External

Figure 9. Time taken to write a test post (seconds)

10

Figure 10. Time taken to view a post using the camera view (seconds)

Figure 11. Time taken to view a post using the map view (seconds)

Figure 12. Time taken to view friend information (seconds)

interview results(amalgam of HTML & POP):

� functionality clear , placed in standard places on screen

� all expected functionality of SNS but no frills bordering on too basic

� iconography clear

� good use of screen real estate

11

� No clear indication of how to access friend information.

� lack of information formatting

Notes:

4.2.3 In-Use

Figure 13. Usability Questionnaire results table

(see appendix 7.1 for question numbers)

Figure 14. Usability Questionnaire results graph

12

Interview results:

� not enough funtionality implemented to really be usable

� the functionality that is there is easy to use and navigate.

� map and camera easy to use

� no warning of gps o�

� good use of screen real estate (doesnt feel cluttered)

� crashes on switching between camera/map/post without returning to main screen �rst

� lack of ability to edit posts once created

� lack of information formatting

� feels very basic

5 Discussion of Results

5.1 Internal (refer to 4.2.1)

The general reaction of the developers tasked with implementing was positive, with all of thedevelopers except one manageing to implement the required functionality. The reason thatdeveloper was not able to complete the task was due to a lack of familiarity with object ori-ented techniques and design patterns.

There were however some points to take away from this excercise: it was noted that the commentswere slightly inconsistant between classes as were variable naming conventions. This led to somedelays in coding as developers spent more time than was necessary deciphering the provideddocumentation before they could start.

This can be recti�ed by going through the source code and rewriting the comments so that doxygenwill produce more consistant docs. The naming conventions may take more work but is alsoperfectly feasible.

5.2 External (refer to 4.2.2)

As can be seen from �gure's 9 - 12 the times taken to complete the various tasks is of similar lengthto that of facebook and linkedin with the exception of viewing friend information. With regards to�gures 9 - 11 the HTML and pop mockups take a little longer but not a signi�cant amount, andnot enough to produce signi�cant negative sentiment according to the interviews conducted.

The time taken to view friend information is signi�cantly longer than facebook and linkedin, andthis is echoed in the interviews conducted, with the general consensus being that it isnt clear howto do it, and that it was only through guestimation that the task was completed. This may bedue to the fact that there is no actual 'friends' tab or section within the app and the only way toaccess friend information is by tapping on the users icon or name.

This needs to be rect�ed in the �nal product. Another thing that was commented on was thatthere was a lack of formatting to the information, both post info and user info. This made theinterface a little o� putting and is an issue that also must be addressed.

13

5.3 In Use (refer to 4.2.3)

Looking at the interview results it is clear that there are some serieous usabaility issues that needto be addressed, First among these is the fact that the system crashes under certain conditions,this is a fatal �aw and must be recti�ed before anything else. The next is the lack of errormessages (interviews & question 13[�g 13-14, appendix 7.1]), this is something vital for the appto communicate with the user during situations such as the gps not being switched on. withoutan error message the user will likely just wonder why the app isnt working and stop using it. Theother points mentioned in theinterview results are less of a priority but still important. The lack ofinformation formatting would probably help the app feel more polished, adding extra functionalitywould make it feel more complete, but theses I feel are probably a lower priority than changingthe structure of posts so they can be edited. It was noted in the interviews and in question 14that there is general sentiment that it is di�cult to recover from a mistake if one is made, and thiswould probably go some way towards �xing that.

On the plus side, the app was generally well recieved with regards to ease of use, learnability andpeoples attitude towards it. (see other questions [appendix 7.1 & �g 14]). Overall the app has bothattractors and detractors in roughly equal measure, hinting that the app shows promise but needswork.

14

6 References & Bibliography

[1]Maeve Duggan, Aaron Smith,. (2013). Social Media Update 2013. Available: http://pewin-ternet.org/Reports/2013/Social-Media-Update.aspx. Last accessed 10 Mar 2015.

[2]Hampton, K.N., Rainie, L., Lu, W., Dwyer, M., Shin, I., & Purcell, K. (2014). Social Mediaand the Spiral of Silence.' Pew Research Center, Washington, DC. Available at http://www.pew-internet.org/2014/08/26/social-media-and-the-spiral-of-silence/

[3]Anabel Quan-Haas , Alyson L. Young. (2010). Uses and Grati�cations of Social Media: AComparison of Facebook and Instant Messaging. Bulletin of Science, Technology & Society. 30(5), p350-361.

[4]Bahador Saket, Carlos Scheidegger, Stephen Kobourov. (2015). Towards Understanding Enjoy-ment and Flow in Information Visualization.arXiv:1503.00582. 1 (1), p1-11.

[5]ISO 9241-11:1998: Ergonomic requirements for o�ce work with visual display terminals (VDTs),Part 11: Guidance on usability, 1998.

[6]Maximilian Speicher. (2015). What is Usability? A Characterization based on ISO 9241-11 andISO/IEC 25010. arXiv:1502.06792. 1 (1), p1-10.

[7]M. F. DiAngelo., C. J. Petrun.. (1995). Collecting Product based Usability Requirements. IBMSystems Journal. 34 (1), p4-19.

[8]David Bell. 2014. CS2001 - Group Project. [ONLINE] Available at:https://blackboard.brunel.ac.uk/webapps/portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblack-board%2Fexecute%2Flauncher%3Ftype%3DCourse%26id%3D_17217_1%26url%3D. [Accessed16 March 15].

[9]Doody 0, Noonan M (2013) Preparing and conducting interviews to collect data. NurseResearcher. 20, 5, 28-32.

[10]Holloway I, Wheeler S (2010) Qualitative Research in Nursing and Healthcare.Third edition.Wiley-Blackwell. Oxford

[11] Samaher Abdullah AL-Hothali, Noor, Anusuyah Subbarao Abdulrahman AL-Zubaidi, . (2012).Requirements Elicitation For Software Projects. International Journal of Computer Science andInformation Security. 10 (11), p64-71.

[12] Osborn, A.F. (1963) Applied imagination: Principles and procedures of creative problemsolving (Third Revised Edition). New York, NY: Charles Scribner's Sons.

[13]Wilson Fletcher, (2014), 'Prototyping - The Tools: What We Useand When To Use Them', CS2003: Usability Engineering , Available at:https://blackboard.brunel.ac.uk/webapps/portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblack-board%2Fexecute%2Flauncher%3Ftype%3DCourse%26id%3D_17219_1%26url%3D, [Accessed16 March 15]

[14]Shackel, B. (1991). Usability�context, Framework, De�nition, Design and Evaluation. Shackel,B. and Richardson, S., Ed. Human Factors for Informatics Usability. pp.21-37. Cambridge, UK,Cambridge University Press.

[15]Thuseethan, S., Achchuthan, S., Kuhanesan, S.. (2014). Usability Evaluation of Learning Man-agement Systems in Sri Lankan Universities. Global Journal of Computer Science and Technology.15 (1), p15-24.

[16]Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1994)Strategy. Design Patterns, Elements ofReusable Object-Oriented Software. Westford, MA: Addison Weseley.

15

7 Appendix

7.1 questionnaire questions

1. I think that I would like to use ARC frequently

2. I found ARC unnecessarily comlex

3. I thought ARC was easy to use

4. I found the various functions of ARC well integrated

5. I thought there was too much inconsistancy in the system

6. I would imagine that most people would learn to use ARC quickly

7. I felt very con�dent using ARC

8. I needed to learn a lot of things before I could get going with ARC

9. I liked using the ARC interface

10. Overall the system was easy to use

11. It was easy to learn to use the system

12. I believe I could become productive using this system

13. The system gave error messages

14. Whenever I made a mistake using the system, I could recover easily and quickly

15. ARC enables me to communicate with colleagues asynchronously

16. I am con�dent in using this technology

7.2 Test text for 'create post' test task

my name is [insert name], i am [insert age] years old, i live in [insert city].

7.3 Programme of Work

On following pages.

16

CS2003 - A.R.C. UsabilityEngineering Mar 20, 2015

http://

Project manager Jan P.C. HansonProject dates Sep 15, 2014 - Mar 22, 2015

Completion 0%Tasks 18Resources 1

A.R.C.- Augmented Reality Communicator

Name Begindate

End date Outcome

Idea generation 9/15/14 9/27/14 App Ideas

Requirementsgathering

9/20/14 10/23/14 Requirements

Survey 9/20/14 10/23/14 required functionality, Current SNS usageInterviews 9/20/14 9/26/14 Soft features, Functionality, preffered SNS usageBrainstorming 9/26/14 10/1/14 ideas for functionality, priority of functionality

App Design 10/24/14

11/13/14 prototype design

Prototype 10/30/14

12/4/14 Prototypes

basic mockup 10/30/14

11/9/14 working POP prototype

html mockup 11/10/14

11/16/14 working HTML mockup

Working Prototype 11/17/14

12/4/14 Prototype android application

Usability Evaluation 1/3/15 2/4/15 Evaluation of the usability of prototypesLiterature Review 1/3/15 1/15/15 Assesment of usability engineering methods

applicableDeveloper review 1/16/15 1/25/15 developers have knowldege of framework usabilityPrototype reviews 1/16/15 1/25/15 testers have knowldege of app usabilityInterviews 1/26/15 1/30/15 Contextual appraisal of prototypesObservation of tasks 1/26/15 1/30/15 semi-quantitative/qualitative appraisal of prototypesQuestionnaire 1/26/15 2/4/15 ADJUST AND ADD

writing usability report 1/16/15 3/21/15 Usability Evaluation Report


Tasks 2

Name Default roleJan P.C. Hanson project manager


Resources 3


Gantt Chart 4

Name Begin... End date Outcome

Idea generati... 9/15/14 9/27/14 App IdeasRequirement... 9/20/14 10/23/14 Requirements

Survey 9/20/14 10/23/14 required functionality, Current SNS usageInterviews 9/20/14 9/26/14 Soft features, Functionality, preffered SNS...Brainstor... 9/26/14 10/1/14 ideas for functionality, priority of function...

App Design 10/24... 11/13/14 prototype designPrototype 10/30... 12/4/14 Prototypes

basic moc...10/30... 11/9/14 working POP prototypehtml moc... 11/10... 11/16/14 working HTML mockupWorking P...11/17... 12/4/14 Prototype android application

Usability Eval...1/3/15 2/4/15 Evaluation of the usability of prototypesLiterature... 1/3/15 1/15/15 Assesment of usability engineering metho...Developer...1/16/15 1/25/15 developers have knowldege of framework ...Prototype... 1/16/15 1/25/15 testers have knowldege of app usabilityInterviews 1/26/15 1/30/15 Contextual appraisal of prototypesObservati... 1/26/15 1/30/15 semi-quantitative/qualitative appraisal of ...Questionn...1/26/15 2/4/15 ADJUST AND ADD

writing usabil...1/16/15 3/21/15 Usability Evaluation Report

2014 2015

September October November December January February March April


Resources Chart 5

Name Default role

Jan P.C. Hanson project manager 400% 200% 300% 200% 200%

2014 2015

September October November December January February March April