Video Conferencing

- User Interface with a Remote Control

for TV-sets

Alexander Freysson & Catarina Sörensen

Master's Thesis

Department of Design Sciences

Lund University

EAT 2015
 Abstract

By using Axis pan/tilt/zoom cameras it is possible to create a simple, high

quality video conference system, without the need for a separate computer
to control the system. This can be achieved by connecting the camera to a
standard television set and utilize open standards like the HDMI feature Con-
sumer Electronics Control (CEC). With CEC it should be possible to control
the system using a standard TV remote control, thus moving a major part of
the user interaction to an external device. Though this approach has its ben-
efits by removing the need for Axis to provide a separate remote control, it
also sets higher requirements on the user interface. Especially with regards to
the usability since TV remote controls differ in many ways depending on the
manufacturer.

A user interface with a TV remote control solution has been prototyped and
implemented demonstrating a peer-to-peer video conference system. This was
done through the use of on-screen displays, an iterative design process with
multiple usability tests and an evaluation of similar video conference products
as a basis. The test results shows that a prototype with high usability was cre-
ated which the users felt confident using.

Keywords: Video Conference, Remote Control, Usability, Interaction design, CEC

ii
Acknowledgements

We would like to thank Niklas Svensson for his help with the techncial parts of this thesis
and also our two supervisors John Rehn and Joakim Eriksson for all the good advise. The
parallel master thesis by Marcus Carlberg and Christoffer Stengren also in video confer-
ence project has always been supporting and been given relevant advises. Last but not
least we want to thank everyone we have come in contact with that has helped us at Axis
Communication.

iii
iv
Contents

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Similar work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.1 Market overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.2 Iterative design process . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.1 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.2 Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Overview of thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Technical background 5
2.1 High Definition Multimedia Interface . . . . . . . . . . . . . . . . . . . 5
2.2 Consumer Electronic Control . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 PTZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Theoretical background 13
3.1 Interaction Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 User-centered Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Cognitive graphical design . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Designing the user interface . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 Card sorting method . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1 LO-FI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

v
CONTENTS

3.5.2 HI-FI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Usability evaluation methods . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6.2 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6.3 Usability inspection . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.4 Usability testing . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Video conference systems

A market overview of similar products 19
4.1 Axis UtilityCam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Different products on the market . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1 Set-tops and other dedicated systems . . . . . . . . . . . . . . . . 20
4.2.2 Software based systems . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Methods for evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1 Menu system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.2 Remote controls . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 First iteration :
Requirements & concepts 29
5.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.2 Exploratory testing . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.3 Heuristic evaluation . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.2 Exploratory testing . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.3 Heuristic evaluation . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Second iteration :
Design & prototyping 37
6.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.1.2 Assessment testing . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.2 Assessment testing . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.3 Results from open discussion . . . . . . . . . . . . . . . . . . . . 41
6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3.1 Error sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7 Third iteration :
Graphic design & high level prototypes 45
7.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

vi
 CONTENTS

7.2 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8 Implementation 49
8.1 Overview of the setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.2 CEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.3 Overlays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.4 Technical Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9 Conclusion and discussion 53

9.1 Technical restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.2 Alternative solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.3 Suggestions for future development . . . . . . . . . . . . . . . . . . . . . 55

References 57

Appendix A 10 Usability Heuristics for User Interface Design 63

Appendix B Script for usability testing iteration 1 65

Appendix C Test plan iteration 2 67

Appendix D Debriefing survey iteration 2 71

vii
CONTENTS

viii
Terminology

Abbreviations
API Application Protocol Interface

CEC Consumer Electronic Control

HDMI High-Definition Multimedia Interface

HI-FI High-fidelity

LO-FI Low-fidelity

PTZ Pan-Tilt-Zoom

OSD On Screen Display

Concepts
Local camera A video conferencing camera that is present and captures the user.

Remote camera A video conferencing camera which is on a different location, capturing

the other praticipants in the video conference.

Daemon In multitasking computer operating systems, a daemon is a computer

program that runs as a background process, rather than being under the direct control of
an interactive user [1].

ix
CONTENTS

Vapix VAPIX in an open API created by Axis that uses standard protocols to
enable integration into a wide range of solutions on different platforms. Almost all func-
tionality available in Axis products can be controlled using VAPIX. [2]

Test Person The test person is the person who are performing a usability test.

x
Chapter 1
Introduction

1.1 Background
Axis Communications AB is a company that primary develops network cameras, the com-
pany’s origin is in Sweden with the headquarter in Lund. The company is at the moment
the market leader in network based video surveillance, Axis is also a driving force in the
transition from analog to digital video surveillance. The number of employees at Axis is
around 1600 worldwide and the headquarter hosts around 1000 of them [3].

AXIS cameras contain a processor chip and can be used for much more areas than just
surveillance, without complementing hardware it could be possible to make video confer-
ence calls and therefore entering on a new market with this desirable feature. For example,
connecting the camera directly to a screen and holding a video conference should work
well without the need of a computer which many of the solutions on the market require.
In our thesis we will use a standard TV remote control to a HDMI compliant TV, use on
overlays to configure the cameras through CEC.

1.2 Similar work

Three master’s theses regarding video conferencing were conducted simultaneously on
Axis Communications, this master’s thesis was one of them. Marcus Carlberg and Christof-
fer Stengren (not yet published) investigated different approaches to varying bandwidth,
explored different algorithms for optimized bandwidth usage and investigated H.264 error
resilience. More closely they implemented and evaluated three TCP congestion control al-
gorithms to achieve this. Michael Sköldegren and Christoffer Timelius (not yet published)
wrote the other master’s thesis were they investigated the video conference market.

1
1. Introduction

1.3 Purpose
The purpose of this masters thesis was to investigate how CEC, TV remote control user
interaction and a high usability GUI can be introduced to and prototyped on an Axis PTZ
camera. The purpose was to make it easier to have video conferencing sessions with no
need for a separate computer to control the system and where all configurations are made
with a standard TV remote control. By using open standards the user should only need an
Axis PTZ camera along with standard television set thus having a plug-and-play experi-
ence. By prototyping this it will be easier to take the next step and in the future make the
prototype into a real product.

The main goal of the thesis is to design and prototype an intuitive interface combined with
a standard TV remote control for a video conferencing system using Axis hardware and
software and standard AV equipment. To achieve this a set of goals has been set up.

• Make a usability evaluation of similar products to identify good and bad video con-
ference interfaces and designs to get a better understanding of how to make a good
user interface for a video conference system.

• Make a working code prototype that shall demonstrate a bidirectional system where
it is possible to install the product, initiate a video conference and remotely control
the other camera’s pan/tilt/zoom functions, without the use of a computer.

• The design of the prototype shall focus on usability and ease of use. The prototype
shall be efficient to use, easy to learn and satisfactory to use. The user shall feel
confident in using the prototype.

1.4 Approach
A literature study was performed to find relevant theories within the area of usability and
also to find relevant technical information regarding HDMI and CEC.

1.4.1 Market overview

To get a basic understanding about the products on the market we evaluated some video
conference competitors. The result from the evaluation where used to base our product
on the good design choices we found. See section 4.3 Methods for evaluation for more on
this.

1.4.2 Iterative design process

The design process was divided into three phases. The first two phases consisted of design,
testing and evaluation, see figure 1.1, the third and last step consisted of design with the
creation of the final Hi-Fi prototype. See sections 5.1 Method, 6.1 Method and 7.1 Method
for more.

2
 1.5 Contribution

Figure 1.1: The design process circle which illustrates one itera-
tion.

1.4.3 Implementation
The implementation of the prototype was done parallel with the iterations. Initially a
set of minor programs was made to get a better understanding of how the camera works
and its different features. In the second and third iteration phase a Hi-Fi prototype was
implemented. Since the camera is Linux based, the implementation was made in the C
programming language. See chapter 8 Implementation for more on this.

1.5 Contribution
Following section describes the writers contribution to the thesis and how the work was
divided.

1.5.1 Development
Both Alexander and Catarina planned and did the exploratory testing and assessment test-
ing together along with most of the design of interfaces for the prototypes. Alexander was
responsible for the technical parts of the thesis.

Alexander
Alexander evaluated set-tops and their remote controls as a part of the evaluation of sim-
ilar products. Also wrote all code for the prototypes and configured them and made the
overlays for the prototype in the second iteration.

Catarina
Catarina evaluated software based systems as a part of the evaluation of similar products.
Also did the heuristic evaluation of the first iteration and made the overlays for the proto-

3
1. Introduction

type in the third iteration.

1.5.2 Report
The report was initially written together by both Alexander and Catarina and later on re-
sponsibilities for the different chapters was divided between the two. Alexander wrote the
abstract and was responsible for chapter 1, 2, 5 and 8 while Catarina was responsible for
chapter 3, 4, 6 and 7. Both were responsible for chapter 9. The chapters were mostly
written by the person who was responsible for them.

1.6 Overview of thesis

The thesis consists of two main parts. The first part, chapter 4, describes a market overview
of similar video conference products which were evaluated. The second main part is the
development of the video conference prototype which is divided into three iterations, chap-
ter 5, 6 and 7. For these chapters we go through the methods used, results and conclusions
drawn from the results. The implementation of the prototype is explained in chapter 8
which is followed by a discussion in chapter 9. Chapter 2 and 3 goes through relevant
technical and theoretical background where the used protocols, methods and other theory
are described briefly.

4
Chapter 2
Technical background

The Technical background chapter introduces the reader to the protocols and technologies
which were used throughout the thesis. The chapters’ purpose is to give the reader a better
understanding of the thesis’ technical aspects.

2.1 High Definition Multimedia Interface

HDMI is a digital audio/video interface for transferring video and audio from a HDMI-
compliant source device, known as a HDMI Source to a HDMI-compliant audio/video
receiver, also known as a HDMI Sink. HDMI Sources include DVD players, Blu-ray Disc
players, video game consoles, VCRs and cameras which can be linked together with HDMI
Sinks like TVs, projectors or monitors, or just about any other device capable of sending or
receiving an high-definition (HD) signal to create a HDMI system, such as a home theater
system. HDMI has become a modern replacement for previous standards such as com-
posite video, Separate Video (S-Video), Video Graphics Array (VGA) and Digital Visual
Interface (DVI). HDMI transmits all HDTV standards and supports up to 8 channels un-
compressed audio. HDMI is basically the same as the interface standard DVI for PCs and
displays but with the addition of audio, smaller connector and CEC [4].

