Embed Size (px)
Citation preview
1
Final report INF5261
Development of mobile
information systems and services
Authors: Kristian Saksvik Munkvold
Karolina Anna Matyja Aleksandra Hrpka
Amund Øgar Meisal
Institutt for informatikk UNIVERSITETET I OSLO
22.11.2013
2
Table of Contents Abstract ................................................................................................................................. 3
Introduction ........................................................................................................................ 3 Project goal and research questions .................................................................................... 4
Prestudy and theory ......................................................................................................... 4 Usability aspects ......................................................................................................................... 5 Contex-‐awareness ...................................................................................................................... 6 Technical background .............................................................................................................. 7 Integration with ecology .......................................................................................................... 8
Case and method ................................................................................................................ 8 User-‐Centered Design(UCD) ............................................................................................................... 8
Methods ......................................................................................................................................... 9 Future workshop ..................................................................................................................................... 9
Technical aspects .................................................................................................................... 10 Usability testing ..................................................................................................................................... 11
Plan for evaluation .................................................................................................................. 11
Findings ............................................................................................................................. 12 Future workshop ..................................................................................................................... 12 Workshop results .................................................................................................................... 12 Prototype ................................................................................................................................... 13 Usability testing ....................................................................................................................... 14 Usability testing results ..................................................................................................................... 15
Discussion ......................................................................................................................... 16
Conclusion ......................................................................................................................... 18
References ........................................................................................................................ 20
Appendix ........................................................................................................................... 22 Appendix A: Use cases ............................................................................................................ 22 Appendix B: Scenarios ........................................................................................................... 22 1. Use of different platforms ............................................................................................................ 22 2. Feedback from users ...................................................................................................................... 23 3. Happenings @IFI .............................................................................................................................. 23
Appendix C: Plan for user testing: ..................................................................................... 23 Appendix D: ............................................................................................................................... 25 Table showing which functions were implemented in the application. ....................... 25
3
Abstract
This project deals with the development of a mobile information system (application),
which helps students solve context-based issues. The functionality explored in depth
for this application is how to find an available room. We will run you through the
process of gathering requirements for such an application with a user centered design
approach. We will go into depth of how to create a functional high-fidelity prototype
for the mobile platform, which with easy steps may evolve into a full blown app. We
will address the usability aspect of our prototype for this application. Each of these
parts will be described in depth and discussed.
Introduction We live in a time where smartphones are becoming a natural part of our everyday life.
For Norwegian Internet users, there’s a considerable amount of 68 percent that have
their own smartphone. In 2012, 42 percent of these smartphone users use the Internet
on their phone as a part of their daily life (MediaNorge 2013). It seems to shape how
people interact, how they structure their daily life and is becoming a more and more
important part of their daily life. Smartphone apps may provide users with tools that
earlier only could be solved on the computer or through a help desk. Some of these
apps help users solve tasks while they are on the go. Examples of such apps are
RuterReise (Ruter 2013) and Google Maps (Google Maps 2013). RuterReise provides
real-time data and timetables for all public transportation in Oslo. Google Maps is an
interactive map of the world, granting their users a free to use GPS navigation system.
In this project we will try to create a context-based application for Ole Johan Dahls
House (OJD).
OJD was opened in 2011 by the University of Oslo. It’s the newest building made for
the Department of Informatics and referred to as “Norway’s new IT mecca” (Digi.no
2011). The building is 28 250m2 in size (IFI2 2006), which makes a simple task like
finding a room based on its name or number a challenge. If you are not familiar with
the building. As familiarity increases, a single issue becomes clear. How can we
easily locate an available room in this building? With this issue in mind we wanted to
explore the possibility for developing an application which may solve this issue. In
4
this project we will gather requirements for such an application, and develop a
prototype for this mobile information system.
Project goal and research questions
The project will focus on solving issues for bachelor students in the context of Ole-
Johan Dahls hus by designing and developing an application. During the project we
will explore the following questions in depth:
• How may we create an application which satisfies the students needs at Ole-
Johan Dahls hus?
• How may we effectively prototype for such a system on the mobile platform?
• How does the prototype score in regards to usability?
Sketch 1 Context for the application
Prestudy and theory As a part of a prestudy we conducted a review of research papers which contained
similar cases and investigated relevant material for our project. Two of the
participants of this group has also been investigating the issue in question in relation
to a prior course named “INF1510 - user-centered design” in 2011.
5
Picture 1: The prototype made by Raptor/Mapster in "INF1510 - user-centered design" in 2011
In this course they were developing a prototype for a stationary device for helping
users find available rooms at OJD. The device was based on Arduino technology and
had a graphical map of OJD with three floors and a legend. LED lights were placed
into each room in the second floor to show how the rooms availability could be
represented. The prototype was connected to a system which evaluated if the different
rooms were available or not. This was done by checking if any user was logged into
the computer in the room. If a room was available, the LED showed green and if not it
showed red. This technical solution for showing room availability has some flaws. As
users are frequently visiting the rooms without using the integrated computers, a room
which is taken may be shown as available. A valid and reliable way of establishing if
a room is available or not, is one of the central aspects of this mobile information
system.
Usability aspects As a part of our prestudy we delved into existing literature dealing with similar issues.
One of the articles we looked into was «Aspects of Personal Navigation With
Collaborative User Feedback» (Holone et.al., 2008). The main issue of the article
was navigation in buildings for disabled people. They had developed a prototype of a
mobile application for their users to test. The application relied on crowd sourcing to
provide their users with correct navigational data. In practice this meant that the
6
prototype suggested a route for the user to take. If the route contained any obstacles,
the user had to press a button to rate the route as “Bad” to get a new route. In this
article they portray the results from their usability testing, and give a fair evaluation of
the data uncovered. They described three usability criterias for evaluation:
1. Effectiveness
2. Efficiency
3. Satisfaction
These usability criterias may provide us with a solid framework for evaluating the
usability of our prototype.
Contex-awareness During the preface of the project we studied “Changing Places: Contexts of
Awareness in Computing” (Agre, 2001). Agre argues that wireless information
services “complicates the analysis of context for purposes of designing context-aware
computing systems”. He explains that context is becoming more complex because the
context’s boundaries are becoming more blurred. Agre reasons that wireless
information services are the reason for why this happens.
In his paper he provides an example of a very distinct context; the theatre. The theatre
has clear boundaries to its context. It has “architectural” boundaries i.e. the physical
walls of the theatre. Also applicable to the theatre context is the “institutions” and
“practices”. By institutions Agre is referring to the defined set of social roles e.g. the
ticket clerk, and by practices he means “the embodied routines that a articular
community of people has evolved for doing particular thing in a particular place”. An
example of a practice could be that the audience should not talk during the
performance.
As wireless information services has made its way into our everyday lives the
mapping between institutions and architecture loosens. The context of the theatre
might not have changed much, but since the mapping between other institutions and
architectures have loosened the theatre is introduced these exogenous disruptions. A
typical exogenous disruption in a theatre is a mobile phone ringing. It might be
someone’s boss calling to remind someone about a meeting. This disruption can
7
happen because the context of the work area has changed due to the introduction of
wireless information services.
The context of OJD is not as defined as a theatre. The building is used in different
ways and is designed fit meet all these different purposes. As a result there is no
distinct institutions or practices either. One can argue that there are differences
between students, teachers and the employees in the cafeteria, but there are no strict
practices defined between these institutions in OJD. Thus our project is somewhere in
the middle ground and it is important to be context-aware during the development.
Technical background As the idea behind our mobile application was room availability, an important part
was establishing that it’s possible to create a reliable system for this. As part of this
inquiry we conducted an interview with the chief of operations at the University of
Oslo, Terje Knudsen. He made it become clear that OJD uses a KNX system which is
installed in the building. KNX is a worldwide standard for home and building control,
and is mainly used as a tool for maintaining lighting, blinds and shutters, energy
management, etc (KNX 2013). Sensors are implemented as a part of every room, and
this includes motion sensors. This will simplify the process of implementing a reliable
room availability system, but there’s one issue that must be resolved before it’s
possible to create this system. The operations department lacks organizational
information of which sensors is in which rooms, and they are currently lacking
resources for implementing such a system. Knudsen assures us that such a system is
on the list of a “want-to-have” system for OJD, but currently there’s a lot of “need-
to-have” systems with higher priorities. This means that before the room availability
system based on KNX is developed and available for use, this aspect of the
application must be solved in a different way. We will address this later in this report.
The technical aspects of developing the mobile application was a highly prioritized
aspect of this prestudy. We wanted to look into opportunities for high-fidelity
prototyping for the mobile platform. The article «Mobile Application Development:
Web vs. Native» (Charland & Leroux, 2011) deals a significant argument for how to
do mobile application development. Developing a platform independent mobile
application may be done through the web platform. Its main drawback is in
performance, and it’s a good way to make sure that the application will be able to run
8
on every single platform. This is made possible through the use of the smartphones
browser, which uses HTML, CSS and JavaScript. If the application needs to access
something that’s phone specific, camera, GPS or similar, this is possible by taking
your application through PhoneGap (Adobe, 2013), an open source framework. This
takes a web-application and applies a wrapper which makes it possible to deploy it as
a native application to the phone platform of your choice. This approach to making
mobile applications provides an insight into the prototyping possibilities. high-fidelity
prototyping may be done as a web application, and usability tested on the users own
smartphone through their browsers.
Integration with ecology The application is contextually bound to OJD and OJD has an existing ecology which
the application is dependent on. The article «Toward a framework for ecologies of
artifacts: how are digital artifacts interconnected within a personal life?» (Jung et.al.,
2008) discuss how a specific ecology is influenced by introducing new artifacts. The
app is interacting, not only with the end users, but also with different systems which
can be found in the building. An important aspect for the app is to consider the
existing ecology in OJD.
Case and method This project will gather requirements for and create a vertical high-fidelity prototype
for a context-based application. We will not create a fully functional application, or
start to implement a back-end system. Instead, we will focus on creating a prototype
which easily can evolve into an application integrated with different systems. As we
create a single functional prototype, Web Content Accessibility Guidelines (WCAG)
will not be a priority. If the prototype is to evolve into an application, WCAG will be
a high priority as the application should be usable for all the users of OJD. The
primary user group for this app are students using OJD. The main use context is OJD.
User-Centered Design(UCD)
During our research, we have chosen to keep a user-centered design (UCD) approach.
UXPA: Usability Resources explain UCD as an approach where the users are
involved and focused on “through the planning, design and development of a
product”. As Maguire points out in his paper Methods to support human-centred
9
design, the fact that an interactive system is usable is crucial when measuring its
success. He points out several benefits that a system acquires through use of UCD,
amongst which is the fact that it improves acceptance (Maquire, 2001, pp.587-588).
Developing our application with this in mind may increase our chances of success.
Development of this application will be done by iterating the following four main
activities: understand the context of use, specify requirements, produce design
solutions and evaluate designs (See Figure 1).
Figure 1: This model is from the website: "UXPA: Usability Resources", and shows four typical activities in
a UCD process model
Methods
Future workshop
Within the UCD approach, we have used a method called Future Workshop which is
derived from the field of Participatory Design (PD) (Brandt et.al, 2013, 152-53).
Sanders and Stappers point out in their article Co-creation and the new landscapes of
design that UCD and PD approach are influencing one another and the methodologies
are becoming more intertwined. Where UCD on one hand treats the users as a
“subject”, the PD approach considers the users as a “partner” (Sanders & Stappers,
2008, pp.5-6). As the target group for our application were students at OJD, making
them central in the establishment of requirements for the application was critical.
Future workshops normally consists of three phases. In the first phase the purpose is
to criticize everything that is wrong with the existing solution of the problem, and
with the problem itself. Users were encouraged to discuss problematic issues
regarding navigating in OJD. The second phase was about generating utopian ideas. It
10
addressed the issues from the first phase and the goal was to create any solutions they
could think of. The third and last phase of the workshop was the realization phase.
Based on their utopian solutions, users had to rethink within the limitations of the
reality we live in. The results of this phase were based on the biggest problems from
phase one, and the best ideas from phase number two. (Brandt et. al. 2013: 152). A
big advantage with this method is that it gives the possibility to develop ideas that are
more focused, organized and systematic. General brainstorming of ideas about the
problem area would not fit, because it wouldn’t be as focused as we wanted (Brandt
et.al., 2013, pp.152-153).
Based on the data from future workshop, we will create scenarios (Sharp et. al. 2009,
p.505) and use cases. The scenarios will be based on the most recurring issues from
the results. They describe situations where a potential user struggles with today´s
situation and how the user may use our application to solve it. Use cases will be used
to create a list of the different goals and functions that has to be developed to address
requirements of the target group. This will be helpful to organize and concretizing
which functions that were important to develop.
Technical aspects The results from the workshop will be the basis of the development of a vertical high-
fidelity prototype. This is because we want to prototype the details of few main
functions (Preece et.al., 2007, p.537). When planning the development of the
application, an important factor was being able to easily redesign and evaluate. A
criteria for the development process was that we could deploy the high-fidelity
prototypes to a web server for testing in the browser of a random users smartphone. In
this way, we could develop an application and get continuous evaluation and
feedback. Based on the results from our prestudy, the decision was made to make a
platform-independent web-application. This approach made it easy to get started with
prototyping. Based on the results from the workshop, we will generate test data which
represents the different ecologies our system depends on. This means that the
application may be connected to the already existing ecology at OJD, but as the most
important part of the systems are still unavailable, we will rely on test data for now.
The test data is stored as JavaScript Object Notation (JSON), which is a lightweight
data-interchange format.
11
In order to create a platform-independent application we have used Hyper Text
Markup Language (HTML). HTML is the core language of nearly all Web content.
Most of what is seen on screen in a browser is described, fundamentally, using
HTML. Along with the HTML we have used Cascading Style Sheets (CSS) which is
a stylesheet language used to describe the presentation of a document written in
HTML. Together with Bootstrap we have been able to quickly form and change
prototypes during the development phase. Bootstrap is a CSS and JavaScript(JS)
framework that provides developers with a variety of boilerplate tools and
components for rapidly creating responsive user interfaces for the web platform. As
the application consists of dynamic data we have used a variety of technologies in
order to handle and manipulate these data. JS is a lightweight, interpreted, object-
oriented language, which together with a library named jQuery enables efficient
document traversal and manipulation.
Usability testing
When we have a prototype ready, we will conduct a user-based, summative usability
test.(Lazar et.al., 2010, p.260). We will test with users that are representative for our
target group and they will perform realistic user tasks in the application. The goal is to
evaluate the effectiveness of the high-fidelity prototype (Lazar et.al., 2010, p.260).
“Usability testing, in general, involves representative users attempting representative
tasks in representative environments, on early prototypes of computer interfaces”
(Lewis et.al., 2010, p.252).
Plan for evaluation When the prototype is ready for evaluation, we will use the definitions put forward by
Holone. The concepts of effectiveness, efficiency and satisfaction will drive the
evaluation of the app. The following list consists of questions based on these usability
criterias.
Effectiveness:
• Does the application @IFI work?
• Does the application provide users with a solution for finding an available
room?
Efficiency:
12
• How does the learning outcome influence the way information about available
rooms is provided to users?
Satisfaction:
• Is the application useful?
• Would the users use it in real life?
Findings
Future workshop The future workshop consisted of eleven informatics bachelor students that were
divided into three groups. The execution went well and we observed the participants
without influencing their discussions. After finishing the three phases, each group
presented their findings and explained their ideas.
Workshop results
Graph 1: Bar chart table with results from the workshop.
According to graph 1, the results of the workshop indicate that the participating
groups agree that the application should have the following functionality:
• A better map and overview of the building.
• Functionality for finding a free computer and available group rooms.
• Feedback for reporting faulty or missing equipment in the different rooms.
13
One may also see that two out of three groups want to be able to book a room, set
time limits for the use of group rooms, to show the time schedule for a selected room
and the opening hours.
For an overview over the scenarios and uses cases based on these results, see
appendix A and B.
Prototype
The design of the application prototype was based on the results from the workshop.
The first functional prototype was a vertical high-fidelity prototype which focused on
the usability of the functionality “Find room”. As shown in Picture 2, the start page of
the application is a menu system, where you can choose between three different menu
options in Norwegian.
• Romoversikt / Room overview
• Hva skjer? / What’s happening
• Praktisk informasjon / Practical information
The three other screens show the different layouts for the different pages. “Room
overview” gives the user the possibility to filter the rooms based on the floor or
availability.
14
Picture 2: Screenshots from the high-fidelity prototype.
The prototype is made as a web application, which made it possible for us to test it on
any smartphone with connection to the internet. The prototype is available for test on
the following url: http://www.krsjan.com/mapp/v1/
Usability testing
The usability testing was conducted according to a testing plan that we wrote by using
general guidelines for planning usability testing from “Praktisk Brukertesting”
(Toftøy-Andersen & Wold, 2011, p.38), see appendix C. We restricted the selection to
bachelor students at OJD. They were selected randomly and given tasks that are
presented in graph 2.
15
Usability testing results
Graph 2: Bar chart table with the assignment results from the usability test.
According to graph 2, the application may have some usability issues. Only 3 out of
10 participants managed to return to the main menu. 4 out of 10 did not understand
how to find the printer overview and did not see that there were buttons at the bottom
of the application that controlled which floor the application was showing (See
Picture 2). And at the same time, only 5 participants found an available colloquium
room. 8 participants managed to figure out if there were any events going on in the
room "ADA", and all of the participants managed to see if the auditorium "Smalltalk"
was available.
Graph 3: Bar chart table with user feedback after finishing the usability test.
Graph 3 shows an overall user satisfaction. 10 out of 10 participants said that they
would use our application. Four of them meant the application was responding too
slow. Three of the participants wanted the following:
16
• Printer overview in the same category as the room overview
• Search for rooms by name or number
• Different name for the menu option "Practical information"
Two participants meant that the application should be able to filter the room overview
based on the room type and that if there is no events in a room that day, that should be
explained. Only a single participant wanted a map of the floors.
Discussion When gathering requirements for a mobile application, it is important to involve the
user as a part of the process. In our project we conducted a future workshop to see if
our assumptions of OJDs issues were correct. This turned out to be of great value to
the further development of the application. As users were put in a context where they
could envision their utopian ideas, important perspectives emerged. It became clear
that existing solutions in OJD were an important factor for the implementation of the
app. In the technological mecca of OJD, there exists a vast ecology of technological
information systems. Only some of them are available for students. This includes:
• Information screens which show relevant information about transportation and
events
• Finnrom, a desktop web application which makes it possible to book and view
room schedules
• Physical maps over the building
• Google calendar which contains the events made by student unions
Using the existing ecology will be an important feature of this application. By not
using the existing information systems as a part of our application, we will be faced
with major maintenance and reliability issues. This would have included manually
updating the app with information, which may lead to errors in the information
provided. As Jung et.al point out, «Every newly designed interactive artifact will
inevitably become a part of someone’s ecology» (Jung et.al., 2008, p.202). As our
application inevitably will become a part of OJDs ecology, there is no reason to not
17
embrace it. Therefore we wanted to create a flexible application which easily
integrates into any system.
Gathering the requirements for the application was a profoundly interesting part of the
project. We realized that the use context for this application is a general issue. Room
availability systems are a known system type, and what makes the systems unique is
their context. We may also argue that the systems requirements may evolve into a
general one, which can be integrated into student contexts all over the world.
An important factor to consider in such an application is platform dependency. There
is a unique ecology of smartphones existing in today’s society. Mobile technologies
are rapidly evolving, and there is no way of telling which kind of devices our users
will possess. The platform dependency is therefore a crucial factor for the success of
such an application. To truly be platform independent, using web technology is the
only solution. This is because running web technology is only dependent on a browser
and independent from any OS. Smartphones must support these technologies, as it is
the basis for most web content. The major drawback for this approach is the
performance. This is due to the fact that a native application is run directly on the core
operative system of the mobile phone, but a web application will be run through the
browser which is using different programming languages. The enormous use of the
internet on smartphones has created a competitive mindset between smartphone
companies towards creating the most efficient performance for web technology
(Charland & Leroux, 2011). Therefore there is hope for a performance boost for web
applications in the future. The mobile technology is rapidly evolving, and the
performance gap between web and native is decreasing. These arguments made us
choose web technology for development. As there is a massive community for
developing web applications, open source frameworks supporting rapid mobile-first
web application development were not hard to find. The prototype was developed
using Bootstrap, which enabled us to quickly develop a responsive web application.
The technologies chosen gave us a supportive and easy framework for prototyping
effectively. Bootstrap also provides a framework which contains solutions to mobile
usability-issues.
Based on our evaluation plan and the criterias set by Holone et.al. (2008), we have
conducted usability tests. All users participating indicated that it was useful and they
18
would use the application. This indicates that the users scored high regards to the term
satisfaction. One may argument that this is one of the most important aspects early on
in the development of a mobile information system. We were hoping to uncover if the
application assists users in finding an available room quickly, and if there was any
learning effect. As we did not track the time for each task during the usability testing,
we do not have a reliable data set to determine the efficiency of our application. The
results from the usability testing are therefore useless when it comes to efficiency. We
wanted to make sure that the prototype was designed in such a way that the users
could solve their tasks effectively. During the testing, 61 percent of the given tasks
were solved successfully. 70 percent of the given tasks which included the find-a-
room functionality were successful. This indicates that we have work to do regarding
the usability aspect of the application. We may conclude that the application works,
but it has some usability issues.
The goal of this project has been to develop a high fidelity prototype for a mobile
information system. The purpose of the system was to provide the users of OJD with
an easy way of finding available rooms. The workshop was an important step in the
direction of understanding the needs of our users and the context in which the system
was to be used. As mentioned earlier, Agre (2011) discusses that the mapping
between the institutions and architecture is dissolved by the wireless information
service making the process of identifying and defining the context harder. We can
argue that the application is not context-aware, because the application is not aware of
its location when it is used. The application collects data from the Internet and is not
depending on being inside or near OJD. This application isn’t context-aware, it is
context-based.
Conclusion In this project we have used a future workshop as a method to discover the needs and
requirements of the bachelor students. Based on the discovered data we have
developed a high-fidelity prototype that gives an overview over rooms at OJD. By
using web technology, we could quickly develop a functional prototype and test on
the mobile platform easily to find out if the constitution of the application is intuitive.
The results of the usability testing showed that it was effective and satisfying, but that
19
there are usability issues which must be addressed. Through this project we have
learned how the process of developing a mobile application works. Due to the lack of
time and capacity our application is not finished, but we still managed to gather
enough data to give a tentative conclusion to our research questions. We know now
that there is a need for an application like ours to be developed and used at OJD, to
relieve the students and make their daily life better.
20
References
Agre, Philip E., 2001 “Changing place: Contexts of awareness in computing”.
Interactions.
CSS, Mozilla Developer Network, “CSS”, https://developer.mozilla.org/en-
US/docs/Web/CSS [retrieved 21.11.2013]
Digi.no 2011, “Norges nye IT-mekka” http://www.digi.no/860112/norges-nye-it-
mekka [retrieved 14.10.2013]
Google Developers 2013, “Google Calendar API”
https://developers.google.com/google-apps/calendar/ [retrieved 17.11.2013]
Google Maps 2013, “Startside” http://www.google.com/maps/about/ [retrieved
22.11.2013]
Holone, H., Misund, G., Tolsby, H., Kristoffersen, S., 2008, “Aspects of Personal
Navigation with Collaborative User Feedback” NordiCHI. October 20-22, Lund,
Sweden URL http://delivery.acm.org/10.1145/1470000/1463180/p182-
holone.pdf?ip=193.157.254.234&id=1463180&acc=ACTIVE%20SERVICE&key=C
2716FEBFA981EF12AF33E0C843ED67530B3370CE24A4EE3&CFID=263464989
&CFTOKEN=33522344&__acm__=1385056983_24e0cc3741dcb4e0d478c8c363656
49f [retrieved 21.11.2013]
HTML, Mozilla Developer Network, ”HTML” https://developer.mozilla.org/en-
US/docs/Web/HTML [retrieved 21.11.2013]
IFI2 2006, “Om prosjektet” http://www.ifi.uio.no/ifi2/index.php?art=omprosjektet
[retrieved 16.10.2013]
JavaScript, Mozilla Developer Network, https://developer.mozilla.org/en-
US/docs/Web/JavaScript
Jung, H., Stolterman, E., Ryan, W., Thompson, T., Siegel, M., 2008, “Toward a
framework for ecologies of artifacts: how are digital artifacts interconnected within a
personal life?” NordiCHI 2008: Using Bridges. 18-22 October, Lund, Sweden. URL:
http://delivery.acm.org/10.1145/1470000/1463182/p201-
jung.pdf?ip=193.157.253.221&id=1463182&acc=ACTIVE%20SERVICE&key=C27
16FEBFA981EF12AF33E0C843ED67530B3370CE24A4EE3&CFID=261525972&
CFTOKEN=88329674&__acm__=1384453473_ced60b262365816b32d739b08f69ea
87 [retrieved 14.11.2013]
21
jQuery, ”jQuery, write less, do more”, http://jquery.com/ [retireved 21.11.2013]
Lazar. J., Feng. J.H., Hochheiser. H., 2010, “Research Methods in Human-Computer
Interaction”. Wiley
Maguire, Martin, 2001, Methods to support human-centred design. Academic Press.
MediaNorge 2013, “Mobil og mediebrett – tal og trendar”
http://medienorge.uib.no/files/nyhetsbrev/2013/Mobil_mediebrett.pdf [retrieved
14.10.2013]
Ruter 2013 “Ruters apper – RuterBillett og RuterReise” https://ruter.no/verdt-a-
vite/app/ [retrieved 22.11.2013]
Sanders, E. B-N., & Stappers, P.J. (2008) Co-creation and the new landscapes of
design, CoDesign International Journal of CoCreation in Design and the Arts, 4(1),
5-18.
Toftøy-Andersen. E., Wold. J. G., 2011, “Praktisk brukertesting”, Cappelen Damm
Akademisk
Universitetet i Oslo 2013, “Finnrom - Høst” https://sci-
ent02.uio.no/WebRoomBooking/Login.aspx?ReturnUrl=%2fwebroombooking%2fbo
ok.aspx [retrieved 17.11.2013]
UXPA: Usability Resources, “What is User Centered Design”
http://www.usabilityprofessionals.org/usability_resources/about_usability/what_is_uc
d.html [retrieved 20.11.2013]
22
Appendix
Appendix A: Use cases After going through the post-it notes provided by our three groups, we summed up
their thoughts and ideas through following use cases:
• Find available room
• Show map
• Show events
• Show opening hours
• Report a technical issue
• Show public transit information
• Show printers
• Report an application issue
Appendix B: Scenarios
1. Use of different platforms
Today: Catherine and Markus are both students at Informatics: Design, use,
interaction.
They take a few courses together and today they are having a group meeting in one of
the courses. After traversing the halls at IFI2 looking for an available colloquium
room without any luck, they decide to wait in the cafeteria. Catherine uses her laptop
and Markus a tablet. The other group members are late. Suddenly Catherine gets a
phone call. One of the group members, Aleksander, has found an available room, and
asks them to come.
With @IFI: Catherine and Markus are both students at Informatics: Design, use,
interaction. They take a few courses together and today they are having a group
meeting in one of the courses. Catherine checks her @IFI application on her
smartphone to see if there’s any free colloquium rooms. Everything is taken. They
wait in the cafeteria. Catherine uses her laptop and Markus a tablet. After a while,
23
Markus decides to check if there’s a room available now with his @IFI application on
his tablet. There’s a free colloquium room on the third floor. They go there together.
2. Feedback from users
Today: Anne is sitting with her group in a colloquium room. They have been there
for quite a while discussing the report, but just begun working. One of the cables were
broken, and they used a good period of time trying to overcome technical difficulties
when connecting her laptop to the television. After several failed attempts, they
decided to work on the desktop computer.
With @IFI: Anne is sitting with her group in a colloquium room. They have been
there for quite a while discussing the report, but just begun working. One of the cables
were broken so they quickly sent a feedback through the @IFI application. After 5
minutes of waiting, a person from Drift was there to help them.
3. Happenings @IFI
Today: It´s thursday and some students are done with lectures 4 P.M. They are sitting
in the corridor on the first floor. On the opposite wall there are some posters about
upcoming events. After reading some, they realize that they have missed some cool
courses in HTML5 and Scala. As they read on they find one event that starts at 5 P.M
the same day. They discuss whether to go or not, and ends up by walking into
Smalltalk where the event is scheduled to be.
With @IFI: It´s thursday and some students are done with lectures 4 P.M. They are
sitting in the corridor on the first floor. They are talking about a HTML5 workshop
that they went to yesterday. While they are chatting about this, one of the students
opens the @IFI application and browse for some social events. After some time he
suggests another workshop at Smalltalk they can attend.
Appendix C: Plan for user testing: Objective: Proof of concept
We wanted to find out if our prototype satisfies the following:
- the users needs
- the users requirements
24
- the main functional requirements
- if the application is intuitive
- test the color spectrum
- usability goals: satisfaction, efficiency and effectiveness.
What will be tested: Functionality
- Room overview
- Missing functionality
- Unnecessary functionality
- If there are any problems with use of different phones, browsers, operating systems
and different or outdated versions of them.
Type of system:
A responsive web application, found on: http://www.krsjan.com/mapp/v1/.
Who is testing:
Selected users that fit our target group.
Where are we testing:
The testing will take place in users natural environment, OJD.
What kind of test equipment:
The users will need a cell phone. If they don’t have one, the test personnel shall
provide them with one during the testing.
Assignments:
- Find a free colloquium room
- Which rooms are unavailable on the third floor?
- Find the printer named Caslon
- Are there any events at the room ADA today?
- Go to main menu
- Is the auditorium named Smalltalk available?
Testing schedule:
25
From 10 a.m. to 12 p.m. on wednesday the 6th of november.
Questions to users before the testing:
1. Are you a bachelor student?
2. Are you interested in testing our application?
Questions to users after the testing:
1. Is there some functionality something missing?
2. Is there something that you would like to change about this application?
3. Would you use this application?
Test team:
Karolina and Aleksandra
How are we going to convey the findings:
By inputting the results into a table and generating bar charts.
Appendix D:
Table showing which functions were implemented in the application.
FUNCTION YES NO
Find available room X
Show map X
Show events X
Show opening hours X
Report a technical issue
X
Show public transit information
X
Show printers X
Report an application issue X
26