The HDMI founders are Hitachi, Panasonic, Philips, Silicon Image, Sony, Thomson and
Toshiba [5]. With over two billion HDMI-enabled products shipped since the start of the
HDMI standard in 2003 it is the industry leading standard for audiovisual equipment and
has extended to a vast array of applications, devices and industries [6].

5
2. Technical background

2.2 Consumer Electronic Control

Consumer Electronics Control (CEC) is a protocol used in HDMI to provide high-level
control functions between various audiovisual products. It is based on the AV.link protocol
on the SCART standard and carries control data on a single wire bidirectional bus known
as the CEC line on the HDMI, see figure 2.1. This allows for transmission of audio, video
and control signal through a single cable. CEC was first utilized to carry remote control
data between TVs and DVD players. When a user inserts a DVD into the DVD-player, the
DVD-player starts playing and, using CEC, turns on the TV and switch the TV input to
the DVD-player. If a separate sound system is available it is also possible to reroute the
the sound from the DVD-player to the sound system via the TV. CEC makes it possible to
control all products in a home theatre system using only one remote control.

Figure 2.1: The HDMI connector pinout where the CEC pin (13)
is marked.

Even though CEC has been included in the HDMI standard since its start in 2002, only
the wiring is mandatory, the implementation of CEC in products is optional. This means
that all HDMI-compliant products does not allow for high-level control functions. Many
companies who choose to adapt CEC have their own trade names for CEC, see table 2.1.

Table 2.1: Companies and their trade name for CEC

Company Trade name

Insignia INlink
LG SimpLink
Onkyo RIHD
Panasonic VIERA Link
Philips EasyLink
Pioneer Kuro Link
Runco RuncoLink
Samsung Anynet+
Sharp Aquos Link
Sony BRAVIA Link
Toshiba REGZA-Link

The companies use different trade names partly due to vendor specific implementations
which often only guarantees full support of high-level control functions between products

6
 2.2 Consumer Electronic Control

from the same company, though in theory products supporting different trade names should
be able to work together and be able communicate entirely using the standardized CEC
commands. See section 2.2.3 Vendor Specific Commands for more on vendor specific
implementations.

2.2.1 Communication
The CEC communication is bidirectional which allows for both the HDMI Source and the
HDMI Sink to send and receive CEC messages. Since the control data is carried over
a single wire bus, the connected HDMI devices can not send messages simultaneously.
The device that receives a CEC message is called a Follower and is required to respond
to the message. The device that has just sent the CEC message is called a Initiator and, if
appropriate, waits for the Follower to respond to the message[7]. Both the HDMI Source
and HDMI Sink can take the roles as Initiator and Follower and will likely switch between
these roles multiple times during the communication session. In figure 2.2 Device 1 is the
Initiator and Device 2 is the Follower.

Figure 2.2: Sequence diagram of a sequence of directly addressed

CEC messages between two devices.

2.2.2 Messages
Frames and blocks
A CEC message, also called a frame, consist of a number of blocks. A block is always 10
bits long, where the first 8 are information bits followed by an end of message bit (EOM)
and an acknowledge bit (ACK) see table 2.2. The information bits differs depending on
which type of block it is. For header blocks information bits are the destination address,
bit 0 - 3, and the initiator address, bit 4 - 7. For data blocks they are opcodes or operands,
more on this under Data blocks in section 2.2.2. The end of message bit indicate if the
block is the final block of the frame, 1 meaning that it is the final block and 0 meaning that
one or more data blocks follow. The acknowledge bit is used by Follower to acknowledge
the block. It is always set to 1 by the Initiator and set to 0 by the Follower if it reads
its own address in the destination address. The block is then sent back to the Initiator.

7
2. Technical background

Therefor an ACK read 0 by the Initiator indicates a successful transmission of the block.
The control bits, EOM and ACK, are always present and always have the same usage. The
first block of a frame is always a header block and it is also always the only header block
in the frame. The number of data blocks differs depending on the type of message, e.g.
a ping message to ascertain that other devices are turned on contains only a header block
and no data blocks. The maximum frame size is 16 blocks, 16 × 10 bits. [8]

Table 2.2: Generic CEC block structure

Header/Data Block
7 6 5 4 3 2 1 0 - -
Information bits EOM ACK

Data blocks
There are two different types of data blocks. The first type is opcode (operation code)
blocks that has the purpose of describing what type of message is being sent. The 8 infor-
mation bits in opcode blocks are unique message identifiers, e.g. User Control Pressed,
which indicates that the user has pressed a button on the remote control, has the unique
value of 0x44, see section 2.2.3 Remote Control Pass Through for more on this. The other
type is operand blocks which contains parameters used by the message.

Table 2.3: CEC block structure of a message sent from the TV to a

recording device reporting that the Select button has been pressed
on the remote control.

Header Block
0 0 0 0 0 0 0 1 0 1
Initiator Destination EOM ACK

Opcode Block
0 1 0 0 0 1 0 0 0 1
User Control Pressed (0x44) EOM ACK

Operand Block
0 0 0 0 0 0 0 0 1 1
Select (0x00) EOM ACK

Table 2.3 shows an example of a message sent from the TV to a recording device. The
message contains three blocks sent in the order of header, opcode and operand block. The
header block contains the initiator address 0, which is the logical address of the TV, and the
destination address 1 which is the logical address for Recording device 1. Since a message
can only contain one header block and a opcode block must precede operand blocks, the
recording device knows that second block is an opcode block. By reading the unique id of

8
 2.2 Consumer Electronic Control

0x44 the recording device knows that the user has pressed a button on the remote control
and awaits a operand block describing which button it is. The information bits for the
operand block is 0x00 which is the unique id for the Select button. The recording device
now knows that the user has pressed the Select button on the remote control. Note that the
EOM of the operand block is set to 1 indicating the end of the message. Also not illustrated
in the table is the acknowledgements for each block sent from the recording device to the
TV.

2.2.3 Features
CEC provides a number of features designed to enhance the interoperability and function-
ality of devices within a HDMI system. Implementation of these features are optional but
if a CEC feature is supported, the feature has to be completely supported with all mes-
sages and their behaviour implemented. Not all feature are covered in this section, only
the features relevant for this theis.

Remote Control Pass Through

Remote Control Pass Through is a CEC feature which allow for HDMI devices to commu-
nicate within the HDMI system for when a user press and release a specific remote control
button. The feature enables a device, typically the TV, to pass through received remote
control commands to other devices within the system. Remote Control Pass Through in-
clude two types of messages, User Control Pressed which indicates when a specific button
has been pressed and User Control Released to inform that a button has been released.
User Control Pressed include one parameter, an id mapped to a specific button. User Con-
trol Released has no parameters and instead refer to the latest pressed button. The feature
is not restricted to only sending messages as a direct result of user interaction, thus not
always directly mapped to button on the remote control (or on the TV). For example, a TV
can offer a way to access a connected HDMI device’s root menu from a menu in the TV
UI.
When the user press and hold a remote control button for a period of time, the Initiator
repeatedly sends the same User Control Pressed message until the user releases the button.
The frequency of these messages are determined by the Initiator repetition time which is
a value between 200 ms and 500 ms, see figure 2.3 for an example on this behaviour . [9]

Vendor Specific Commands

This feature allows vendors to specify their own CEC messages to communicate between
devices. For this to be possible a device that support this feature must store a Vendor ID.
The Vendor ID is an id that is unique for that vendor, i.e. each trade name in table 2.1
corresponds to one Vendor ID. A communication with Vendor Specific Commands must
be initiated by an exchange of the devices’ Vendor IDs. If, and only if, the other device’s
Vendor ID matches a Vendor ID on the internal list of acceptable Vendor IDs, the com-
munication may continue. If the Vendor ID is not recognized then the incoming messages
will be ignored. With this feature it is possible for companies to add new messages and
functionality to CEC and tailor the communication for their devices. A common use of

9
2. Technical background

Figure 2.3: Sequence diagram for when a user presses and holds
down the Up key on the remote control for a period of time before
releasing the key.

the feature is to send messages about button presses which are not supported in Remote
Control Pass Through.

It is important to note that if a device supports a CEC feature it is not obliged to use that
feature before Vendor Specific Commands. For example, a device may support Remote
Control Pass Through but choose to send Vendor Specific Commands instead for commu-
nicating about remote control button presses for certain remote control buttons, even if
they are supported in Remote Control Pass Through. [10]

With the use of the open source Pulse-Eight project libCEC [11] along with hardware like
the credit card-sized single-board computer Raspberry Pi [12], it should be possible to
listen to Vendor Specific Commands messages and interpret them.

2.3 Overlay
Overlays is put on the picture from the camera block in the chip module. Overlay images
are converted from bitmap file format to a ovl file format and later on added. The overlays
can be in different sizes and there can be more than one at the same time. It is also possible
to make parts of an overlay transparent.

10
 2.4 PTZ

2.4 PTZ
PTZ is an abbreviation for Pan Tilt Zoom and is a term used for cameras. A PTZ camera
is capable of pan, tilt and zoom movements not available to stationary cameras.

Figure 2.4: Illustration of pan (horizontal) and tilt (vertical)

movement.

11
2. Technical background

12
Chapter 3
Theoretical background

The Theoretical background chapter introduces the reader to some important usability and
design concepts which is important for the coming chapters.

3.1 Interaction Design

Interaction design is about creating interfaces that that are completely elaborated. With
the understanding about how humans reason around navigating in different interfaces the
interface developer can partly invent new methods to do things and partly fix problems
early in the developing phase.

Interaction design (abbreviated IxD) is the knowledge about shaping digital products for
people’s use. IxD fills the design needs of digital products with dynamic behavior and
changing user interfaces.
Designing interactive products to support the way people communicate and interact in
their everyday and working lives [13].

Once we know something, we find it hard to imagine what it was like not to know it. Our
knowledge has "cursed" us [13].

3.2 User-centered Design

User-centered design (UCD) is a process where there is a strict and early focus on the end
user. The purpose is to evaluate often and continuously improve the design. A Iterative
design processes is a big part of the User-central design. An iterative design process was
chosen since it is suits user-centered design well. The usability expert Jakob Nielsen rec-
ommends at least two iterations which we adapted in our approach [14]. Nielsen has also

13
3. Theoretical background

measured that the usability can be improved by 38% per iteration. [15]

3.3 Cognitive graphical design

Cognitive graphical design is the knowledge about designing interfaces with concern of
how the brain works. By increasing the visibility, give good affordance, support mapping
and by giving relevant feedback a user interface can be improved.

There are some cognitive laws according to the cognitive graphical design. The laws are
called the law about proximity, similarity, closure, symmetry, common fate, continuity and
past experience. [16]

When creating graphical user interfaces the choose of color is very relevant. The brain
connects different colors to different feelings and therefore the choice of color is impor-
tant.

Blue often feels distant, peaceful and cold.

Green often perceived as distant and peaceful as well.
Yellow is on the other hand closer than more stimulating.
Red feels warm just like yellow but stronger.

The brain works faster when it recognises a picture and uses its passive memory instead
of processing letters to a word with the active memory which gives that icons should be
used. Icons shall in general be simple pictures and be based on nouns. [17]

3.4 Designing the user interface

“Anything that can go wrong, will go wrong.”
— Murphy’s law
When designing a user interface there are some well known researchers and experts who
have created some guidelines that is suitable to assume from. Shneiderman’s Eight Golden
Rules of Interface Design are a good base together with Jakob Nielsens ten usability guide-
lines for interaction design. Jakob Nielsens guidelines can be seen in appendix A and the
Eight Golden Rules of Interface Design are presented below.

1. Strive for consistency

2. Cater to universal usability
3. Offer informative feedback
4. Design dialogs to yield closure
5. Prevent errors
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short-term memory load [13]

14
 3.5 Prototypes

There are some important concepts that are relevant when designing the user interface.
These concepts are learnability, efficiency, attitude, flexibility and relevance. They are
important due to the fact that the concepts together contains all the important characteris-
tics from a smooth user interface.

Learnability The relation of performance to training and frequency of use,

i.e. the novice user’s learning time, and relearning on the part
of casual users. How easy it is to learn, and well the users can
remember their skills. [18]

Efficiency The results of interaction in terms of speed and errors. How

efficiently the users carry out their tasks and recover mistakes.
[18]

Attitude The acceptable levels of tiredness, discomfort, frustration and

personal effort. Subjective feelings towards the product. [18]

Flexibility Allowing adaptation to tasks and environments beyond those

first specified. [18]

Relevance How well the product serves the functions needed by the user.
[18]

3.4.1 Card sorting method

This method is used to explore the general structure of an application. The system user
often got a mental image that can be discovered with card sorting. By using this method
in the design process all the categorization will be thought through. Every function in a
system is put on a piece of paper like a memory card, after that everything is sorted based
on the logical groupings the participant prefers. [13]

3.5 Prototypes
A prototype is the manifestation of a design suggestions for you to interact with in any
way. There are two kind of prototypes, horizontal and vertical. The horizontal has many
functions and few details, the vertical in opposite has few functions but is more detailed.
[19]

3.5.1 LO-FI
A LO-FI prototype equals to a low fidelity prototype and is often drawn by hand. LO-FI
prototypes are cheap and quick to make. Another advantage is that it can be easier to give
constructive feedback on a prototype that does not look polished. Some disadvantages are
that usability tests becomes harder and the navigation is quite limited. [19]

15
3. Theoretical background

3.5.2 HI-FI
A HI-FI prototype equals to a high fidelity prototype and is often computer made. It takes
a lot of time to create a HI-FI prototype. Adobe Photoshop or Microsoft Power Point is two
common programs that can be used for HI-FI prototyping. HI-FI prototypes can prefer-
ably be used when usability test must be performed and therefore a click-able prototype is
needed. It can in most cases be more cost effective to first create HI-FI prototypes because
changes are easier done in non implemented prototypes. [19]

3.6 Usability evaluation methods

A program that is hard to use is a poorly designed program no matter how great the different
features may be. When performing usability tests the lack of usability can be discovered
and any problem with the usability requirements. Not only the fact that the product will sell
more if it is usable, the support costs will drastically be reduced as well. When discussing
usability evaluation there are some key words that must be explained. [20]

3.6.1 Use cases

A use case is a written description of how a user will perform a certain task on the software
while striving for a particular goal. A use case is from the user´s point of view, each use
case is a collection of steps to complete the task. A reason to use use cases is because they
add value in explaining and describing the systems behaviour. To create use cases can also
be a way to brainstorm what can go wrong in the system. [21]

3.6.2 Scenarios
Good scenarios are concise and answer the following key questions:
Who is the user ? Why does the user come to the site/view? What goals does he or she
have?

With Goal- or Task-Based Scenarios it is only stated what the user wants to do. Any
information on how the user would complete the scenario should not be included. These
scenarios are useful in helping to define your site architecture and content. This type is
suited for usability test scenarios. It gives them a reason and a goal for going to the site,
but it lets them show you how they would use the site to accomplish that goal.

Elaborated Scenarios give more user story details. These details give the Web team a
deeper understanding of the users and users’ characteristics that may help or hinder site
interaction. Knowing this information, the team is more likely to develop content, func-
tionality, and site behavior that users find comfortable and easy to work with.

When identifying scenarios for usability testing, you should limit your test to 10 to 12
tasks due to time constraints. Additionally, in a usability test, you can ask users for their
own scenarios.

16
 3.6 Usability evaluation methods

Debriefing
The main goal of having a written post questionnaire is to clarify and deepen your under-
standing of the test person. Every question in a written debriefing must be asked to the test
person in the same way but in an oral debriefing the questions can be adopted depending
on the test results. The questions shall be subjective, not performance based.

3.6.3 Usability inspection

A usability inspection is a way to find usability problems in a interface design. Usability
problems in the whole system and also system difficulty can be found. Inspections can
be performed early in the design due to the fact that the specification can be reviewed.
[22] One type of Usability Evaluation is Heuristic Evaluation which is the most informal
usability inspection method. By going through usability guidelines and apply them on the
design and later on evaluate.

3.6.4 Usability testing

Usability testing refers to evaluating a product or service by testing it with representa-
tive users. Typically, during a test, participants will try to complete typical tasks while
observers watch, listen and takes notes. The goal is to identify any usability problems,
collect qualitative and quantitative data and determine the participant’s satisfaction with
the product. The desired number of testers in a usability study differs depending on the
type of study, but according to Nielsen [23, 24] for most cases 5 test users is preferable.
[25]

Pilot test
A pilot test is a preliminary study performed to validate the study itself. The pilot test is
partly used to confirm that the questions are correctly formulated, it can also be a time and
cost test and there is a possibility to change the arrangement of the study post pilot test.
[26]

Before and after usability testing

When planing a usability test one of the first step is to create a test plan. The things that
should be included in a test plan is scope, purpose, equipment, session description, metrics
and roles. After the usability test the result is supposed to be reported and analysed. The
things that needs to be reported is error and success rates and tast time. Recommendations
and other comments must be presented as well as the note takers observations. [27][28]

Exploratory testing
This testing technique is cheap and perfect for discovering the interface. The design is not
yet decided and the result from the test will affect the future design work. This method
is used early in the design phase and the goal is to validate how the design works. This

17
3. Theoretical background

method can be applied on paper prototypes which makes it cheap to make radical changes.
The test leader interacts very much with the test person for example ask questions and start
discussions.

Assessment testing
This testing method is in contrast to Exploratory testing a way to test a ready design and
perhaps a completed prototype. This test method can be used either in the end of the design
phase or in a early implementation phase and the main purpose of this is the localise design
issues. [29]

18
Chapter 4
Video conference systems
A market overview of similar products

The market overview is done to take inspiration from similar products and this chapter
explains the method used and the pros and cons with the similar products.

In this chapter different video conference systems has been compared and evaluated. To
introduce the reader to the chapter the first section will cover the video conference camera
this master thesis is based on, followed by an introduction of the existing products on the
market which were chosen for evaluation. The purpose of the evaluation is not to identify
the market or to find and compare possible main competitors but to evaluate the usability
of similar products to identify good and poor design choices. The evaluation and the
conclusions drawn will serve as a helpful basis in the design process of the prototype. The
evaluation is based on four different use cases which are described in section 4.3 Methods
for evaluation. Video conference remote controls are also covered and evaluated in this
chapter.

4.1 Axis UtilityCam

Axis UtilityCam is the camera the thesis is based on. It is the first camera in the V-line
series that is not intended for surveillance use. Non-surveillance cameras still have wide
use areas, for example video conferencing and broadcasting. Axis UtilityCam will be
produced both for 720p and 1080p, there will be a HDMI and SDI outputs and support
PTZ with up to 30 times zoom. What makes UtilityCam unique in the non-surveillance
field is that the products only consists of a camera and that the user interaction is relied
on a separate product. In the case of video conferencing the user completely controls the
system with the connected TVs remote control. In many ways it is similar to surveillance
cameras but intended for other multi-purpose use.

19
4. Video conference systems
A market overview of similar products

4.2 Different products on the market

There are a lot of different video conference products on the market which means that all
categories and types will not be covered in this evaluation. To get the most out of the
analysis it is preferred to compare and evaluate video conference products that are similar
or have similar features to UtilityCam but also products with unique or different interface
solutions to get a broader view on the area.

The four most common types of videoconferencing systems are telepresence videocon-
ferencing systems, integrated videoconferencing rooms, set-top or appliance videoconfer-
encing systems and desktop videoconferencing systems. Telepresence systems give the
appearance of being present in an actual meeting even though the participants are geo-
graphically dispersed. They usually consist of higher quality video and audio, often with
several large displays. This is the most expensive type of the four. Integrated room video-
conferencing systems are most often used in conference rooms and board rooms and are de-
signed for larger groups. These systems are usually permanently mounted with customized
configurations and are normally equipped with multiple features which allow the room
to be used for other functions besides videoconferencing. Telepresence and integrated
videoconferencing systems will not be covered in the evaluation, due to their limitations
in availability and high cost. Set-tops and appliance videoconferencing systems are non-
stationary systems that are most useful in small conference rooms and for smaller groups
of participants. UtilityCam falls under this type of videoconferencing system. Desktop
systems are often completely software based and requires a computer and separate camera
to use. These products are often designed for non-business use. [30]

4.2.1 Set-tops and other dedicated systems

This category includes set-tops and other dedicated video conference system that were
chosen for evaluation. Set-tops are information appliance devices that displays the output
on a display, normally a television set. To get a closer similarity between the evaluated
systems and the Axis camera, only portable devices designed for smaller groups were
chosen. The systems were selected for their relevance, interesting features and interfaces
and their availability.

Logitech TV Cam HD
The Logitech TV Cam HD is a set-top video conferencing system that connects to a tele-
vision set with HDMI. The product has its own remote control and is integrated with
Skype. The product is described as a "living room Skype approved all-in-one TV cam"[31].
Though the system is not designed for a business environment there are some similarities
worth looking into, PTZ control is supported along with a 10-foot user interface.

Google Chromebox for meetings

Chromebox for meetings is a Chromebox with additional video conference equipment; a
HD camera, microphone/speaker and remote control. The Chromebox is a personal com-

20
 4.2 Different products on the market

puter running Google’s Chrome OS operating system. Chromebox for meetings connects
to a display using DisplayPort++ or HDMI with no support for CEC [32]. The interface
is similar to Google+ Hangout but designed for a larger screen. [33]

Lifesize Icon 600

The Lifesize Icon series is a series of video conferencing products that has more emphasis
on the ease of use than their other series. Michael Helmbrecht, Vice President of Product
Marketing on LifeSize Communications said that "The idea behind the icon series is to
simplify the video conferencing for individuals, one of the things that we’ve heard over
and over is [...] that many users are still intimidated by it [their products], it is still too
difficult to use versus competing technologies that people are more familiar with, like audio
conferencing or web conferencing" [34]. The Lifesize Icon 600 is HDMI enabled and
supports up to 1080p. It consist of a remote control, which is covered in section 4.4.2, a
camera along with other accessories.[35][36]

4.2.2 Software based systems

There are products on the market that only provides the graphical interface between two
end users, the hardware can differ which makes the system more dynamic.

Blue Jeans
Blue Jeans offers a cloud-based video conferencing service that can connects different
users with no requirements on the hardware which makes Blue Jeans to a very dynamic
video conference client. The main purpose of Blue Jeans is to bring together business
conferencing solutions. [37]

Hookflash
Hookflash is a application for smart phones which offers text messaging, telephoning and
video conferencing over a peer-to-peer network. The system also offer features like call
transfer. [38]

Palbee
Palbee is a Video Conference system that is used mainly for sharing knowledge. The
system offers limited talking hours and participants but unlimited amount of sessions. The
interface is flash based and evry kind of computer with an internet access can use it. [39]

ParkSlide
ParkSlide is a system for video conferencing that from the beginning where designed
around social networking. ParkSlide has since the beginning developed into an enter-
prise direction. ParkSlides vision is to change the common overly complicated systems
and software in video conferencing. [40]

21
4. Video conference systems
A market overview of similar products

4.3 Methods for evaluation

This section is important for Axis who want to launch a competitive product on the market
in the near future. The market analysis is also important for the master thesis project it
selves because what functionality is needed and what we can do can be inspired from
other similar products as well as what we should not do, mainly concerning the graphical
user interface. The focus of this section will mainly lie on the menu systems, ease of use
and installation and setup.

4.3.1 Use cases

To be able to compare and evaluate different video conference systems from the usability
point of view we started with creating four use cases which reflects the need of a typical
video conference user.

Use case 1: Installation and setup

The installation and setup of the system is often the first impression the user gets with the
product. As it is commonly known that first impressions could have a large impact on the
users overall experience with the product, it is important that the installation and setup has
a welcoming design that doesn’t scare the user away or make him or her hesitant to use the
product.

The purpose of this use case is partly to capture the first time the user is introduced to
the system and how well it is introduced to the user. It includes the necessary, and possi-
bly unnecessary, steps before the product can be used for video conference call from when
the system is turned on for the first time after all cables has been correctly connected.

Figure 4.1: Example of use case for installation and setup.

Use case 2: Initiate a call

One of the core functions of a video conference system, which should be an easily accessed
and intuitive process. This use case include adding the address of the receiver, both from

22
 4.3 Methods for evaluation

a preconfigured contact or manually adding the address. Most of the systems have the call
camera symbol in direct connection to person the user want to call which prevent errors
due to the fact that the user sees the picture at the same time as calling. One thing that
increased the user experience were in Hookflash when calling somebody a spinning circle
and a timer of how long the user have waited occurred on the screen. Many of the initiate
calls is by pressing a button with a camera symbol. This symbol is a bit miss leading, a
telephone might would be better as dialing symbol because the user will not mistake the
dialing button for watch the camera.

Figure 4.2: Example of use case for initiating a call.

Use case 3: Answer a call

Often completed with just a press of a button but includes more than that. The user should
get notified of incoming calls, from who it is and how to answer without other unnecessary
information which might confuse.

Figure 4.3: Example of use case for answering call.

Use case 4: PTZ Control

Controlling the Pan-Tilt-Zoom features during a video conference call. What the differ-
ences are there in the design when controlling the local cameras PTZ and controlling the
remote cameras PTZ. What symbols should be used to get the most usable remote control.
This is the only use case which takes place during a video conference call. It was chosen
as a use case because of the feature’s high importance and how it might distract the user
from the video conference call if poorly designed.

23
4. Video conference systems
A market overview of similar products

Figure 4.4: Example of use case for controlling PTZ functionality.

4.4 Evaluation
The analyse includes to interpret the information given from the use case evaluation of the
video conference systems described above. In this section we will discuss pros and cons
from different graphical interfaces and the effects it will cause for the user as well. The
analytic evaluation will be grounded of what expectations is held on a video conference
system interface which is a subjective form of evaluation and the functionality performance
which is the objective form of a evaluation. Except for the mentioned evaluation methods,
a combination of heuristic evaluation and comparison testing is performed as well. The
video conference cameras compared in this section are described above 4.2 as well as the
testing methods and techniques 3.6.

4.4.1 Menu system

Lifesize Icon are video conference products which are based on one principle, simplicity.
The design revolves around presenting the same user experience which we commonly get
from todays smartphones[35]. This is seen in the menu system where the icons swipes back
and forward when the user navigates through the menus. As expected from the name, the
icons play a very important part of their design, it is what their design stand or fall by.
Google’s Chromebox for meetings goes for a more minimalist look, a winning concept
which they have used since the start of their search engine. In contrast to Lifesize Icons
interface this makes the other participants visible at all times.

Installation and setup

The criteria on the interface in this use case is the simpleness. This step is only done once
and therefore it should be quite straight forward. In some products the installation were
simple because all the wireless cameras connected where shown in a straight forward list
and it was very easy to find and install the camera intended. In other systems the camera
could only be found when entering the correct IP number which in many cases where hard
to find and not very adopted for persons without it knowledge. Other problem in other
systems where for instance that it was possible to video call persons without first installing
the camera which were not that logical in contrast to, for example Parkslide which focused

24
 4.4 Evaluation

a lot on the design and had a intuitive tab for installing the camera, the interface were
overall very clean and easy to find in. Parkslides slogan is "Get started in seconds, talk
for hours". Chromebox for meetings had a fast and straight forward setup process, the
user did not get overwhelmed with unnecessary configuration steps since the setup only
consisted of picture, sound and microphone checking. Easy as it might seem there are
some prerequisites, Chromebox has to be setup and running and the user needs a Google
account. Bluejeans is a video conference client that is compatible with a bunch of different
cameras which makes it easier for a company to have meeting without the same type of
hardware. The functionality is also implemented in other VoIP system such as Skype,
Skype is usually not used for video conference calls, although for example Logitech have
a Skype integration for their video conference camera.

Initiate a call
Most of the product that where evaluated by us had tried to make this step intuitive and
logical. A problem with Hookflash were that to initiate a call the user had to manually
type in the number to be able to make a call. Parkslide has a smooth drag and drop system
to add people in the conversation. This is showed for the user with a text and a box where
you can drop the pictures of the one you want to talk with. For example Blue Jeans also
uses the color mapping with red to end call which the human mind connects with stop.

Answer a call
Hookflash has a very simple and good way to answer a call, the buttons are color mapped
to make it more logical for the user. Accept is green, ignore is orange and decline is red.

PTZ Control
In the different PTZ remote controls there are some different approaches of how to control
the pan tilt and zoom. The pan and tilt is often remote controlled with arrows, see figure
4.5, it is logical that the panorama view is navigated by left and right arrow and the tilt
with up and down arrows. The zoom in some remote controls are logical with mapping to
magnifying glass with a plus or a minus. Both 4.5 and 4.6 with a W and T which not are
that intuitive. The W and T refers to a word that does not work cross languages, a symbol
is better. In some cases there are two different speeds for zoom which could be useful in
some cases but in general there could be too many buttons as in 4.5. Depending on what
the remote control should be used for sometimes less is more.

4.4.2 Remote controls

Most video conference systems are designed to be controlled with a remote control, the
exception being software products that are made to be used on a desktop computer and
are thereby controlled using a standard mouse and keyboard. Many of the products which
rely on a remote control solution design their own remote control which is included with
the camera. For some systems the remote control is not mandatory but can be bought

25
4. Video conference systems
A market overview of similar products

Figure 4.5: Agent remote control for controlling PTZ functional-

ity.

Figure 4.6: Sony remote control for controlling PTZ functionality.

26
 4.4 Evaluation

separately. The design and complexity of these remote controls can vary a lot depending
on which aspects the manufacturers have decided to focus on.

Figure 4.7: From the left, remote control for the Icon series and
remote control for the 220 series.

Lifesize chose two very different approaches in their remote control designs for their se-
ries, 220 and Icon, see figure 4.7. For their older 220 series the remote control is very
similar to a standard TV remote control with many buttons and a higher learning curve.
For their newer Icon series they took a complete u-turn and made their remote control as
simple as possible with only the most essential buttons: a mute button, navigation buttons
and a select button. That is a total of 6 buttons compared to 33 buttons in the 220 series.
Lifesize says that with their new remote control for the Icon series they "want the users
to never have to look down at the remote"[41], this way the user can focus on the display
instead of trying to figure out which buttons do what. For the user to be able to control
the system with only 6 buttons, down from 33, they also had to revamp the navigation and
menu system, see Menu system in section 4.4.

Google’s remote control for Chromebox for meetings has also tried to adopt the same
simplicity as Lifesize Icon remote control, at least partly. The front look very similar to
the Icon remote control with the only additions of an end call button and a menu button,
see figure 4.8.

27
4. Video conference systems
A market overview of similar products

Figure 4.8: Front side of remote control for Chromebox for meet-
ings.

Figure 4.9: Rare side of remote control for Chromebox for meet-
ings.

28
Chapter 5
First iteration :
Requirements & concepts

In this chapter the early development of the prototype is described. The chapter is divided
into three main parts: Method, Results and Conclusions. Method covers the work process
and the methods used, Results describes the results from the tests and Conclusions consist
of the conclusions drawn from the results.

The goals for the first iteration with a horizontal paper prototype were the following. De-
cide what functions that would be included and decide what steps that should be included.
There was no focus on in-dept details in this iteration, just proof of concepts. The things
that were prioritized in this step were the terminology, the conceptual design and the cat-
egorisation and grouping of features. The goals were fulfilled by creating prototypes that
are based on the conclusion from the evaluation of similar products in the previous chapter.

5.1 Method

Figure 5.1: Iteration 1 work process

29
5. First iteration :
Requirements & concepts

Figure 5.1 illustrates the work process for the first iteration. Initially requirement priori-
tisation and grouping was performed using the card sorting method. Based on the results
from the card sorting and the conclusions from the previous chapter a paper prototype was
made which was tested and evaluated. The conclusions from the evaluations was later
used to improve the prototype in the second iteration.

5.1.1 Design
Prioritizing
Every function from the current function analysis where included in a prioritization session
and where given number with the the numeral assignment technique. The 13 functions
where categorized from 1 to 13 where 1 equals the function that is most prioritized.

Grouping with Card sorting method

The categorization between the different sub views is decided with the card sorting method.
The technique is described in 3.4.1. The result from the card sorting session turned out
in the four views "installation, settings, before call and during call. This can be viewed in
figure 5.2. The functions from the functional analysis where divided into logical groups
which represent what view in the menu system the function will be in.

Paper prototyping
The prototypes in the first iteration were hand drawn on paper so usability testing and us-
ability inspection could be performed. The prototypes where inspired by conclusions from
the evaluation of similar product in 4.4.

5.1.2 Exploratory testing

This type of testing is described in section 3.6.4. The test consisted of note taker, test
person and a test leader. The usability test was a minor formative usability test with focus
on qualitative data. The purpose of this test was to test and evaluate how the preliminary
conceptual design works, also to test if the terminology was fitting. The test could also be
seen as a pilot test for future testing and as training for the test leader and the note taker.

The test was performed on three master students that has specialised in usability and de-
sign at LTH. The reason we chose these test persons, which are not in the target group,
is because we wanted to get a lot of feedback regarding the usability. The students did a
combination of both a form of expert judgment due to their academic background and a
form of personas due to the fact that they getting a scenario they have to adopt to.

Six different scenarios were created which all contained a task for the test person to per-
form. The test leader tried to introduce a discussion for every scenario while the note taker
described the scenarios and recorded what the test person expressed. The test started with

30
 5.2 Result

a short description of the master thesis and picture 4.4 where shown for the test person.
For more on the presentation and scenarios, see appendix B.

5.1.3 Heuristic evaluation

Usability inspection of iteration 1 where done with Heuristic evaluation that was based on
Jakob Nielsens 10 Usability Heuristics in appendix A.

5.2 Result
5.2.1 Design
The results from the prioritizing and grouping of functions can be seen in figure 5.2.

Figure 5.2: Grouped and prioritized functions. Functions closer

to the top is have a higher priority. The color mapping corresponds
to the different views of the menus.

5.2.2 Exploratory testing

In scenario 1 the test participant were suppose to type in the name of the conference room
they were currently sitting in as a part of the setup of the video conference system. Two
of the test participants failed this test by typing their own name. During the retrospective
probing (RP) they both said that the reason why they failed was because they were eager
to get through the setup process as soon as possible and because of this they only read the
word "name" and assumed they were suppose to type their own name.

31
5. First iteration :
Requirements & concepts

Figure 5.3: The view in the first iteration prototype for controlling
the PTZ values of the local camera.

All three test participants had issues with the menu navigation. They expressed uncer-
tainty for what the navigation buttons did in different situations. Most notable was during
scenario 2 where the test participants wanted to pan, tilt and zoom the camera, and sce-
nario 3 and 4 where the test participant wanted to change the settings. During scenario 2,
when the test participants had reached the view shown in figure 5.3, two of the test par-
ticipants expressed that they were uncertain if pressing the arrow buttons on the remote
control would pan and tilt the camera or would continue to navigate through the menu.

Similar comments were made for the settings view, figure 5.4, where the test participants
had issues determining if their action would affect the left or right panel. It was also stated
that not enough feedback was given regarding if tabs or menus were selected or not, though
one test participant thought that it was because the test was made on a paper prototype. The
same test participant suggested an alternative way for changing settings in a list such as
language by using the numpad or the channel up or down buttons. During the RP, one test
participant said that there were some inconsistency for menus layout and how they worked.
One test participant did not understand the term picture-in-picture in the advanced tab un-
der My Settings.

It was also made clear that in the right panel of figure 5.3 it was found intuitive and easy to
understand how to pan, tilt and zoom the camera, none of the participants failed this task
on their first try. During the test one participant was asked about the zoom icon in the upper
right corner and if it would’ve been better to use perspective arrows. The test participant
thought it was much better as it was in the test because that icon was recognized from the
remote control. With different icons for the button on the remote control and for the screen
it would be more difficult to map these together. The purpose of being able to control the
remote camera and not the local camera during a video conference call perplexed a test
participant, as a user he wanted to be in control of his own product, not anyone else. It
was also expressed that it deprives the purpose of configuring the local cameras pan, tilt
and zoom if the user on the other end of the video conference call can change it freely.
Overall the test participant thought that PTZ control was a "luxurious feature" which isn’t

32
 5.2 Result

Figure 5.4: The view in the first iteration prototype for changing
system language.

necessary.

Some spontaneous thoughts of changes from the test participants:

• Strive for more consistency in the navigation.

• Use the numbers as presets in the contact list.

• It is enough to only control your own cameras PTZ according to one test participant.

5.2.3 Heuristic evaluation

The main menu gives good information of where the user is because the whole view is vis-
ible and there are clear indications in the view which helps the navigation. The introducing
installation should give a hint of how many steps are left of the installation, for example
"2/3" in the right corner. The "My Settings" view got some issues about the navigation,
due to the fact that there are nested tabs inside of the menu the interface must be very clear
of the navigation status.

According to Jakob Nielsens second rule, see appendix A, the system should be designed
for its target group with for example terminology which the prototype is. The headlines in
the main menu could have more professional headlines instead of MyContacts, MyCamera
and MySetting but on the other hand the names indicates precisely what the view is aimed
for which is good.

The third rule is fulfilled because the user can always navigate to another state in the main
menu. During a call the user can press the menu button to end the call. If it is to hard to
end call, a mistake call could be embarrassing but on the other hand if it is very easy to
end call the user might end calls by mistake.

33
5. First iteration :
Requirements & concepts

The navigation should always be straight forward and in the MyCamera and MySettings
views there is need for clearer navigation possibles and indications of where the user are.
The interface is indeed flexible for both new and advanced users, by default there is a lot
of help views and the views are design for not that technical users. Even though there is
a help view during the minimalistic call view, the order of the functions must be thought
through.

5.3 Conclusions
Terminology
Picture in picture is a technical term which is hard to understand, a better way could be to
use self explanatory images or icons. My Contacts, My Camera and My Settings should
be changed into something more professional, it can also give the user the false impres-
sion that the user interface is personal, even tough it is room based. In the Language tab,
United States should be changed to English. It is not clear what the Security tab means,
Privacy could be a better term. The zoom indicator in the PTZ view, figure 5.3, is easy to
understand and maps to the remote control button well. A reason for why two of the test
participants failed scenario 1 could be the lack of background information. Inexperienced
video conference users often associate video conference systems with Skype, which is a
personalized product unlike the prototype which were tested. During the setup it should
be made more clear that the user is asked to insert the name of the conference room.

Conceptual model and navigation

Drop down menus is mostly a computer oriented design and is not optimal for interfaces
designed for television sets, it should be made clear how to open the drop down menu if
they are kept in the design. The setup should have a clear indication on where the user
is in the setup process and how many step there are. The general conceptual model and
navigation routes needs a lot of work and might have to be completely remade. The testing
showed that the current design for the main menu is a poor design. With two menus shown
at the same time, right and left panel, it is difficult to navigate. The design of the menus
is most confusing when the user is presented with multiple horizontal and vertical menus,
e.g. see figure 5.4, this should be avoided.

Features
“The hardest part of design, especially consumer electronics, is keeping
features out.” — Donald A Norman

Since a goal of this thesis is to develop an initial prototype which focus on the ease of use,
the scope for included features should be reduced in upcoming iterations. This is espe-
cially relevant for features which can not be fully implemented due to technical limitations
and would only serve as a placeholder and not a proof of concept of how such feature could

34
 5.3 Conclusions

or should work. Since the feature can not be fully implemented it would not be correctly
tested in upcoming iterations which is planned to be done on the implemented prototype.
Picture in picture is one such feature that also was found to be a technical term that might
be difficult to understand. The feature picture in picture does not necessarily have to be
removed in upcoming iterations but the option of enabling and disabling picture in picture
should. Advanced settings and features which would primarily be used by advanced users
will thereby be reduced in upcoming iterations.

35
5. First iteration :
Requirements & concepts

36
Chapter 6
Second iteration :
Design & prototyping

This chapter contains information about the method used in iteration 2 and the results
which is half way into the design. The results are presented in form of digital prototypes.
The chapter is formed in the same way as chapter 1.

The goals for the second iteration included creating a HIFI-prototype. In contrast to it-
eration one where it was decided what functions should be in what view, this iteration
focused instead on how to interact with the different functions in a natural and useful way.
The second iteration is more detailed than the previous one. what was most important in
this step, was to get feedback about how well the user understand the hidden functions and
also feedback on the use of color et cetera.

6.1 Method

Figure 6.1: Iteration 2 method overview

The goals and test method from the second iteration can be found in appendix C. The iter-
ation started with a complete redesign from iteration 1 that were based on the conclusions
from iteration 1. Digital prototypes were created and usability tests was made. Each test
included a debriefing, the results were used to draw conclusions.

37
6. Second iteration :
Design & prototyping

6.1.1 Design
This was still quite early in the design phase and it was therefore decided to rethink the
design from iteration 1 to be find a better solution. The main menu was completely re-
designed and the main goal was that less is more. Even though the old design in 5.3 kept
the user aware of where they were and how they could navigate to other view, the new
design seen in 6.2 is a better design for TV interfaces.

6.1.2 Assessment testing

The usability test was performed on seven test persons that work on Axis Communica-
tion AB. They were chosen because they fit the target group, since the prototype is meant
for business use. The complete test plan can be found in appendix C. One goal with the
usability test was to get suggestions for improvement. The whole system is tested in a
real video conference environment. The sessions were all together about 45 minutes long
an contained six different scenarios with a debriefing afterwards. The data collected is
both subjective and objective information we received from the tests. The test leader in-
teracted if needed with the test person and the note taker collected all valuable information.

Techniques used for the assessment testing were concurrent think aloud and retrospective
probing which are technique where the test person talk loud what they think and how they
resonate while retrospective probing means that there is a discussion after the test session.
[42] [43]. The data collected during the test were both quantitative and qualitative data.

6.2 Result
6.2.1 Design

Figure 6.2: Iteration 2 main menu

38
 6.2 Result

Figure 6.3: Iteration 2 language view

Figure 6.4: Iteration 2 remote camera view

6.2.2 Assessment testing

Quantitative data

Table 6.1: The 1 - 5 scale questionnaire statements used in the

assessment test.

Q1 I feel confident that I used this system correctly

Q2 I think that I would need to ask questions to know how to use this system
Q3 I think that most people would figure out how to use this system very quickly
Q4 Figuring out how to navigate in this system was difficult
Q5 I think that this system was easy to use
Q6 I think the amount of information where adequate
Q7 I think the use of color where appropriate

The data presented in table 6.2 shows the results from seven questions, seen in table 6.1,
from the seven test persons and two pilot testers. The debriefing survey can be found in
appendix D. The table shows that question three and question seven got the lowest points
for the questions where high points were preferred, which are all except question two and
four. With the low mean value of Q7 of 3.78, it should be noted that the choice of colors
not optimal and can be improved to next iteration. Figure 6.6 shows a bar diagram for
these values.

39
6. Second iteration :
Design & prototyping

Table 6.2: Debriefing results for question (Q) one to seven with
test person (TP) one to seven and pilot tester (P) one and two.
1 means strongly disagree which scales up to 5 which means
strongly agree.

Q1 Q2 Q3 Q4 Q5 Q6 Q7
TP1 5 3 3 3 4 3 4
TP2 2 4 2 4 3 4 5
TP3 5 2 4 1 5 2 2
TP4 5 1 4 2 4 4 4
TP5 5 1 4 2 4 4 1
TP6 4 4 5 2 5 5 5
TP7 4 2 4 1 5 5 4
P1 5 2 4 2 5 4 4
P2 5 2 4 2 5 4 5
Mean 4.44 2.33 3.78 2.11 4.44 3.89 3.78

Navigation

All users understood right away that they had to use the arrow buttons to navigate through
the menus and used them correctly. Several users commented during the testing that the
navigation through the menus felt fast and smooth. The first time the users came across
that they had to go back a step in the menus was in scenario 1 where they wanted to go back
from the Camera menu to the Main menu. None of the users pressed the correct button
(Exit) on the remote control on their first try. Three users pressed the correct button on
their second try, two on their third, two on their fourth and one on the fifth, see figure 6.5.
In the Camera menu a few test persons expressed that they felt that it would be suitable
with more hints for how to go back to the Main menu. One test person said that the Select
button should send back to Main menu from the Camera menu because the test person felt
that Return or Exit would exit the menu without saving the cameras PTZ configurations
that were made.
After scenario 1, once the users had found that Exit was the correct button, the users
continued the usability test by going back a step in the menus in a correct way. During
the retrospective probing the users were asked why they think they failed to go back to the
main menu from the camera menu in scenario 1.

Information

The information that was not existing in the prototypes was how to return. There were also
missing information about who you are connected to during call. Other things that were
missing were the Axis look n’ feel in the design. When muting the call it was not clear if
it was the local or the remote microphone (the microphone on the other side of the call)
that was muted.

40
 6.2 Result

First Second Third Fourth Fifth

Select → Exit
Return → Exit
Return → Exit
Select → Return → Exit
Return → Select → Exit
Return → Select → Menu → Exit
Return → Select → Menu → Exit
Menu → Return → Tools → Select → Exit

Figure 6.5: The buttons pressed by the users in their first en-
counter of having to go back a step in the menus. Each row repre-
sents the series of buttons pressed by a user in chronological order
from left to right.

Feedback
Many test persons found the prototype to be lacking feedback when changing language, the
only thing that changed were the language symbol in the top left corner which switched
to the selected language. Two test persons said that they were expected to be sent back
to the settings menu when they changed language which the prototype did not do. More
feedback where desired regarding the mute function during a video conference session,
especially when the menu was not present.

Terminology
Generally the users did not find the terminology confusing and felt that the sentences was
of appropriate length. One user found it unclear if the mute function in a video conference
call muted their own microphone or the microphone on the other side of the conference
call.

6.2.3 Results from open discussion

In the contacts menu some test persons wanted to be able to go directly from A to Z as
well as directly from Beige to Yellow which was not possible in the current design. Beige
and Yellow are conference rooms from the usability test session. It was new for some test
persons that you can configure the PTZ for both local and remote camera. This was said
to be unnecessary and some wanted to have the opportunity to turn this feature of.

Colors should be more, exciting, modern and warm. A problem that occurred was that
the help menu was not present when it was felt that it was needed. It was never used for
during the tests. One test person commented on the Camera view that it is not clear if the
changes are saved. The mute/unmute icon and text were contradictory.

41
6. Second iteration :
Design & prototyping

6.3 Conclusions

5
4.44 4.44

4 3.78 3.89 3.78

3
2.33
2.11
2

1
Q1 Q2 Q3 Q4 Q5 Q6 Q7

Figure 6.6: Mean value of the results from the 1 (strongly dis-
agree) to 5 (strongly agree) scale questionnaire in appendix D,
these are the same results as in table 6.2. Higher value is better
except for Q2 and Q4 where lower is better.

Navigation
One recurring error that was found in the assessment testing regarded the users ability to
go back a step in the menus. As seen in figure 6.5 all users tried the Return button on
their first or second try except one user which pressed the correct button on the second
try. Based on the result it is clear that the correct button should be the Return button. The
reason why the Return button has not been used previously is due to technical limitations.
Return does not map to a CEC UI Command Code like Exit does but is a vendor specific
implementation which falls outside of the scope for this thesis.

Information
The results showed that all users had trouble knowing how to return, see figure 6.5. There
were also missing information about who you are connected to during a call. Other things
that can be improved was to give the prototype a more Axis look n’ feel, by fonts and colors
that are typically used in Axis products.

Terminology
The terminology in the prototype is good and does not need to be changed for the next
iteration.

42
 6.3 Conclusions

6.3.1 Error sources

Some things could affect the result in a negative way, this is for example that two of the
debriefing questions where designed in a way that low number is preferred while in the
other five questions a high score is preferred. Another error source is that the test persons
all had different experience of similar systems, some had experience with HDMI-CEC
and XBMC before which were helpful because the navigation is similar. XBMC is a open
source media and entertainment center.

43
6. Second iteration :
Design & prototyping

44
Chapter 7
Third iteration :
Graphic design & high level prototypes

This chapter contains information about the method used in iteration 3 and the final design
results. The results are presented in form of digital prototypes. The chapter is formed in
the same way as chapter 1 and 2.

The third iteration is the last iteration in the design process for this master thesis. The goal
for this iteration was to create a HI-FI prototype with Axis look and feel. All the results
and conclusions from the usability tests in iteration 2 were considered.

7.1 Method

Figure 7.1: Iteration 3 method overview.

7.1.1 Design
Important for this iteration was to not change anything that we did not have any base to
change because there is a chance to introduce new usability problems. The changes for
this iteration was based on previous usability test results and conclusions from iteration 1
and 2.

45
7. Third iteration :
Graphic design & high level prototypes

7.2 Result
The main view from iteration 3 seen in figure 7.2 is the interface with Axis look n’ feel,
only three menu selections and a gray text that explains the marked menu choice. The
help menu has been removed. The intuitive icon that shows that the sound is muted can
be seen in figure 7.4, which is a view that is shown during call, gives its information
without being in the way for the user. The indicator in right top side of the view is the
same as in iteration 2 but the colors has been changed. The left indication about how the
user navigates back to the main menu is complimented by a symbol which is the same as
the button that is supposed to be pressed on the remote control. This symbol may differ
depending on TV model but information about the TV brand can be fetched with CEC
and the displayed symbol can be adjusted to fit the remote control. The main difference in
the Settings language view figure 7.5 is that the user is moved to the previous view when
selecting language, this is to give the user feedback. An interaction design advantage we
added to the contact list view figure 7.6 were that there are two items showing down or up
except when the scroll reaches the end of the list. The intuitive scheme in the top of the
view with all the letters shows in what letters there is conference rooms and what letter is
in focus right now. This scheme is a short cut for faster navigating when there is a lot of
conference room.

Figure 7.2: Iteration 3 main view

46
 7.2 Result

Figure 7.3: Iteration 3 during call

Figure 7.4: Iteration 3 during call with mute and zoom

Figure 7.5: Iteration 3 language view

47
7. Third iteration :
Graphic design & high level prototypes

Figure 7.6: Iteration 3 contact view

48
Chapter 8
Implementation

The implementation chapter describes the setup and implementation of the final prototype.
This chapter also covers technical restrictions.

8.1 Overview of the setup

The communication between the different artifacts for one end of the system is shown in
figure 8.1. The same configuration is taking place in another remote conference room and
the external communication is through an ethernet port on the camera over the external
network. The figure illustrates which data is sent from the different artifacts in the system.
The user navigates in the menu system with a remote control and the signals are passed
through HDMI to the camera. This was the initial setup, the end setup is illustrated in fig-
ure 8.2. The differences between these are due to technical limitations which were found
through the course of the thesis. In the initial setup the video stream is displayed on the
TV but in the end setup the video stream is displayed on a computer monitor. The switch
of monitors was made because the communication from ARTPEC 5 to FPGA was not yet
fully implemented when this thesis was conducted, see 8.4 Technical Limitations. The
computations are still being made on the camera, the computer only displays the image
from a GStreamer pipeline sent from the camera, for this we used the gst-launch tool [44].
A Samsung TV was used for the setup.

The basic architecture of the program is made up by different states and in them different
views. The program listens to CEC messages and when received changes the states and
views accordingly which alters the GUI. For PTZ control Axis’ own open API, VAPIX,
was used.

49
8. Implementation

Figure 8.1: Overview of the initial setup for one end of the system.

Figure 8.2: Overview of the end setup for one end of the system.

50
 8.2 CEC

8.2 CEC
The Remote Control Pass Through feature was used when communicating between the
TV and the camera. The reason for not utilizing the Vendor Specific Commands feature
was that a solution which would work on any HDMI-CEC TV was desired. Initially a LG
TV was used in the setup but was later switched to a Samsung TV since the SimpLink
(LG CEC trade name) seemed to be using Vendor Specific Commands more for button
presses while Anynet+ (Samsung CEC trade name) used Remote Control Pass Through.
Some Samsung remote control buttons were still not supported in Remote Control Pass
Through. The Exit button is one example and was therefor not used which was found to
be the source of the navigation problem in the second iteration, shown in figure 6.5.

8.3 Overlays
The process of generating an image in the Axis camera basically consists of four steps,
seen in figure 8.3. These steps are made in the ARTPEC 5 module, (2) in figure 8.4. In
the first two steps the image is captured and processed to enhance quality. In the third step
the overlays are added to the video stream over the captured image and in the last step the
data is encoded. Since the scaling is made before the encoding, the overlay images can not
be in a compressed file format, instead 24 bit BMP was used.

Figure 8.3: The four steps of generating an image. Overlays are

added in the third step, Scale, before the image is encoded.

Along with the captured image, the video stream can be seen as three layers. The other two
layers are the overlay image and the overlay alpha. The overlay alpha determines which
part of the overlay image that will be transparent and show the captured image underneath.
The alpha is determined by a unique color in the overlay image, in figure 7.3 the white color
is the alpha. Not all overlays overlays had transparency, e.g. Main menu, figure 7.2, where
the overlay image completely covered the image captured by the camera.

8.4 Technical Limitations

The chip, ARTPEC 5, in the camera has limited graphical processing power. There is no
GPU, Graphical Processing Unit, in the chip which put constraints on animations and dy-
namic overlays which could increase the user experience and give a more modern look to
the interface. Due to the graphical processing restriction, the overlays were pre-generated.
Because of this, the prototype only supports one resolution, 1920 × 1080. The prototype is
not technically limited to only one resolution but the overlays would lose quality if scaled

51
8. Implementation

to other resolutions than the pre-generated overlay image, especially for text which could
become unreadable. An alternative solution for this could of course be to have multiple
overlays for multiple resolutions for each view, but this would require a lot more overlays.

Figure 8.4: The different parts in the camera (oval) and how they
are connected.

As previously mentioned, the communication from ARTPEC 5 to FPGA is not yet fully
implemented at the time of this thesis. It is still possible to send the captured image from
the local camera to the TV via HDMI, (4 → 5) in figure 8.4, but not with the added overlays
since that part is done in ARPTEC 5. By sending the video stream to a separate computer
through the ethernet port (1), this solution circumvents the issue. As the Axis camera was
still in development during this thesis, technical limitations like these should be expected
and should not be considered a bug.

52
Chapter 9
Conclusion and discussion

This chapter presents different aspects of the project, future perspective, alternative solu-
tions and general discussion.

We have in this project created a video conference prototype with an intuitive interface
combined with a standard TV remote control for a video conferencing system using Axis
hardware and software and standard AV equipment. We also did a market overview where
we compared similar products which where included in the first goal. The market overview
could be done in a more effective way but due to the fact that some equipment where hard
to test without buying we read about some systems instead of testing them ourself. The
second goal about creating a bidirectional system where not fulfilled completely. Due to
technical limitations some functionalists where simulated with a computer in the middle
but this problems where outside of our project and will eventually be fixed. Also the instal-
lation of the camera where excluded and put in a fictive cloud solution. After the usability
test we can be quite positive that a huge majority of the target group will feel confident
using the video conference system.

The CEC solution in this thesis has some major benefits, the two biggest being not having
to provide additional equipment, like a separate remote control, and the use of a standard-
ized protocol that, in theory, should make the system interoperable. We found however
some drawbacks to this approach regarding both design and implementation. The CEC
feature does not provide for as much interoperability as we first hoped for. With different
CEC trade names using different vendor specific commands, vendor specific implementa-
tion might be required by Axis as well. How many TV brands must a CEC based video
conference product support to be sufficient? Do all vendors use their own unique com-
mands? The different implementations of CEC from different vendors was only briefly
looked into during this thesis, a more thorough study on this will be required to be able to
answer these questions certainly. Is it possible to design a user interface good enough to
work well with high usability, regardless of the layout of the remote control? With no real

53
9. Conclusion and discussion

influence on the design of the remote control, this is basically the task. Most TV remote
controls are similar and we can of course expect that the companies strive to design remote
controls with high usability. But even when this succeeds, it is still a TV remote control,
not a video conference remote control. Can we expect a product with high usability for
its intended field to still be intuitive to use outside of the field? During our testing we did
not find any correlation between a better result for experienced Samsung users who has
the same type of remote control at home compared to the other testers. With CEC it is
possible to find the brand of the TV and tailor the user interface for that company’s remote
control. Could a dynamic interface which adapts to the TV and its remote control be the
solution? That is possible, in our design we believe we achieved better results by restrict-
ing and adapting to a specific TV remote control as many testers justified their choices of
button presses by the icon mapping between the remote control and the GUI. Note that the
user isn’t actually restricted to the standard TV remote control though, a generic remote
control could be used. Even though higher usability might be achieved for the individual
case, a user of multiple products connected to different TV brands, might find it confusing
if the user interface differs since it is same video conference product.

The amount of testing we did was sufficient according to usability experts, such as J.
Nielsen. We even tested on more test users than suggested (5) [24]. When determining the
suggested number of testers, Nielsen not only looked to find as many usability issues as
possible but also took the test budget regard. The test budget in our case can be seen as the
time we spent on the testing, the preparation and the evaluation of the test results. We felt
that we gained a lot from our elaborated tests with many test participants, but according to
Nielsen it is more favorable to test on fewer users if it leads to more tests. A rule of thumb
here might be to strive for many tests and on a few testers rather than a few tests on many
testers. For our testing we felt that we wanted to be well prepared, and if possible test
on more users to get as many different views and thoughts on our prototype as we could,
which we think we did successfully. In hindsight, testing more scenarios or adding other
types of tests instead of more testers when we had spare time could have given us a better
result. That said, we are still satisfied with our result.

9.1 Technical restrictions

The design where constraint by the camera hardware, with no GPU and a limited mem-
ory the design had to be quite simple. No visual effects could be used so the views are
not dynamical, no input text or similar can be used, in our prototype all views are unique
pictures. Sound is a central thing during video conference, both for the sake of video but
also for the usability part. This were excluded from this project due to time limit.

9.2 Alternative solutions

The system is implemented with a TV remote control which has its pros and cons. In
some peoples opinion the TV remote control feels limited and old meanwhile the pros is

54
 9.3 Suggestions for future development

that you do not need one more new unique remote control. There is a possibility to both
skip using the TV remote control and also not have a own unique camera remote control
by having a application in your smart phone where you can sign in and control the camera.
It is also a opportunity to both have a smart phone application and the TV remote control.
The TV remote control limits the video conference user to only use an TV screen while in
fact there often is need for a bigger screen than that.

Usually meetings are setup on/added to the participants digital calendars. There are al-
ready standards for exporting and importing such appointments, this can be an possible
extension of the project. When a user comes to a conference room it could already know
which other conference room the user is going to call and provide the user the option to
call that conference room with one button press.

There is a opportunity to create a personal interface which requires sign in. The guidance
that is should be very easy to get started made us go for a solution without a personal
touch but there is of course pros with personal views. First of all there will be possibility
to configure the settings and save it depending on the users own requirements.

The contact list is design so you first have to choose a country then city and last a confer-
ence room all in alphabetic order. One can imagine a solution where the contact list gets
less steps and the contacts instead are grouped by geographical orientation or by starred
contacts.

9.3 Suggestions for future development

The future from this project is quite unknown. Many parts of this project is simulated for
the demonstration. To make a product out of this is a large step. In this thesis we have
showed that it is possible but there is still a lot of improvements that must be done. As
discussed above, the artpec5 chip is quite limited for graphical things and the graphical
part must indeed be improved before the video conference camera is market ready.

55
9. Conclusion and discussion

56
References

[1] Daemon computing. http:// www.en.wikipedia.org/ wiki/ Daemon_(computing).

[Online; accessed 20-Aug-2014].

[2] Vapix. http:// www.axis.com/ techsup/ cam_servers/ dev/ cam_http_api_index.php.

[Online; accessed 11-Mar-2015].

[3] Axis communications. about axis. Available at http:// www.axis.com/ corporate/ .

[Online; accessed 20-Aug-2014].

[4] LLC HDMI Licensing. Faq. Available at

http:// www.hdmi.org/ learningcenter/ faq.aspx. [Online; accessed 05-Aug-2014].

[5] LLC HDMI Licensing. Hdmi adopters.

http:// www.hdmi.org/ learningcenter/ adopters_founders.aspx. [Online; accessed
06-Aug-2014].

[6] LLC HDMI Licensing. About us. Available at

http:// www.hdmi.org/ about/ index.aspx. [Online; accessed 04-Aug-2014].

[7] LLC HDMI Licensing. High-definition multimedia interface specification version

1.4b, cec section 2.2, October 2011.

[8] LLC HDMI Licensing. High-definition multimedia interface specification version

1.4b, cec section 6, October 2011.

[9] LLC HDMI Licensing. High-definition multimedia interface specification version

1.4b, cec section 13.3, October 2011.

[10] LLC HDMI Licensing. High-definition multimedia interface specification version

1.4b, cec section 13.9, October 2011.

[11] libcec. http:// libcec.pulse-eight.com. [Online; accessed 17-Jan-2015].

57
REFERENCES

[12] Raspberry Pi Foundation. What is a raspberry pi?

http:// www.raspberrypi.org/ help/ what-is-a-raspberry-pi/ . [Online; accessed
15-Mar-2015].

[13] Ben Shneiderman. Designing the user interface-strategies for effective

human-computer interaction. Pearson Education India, 1986.

[14] Jakob Nielsen. Parallel & iterative design + competitive testing = high usability.
http:// www.nngroup.com/ articles/ parallel-and-iterative-design/ , January 2011.
[Online; accessed 21-Jan-2015].

[15] Jakob Nielsen. Iterative user-interface design. Computer, 26(11):32–41, 1993.

[16] Gestalt laws of grouping.

http:// en.wikipedia.org/ wiki/ Gestalt_psychology#Gestalt_laws_of_grouping.
[Online; accessed 11-Nov-2014].

[17] Donald A Norman. The design of everyday things. Basic books, 2002.

[18] Judy Jeng. Usability assessment of academic digital libraries: Effectiveness,

efficiency, satisfaction, and learnability. Paper received 30 May 2005 and accepted
4 August 2005.

[19] Designprocessen 2. http:// www.eat.lth.se/ fileadmin/ eat/ MAMA15/

Designprocessen_2_MAMA15_HT13-VT14.pdf . [Online; accessed 20-Aug-2014].

[20] Användbarhetsutvärdering mam120. http:// www.eat.lth.se/ kurser/

interaktionsdesign/ anvaendbarhetsutvaerdering-mam120/ . [Online; accessed
21-Aug-2014].

[21] Use cases. http:// www.usability.gov/ how-to-and-tools/ methods/ use-cases.html.

[Online; accessed 17-Nov-2014].

[22] Jakob Nielsen. Summary of usability inspection methods.

http:// www.nngroup.com/ articles/ summary-of-usability-inspection-methods,
January 1995. [Online; accessed 19-Nov-2014].

[23] Jakob Nielsen. How many test users in a usability study?

http:// www.nngroup.com/ articles/ how-many-test-users/ , June 2012. [Online;
accessed 16-Feb-2015].

[24] Jakob Nielsen. Why you only need to test with 5 users.
http:// www.nngroup.com/ articles/ why-you-only-need-to-test-with-5-users/ ,
March 2000. [Online; accessed 16-Feb-2015].

[25] Usability testing.

http:// www.usability.gov/ how-to-and-tools/ methods/ usability-testing.html.
[Online; accessed 19-Nov-2014].

[26] Pilot testing. http:// en.wikipedia.org/ wiki/ Pilot_experiment. [Online; accessed

19-Nov-2014].

58
 REFERENCES

[27] Before usability testing. http:

// www.usability.gov/ how-to-and-tools/ methods/ planning-usability-testing.html.
[Online; accessed 19-Nov-2014].
[28] After usability testing. http:// www.usability.gov/ how-to-and-tools/ methods/
reporting-usability-test-results.html. [Online; accessed 19-Nov-2014].
[29] Joakim Eriksson. When should you test?
https:// lu.app.box.com/ s/ g3r0py8sb6mmlelqsnyt/ 1/ 2383500167/ 20720531781/ 1,
November 2014. [Online; accessed 27-Nov-2014].
[30] Types of videoconference systems. http:// picturephone.com/ learn/ types.html,
2013. [Online; accessed 10-Sep-2014].
[31] Logitech tv cam hd.
http:// shop.skype.com/ skype-for-tv/ tv-compatible-webcams/ logitech-tv-cam-hd.
[Online; accessed 21-Aug-2014].
[32] For meetings, specifications.
http:// www.google.se/ intl/ en/ chrome/ business/ solutions/ for-meetings.html#specs.
[Online; accessed 18-Aug-2014].
[33] For meetings, features. http:
// www.google.se/ intl/ en/ chrome/ business/ solutions/ for-meetings.html#overview.
[Online; accessed 18-Aug-2014].
[34] Simple and intuitive video conferencing system with lifesize icon series.
https:// www.youtube.com/ watch?v=AsrZNZz4Wtw, January 2013. [Video file;
accessed 21-Aug-2014].
[35] Lifesize icon series.
http:// www.lifesize.com/ en/ products/ video-conferencing-systems/ icon. [Online;
accessed 19-Aug-2014].
[36] Lifesize icon 600 datasheet. http:// www.lifesize.com/ ~/ media/ Documents/
Product%20Documentation/ Icon%20600/ Product%20Datasheets/ Lifesize%
20Icon%20600%20Datasheet%20EN.ashx. [PDF file; accessed 21-Aug-2014].
[37] Blue jeans. http:// bluejeans.com/ . [Online; accessed 21-Aug-2014].
[38] Hook flash. http:// hookflash.com/ . [Online; accessed 21-Aug-2014].
[39] Palbee: A free and interesting web conferencing contender. http:// gigaom.com/
2008/ 09/ 17/ palbee-a-free-and-interesting-web-conferencing-contender/ . [Online;
accessed 21-Aug-2014].
[40] Parkslide. http:// v1.derekmack.com/ work/ parkslide/ . [Online; accessed
21-Aug-2014].
[41] Lifesize icon series video conferencing demo.
https:// www.youtube.com/ watch?v=AsrZNZz4Wtw, January 2013. [Video file;
accessed 19-Aug-2014].

59
REFERENCES

[42] Jakob Nielsen. Thinking aloud: The #1 usability tool.

http:// www.nngroup.com/ articles/ thinking-aloud-the-1-usability-tool, January
2012. [Online; accessed 19-Nov-2014].

[43] Retrospectic probing.

http:// www.usability.gov/ how-to-and-tools/ methods/ running-usability-tests.html.
[Online; accessed 19-Nov-2014].

[44] GStreamer team. gst-launch-0.10. http:// linux.die.net/ man/ 1/ gst-launch-0.10.

[Online; accessed 18-Feb-2015].

[45] Jakob Nielsen. 10 usability heuristics for user interface design.

http:// www.nngroup.com/ articles/ ten-usability-heuristics, January 1995. [Online;
accessed 14-Oct-2014].

60
Appendices

61
Appendix A
10 Usability Heuristics for User Interface
Design

Below is Jakob Nielsen’s 10 general principles for interaction design. He calls them
"heuristics" because they are broad rules of thumb and not specific usability guidelines
[45]:

Visibility of system status

The system should always keep users informed about what is going on, through appropri-
ate feedback within reasonable time.

Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar
to the user, rather than system-oriented terms. Follow real-world conventions, making in-
formation appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency
exit" to leave the unwanted state without having to go through an extended dialogue. Sup-
port undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the
same thing. Follow platform conventions.

Error prevention
Even better than good error messages is a careful design which prevents a problem from
occurring in the first place. Either eliminate error-prone conditions or check for them and
present users with a confirmation option before they commit to the action.

63
A. 10 Usability Heuristics for User Interface Design

Recognition rather than recall

Minimize the user’s memory load by making objects, actions, and options visible. The
user should not have to remember information from one part of the dialogue to another.
Instructions for use of the system should be visible or easily retrievable whenever appro-
priate.

Flexibility and efficiency of use

Accelerators – unseen by the novice user – may often speed up the interaction for the expert
user such that the system can cater to both inexperienced and experienced users. Allow
users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every ex-
tra unit of information in a dialogue competes with the relevant units of information and
diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the
problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be neces-
sary to provide help and documentation. Any such information should be easy to search,
focused on the user’s task, list concrete steps to be carried out, and not be too large.

64
Appendix B
Script for usability testing iteration 1

Presentation

• You work at a company.

• You are about to use this conference camera for the first time.

• You are in a conference room where the camera will be permanently placed.

• The camera is connected to the TV with a HDMI cable and connected to the internet
with an ethernet cable.

• In your hand you are holding the remote control for the TV, in this test you will be
interacting with the video conference system using this remote control.

Scenario 1 You have recently bought a new conference camera and want to start using it
by getting to the main menu after you have plugged in all the cables needed.

Scenario 2 You have the camera on the shelf and you want to change the cameras PTZ
position using the remote control.

Scenario 3 Your conference system is by default used with English and you want to change
it to Swedish.

Scenario 4 You want to customize your video conference experience by becoming an ad-
vanced user. Remove the nestled window in you view that shows yourself.

Scenario 5 You want to initiate a video conference call with the persons that are located
in the room "Axis Herkules".

65
B. Script for usability testing iteration 1

Scenario 6 You are in your conference room and are waiting for a call from "Axis Hippo-
dromen". Answer the call.

66
Appendix C
Test plan iteration 2

Purpose
The purpose of the usability test in iteration 2 is to receive useful feedback from the real
target group on computer made prototypes. The questions we want to get answers to is
for example: By fixing issues from iteration 1 have we introduced new problems? Is
there a difference now when we are doing a computer made prototypes instead of paper
prototypes? Is it something that the real target group finds good or bad in contrast to the
master students in usability and design from iteration 1? Is the interface easy to use for
the whole intended target group? Is there any part of the interface where the user becomes
uncertain or cannot understand how to follow?

Scope
The testing will be performed on computer made prototypes of the Axis Communications
Utility cameras video conference mode. The prototypes are from iteration 2 of 3 and will
consist of the whole overlay interface system, the cloud service will not be included.

Environment
The test will be executed 2014 week 45 and 46 at Axis Communications buildings at
Emdalavägen in Lund. The number of test participants and sessions that will be held
depends on how many that can volunteer their time for us. The vision is to held the test in
conference rooms in the H building.

Session
The test will be 20 minutes long each and afterwards it will be free discussion for 10
minutes and here is it after that it will be possible for for the test leader to reset the test

67
C. Test plan iteration 2

environment for the next test person. Every test session will be 30 minutes long and the
test persons will come every forty fifth minute which means 15 minutes for resetting the
environment and briefly review the session.

Equipment
The test will contain of table with room for at least four seatings, laptop preferably 15
inches and the operating system should be Linux, camera that can document the test, time-
keeper, paper and pencils for the note taker.

Participants
The test persons will be recruited mainly by our supervisor at Axis Communications and
everybody will be from our target group. Our target group is employees at Axis Commu-
nications who might want to have video conference. For the test we would prefer to have
eight test persons but five is the minimum number we want to test to get the most out of
the usability test.

Scenarios:
1 Ändra kameran så du är i bild och gå därefter tillbaka till huvudmenyn.

2 Ring konferensrummet Yellow i Chicago.

3 Ändra så att personen i andra änden av videokonferenssamtalet är i bild.

4 Stäng av mikrofonen så att personen i andra änden av samtalet inte kan höra vad du säger.

5 Avsluta videokonferenssamtalet med konferensrummet Yellow.

6 Zooma in på din kamera och gå därefter tillbaka till huvudmenyn.

7 Ändra språk till Spanska.

Method
The test will be held in the environment described above, it is the real video conference
environment that is pursued. The test leader brings all the necessary equipment for the test.
First the test person will be greeted welcome and the outline will be described. Afterwards
the test will start and proceed scenario for scenario. Afterwards a debriefing will be held.

Roles
The test will be held by the test leader who will integrate with the testperson but only if
necessary, afterwards a short discussion will occur. The test also contains a note taker that
will write down everything said during the test. The test leader will as well take time if so
needed.

68
Data collection
The primary data collection will be qualitative data that the note taker wrote down and
later analysed. Every test session will be taped which means that the analysis can be done
on that material as well. Another form of data is from the debriefing when the test person
with his or her own words can give suggestions for improvement in either a interview or a
survey.

69
C. Test plan iteration 2

70
Appendix D
Debriefing survey iteration 2

Post test questionnaire - Video Conference System

Answer the following questions with a number between 1 to 5, 1 means strongly disagree
and 5 means strongly agree.

I feel confident that I used this system correctly.

1 2 3 4 5

I think that I would need to ask questions to know how to use this system.
1 2 3 4 5

I think that most people would figure out how to use this system very quickly.
1 2 3 4 5

Figuring out how to navigate in this system was difficult.

1 2 3 4 5

I think that this system was easy to use.

1 2 3 4 5

I think the amount of information where adequate.

1 2 3 4 5

I think the use of color where appropriate.

1 2 3 4 5

71
D. Debriefing survey iteration 2

Answer the following questions with free text.

Problems with navigation?

Problems with losing your place in the system?

Too much or too little information?

Both experienced and novice users accommodated?

Terminology confusing?

Adequate feedback after completing actions?

Sentences appropriate length?

72