Incorporating Video Support in an Innovative Communications Solution

Incorporating Video Support in anInnovative Communications

Solution

Jonas Sandström and Hannes Wikström

October 31, 2010Master’s Thesis in Computing Science, 2*30 credits

Supervisor at CS-UmU: Prof. Lars-Erik JanlertExaminer: Per Lindström

Umeå UniversityDepartment of Computing Science

SE-901 87 UMEÅSWEDEN

Abstract

Ericsson is a large actor in the telecom industry, providing infrastructure and commu-nication solutions connecting billions of people around the world. The Multimedia branchof Ericsson focuses on the development of communications solutions, and one of these newinnovative solutions is called Cloud Communication. The Cloud Communication system pro-vides an anonymous peer-to-peer communication service through multiple channels. Thismaster thesis is a step to further expand the channels that the system supports as well asrebuild and redesign the applications that make the communication possible. Methodologiesthat helped achieving this was mainly the design process and to help plan and execute theproject Scrum was used. The results of the thesis were added support for video conversa-tions and two entirely new clients supporting the new feature together with the old ones.These new clients can be used to demonstrate the capabilities of the Cloud Communicationsystem and the features it supports. Video conversations in an anonymous context is how-ever questioned and the conclusion is that the video-use case mainly should be applied in acollaboration/business context in which the clients currently are implemented.

Contents

1 Introduction 11.1 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 About Ericsson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Solutions Area Consumer and Business Applications . . . . . . . . . . 31.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 Cloud Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Widget Management System . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Existing Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Problem Description 113.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Method 134.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Collaborative Software Development . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.1 Apache Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.2 Apache Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Creative Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5 Technical Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.5.1 Red5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.6 Flash Catalyst workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Video Communication - Possibilities and Limitations 215.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iii

iv CONTENTS

5.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3 Summary and discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Guidelines for a Successful Business Model in Cloud Communication 276.1 Definitions of Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.1.1 Existing Business models . . . . . . . . . . . . . . . . . . . . . . . . . 286.2 Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2.1 Mobile Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2.2 Mobile Payment Procedures . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3 Trust and Business Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.3.1 Factors influencing trust . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.4 Summary and Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.5 Discussion and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7 Design 357.1 Theoretical foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.1.1 Shneiderman’s Eight Golden Rules of Interface Design . . . . . . . . . 357.1.2 Norman’s design principles . . . . . . . . . . . . . . . . . . . . . . . . 36

7.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.3 Concepts and Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.3.1 Web Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.3.2 Desktop Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

8 Results 418.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418.2 Prototype Video Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.3 Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.3.1 Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.3.2 Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.3.3 Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.4 Desktop Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.4.1 Login procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.4.2 Incoming call procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 518.4.3 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8.5 System testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.6.1 Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

9 Conclusions and Discussions 599.1 Possible use-cases for video . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.2 Restrictions and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

CONTENTS v

9.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

10 Acknowledgements 63

References 65

A Source Code 69A.1 POM Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

B Figures 71B.1 Interaction flow-charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

C Mockups 75

D Build Guidelines 83D.1 Desktop Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83D.2 Web Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

vi CONTENTS

List of Figures

1.1 Organizational overview of Ericsson. . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 An example of the communication widget that can be inserted on websitesor in mail signatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Revenue flow for CloudCom. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 WMS architectural overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 The CloudCom web client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 The CloudCom desktop client . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1 The Scrum process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Burndown-chart for the thesis’ third sprint. . . . . . . . . . . . . . . . . . . . 154.3 Task-board for the thesis’ third sprint. . . . . . . . . . . . . . . . . . . . . . . 154.4 Simple interaction design process . . . . . . . . . . . . . . . . . . . . . . . . . 174.5 The workflow using Flash Catalyst . . . . . . . . . . . . . . . . . . . . . . . . 20

7.1 The final concept chosen for the web client. . . . . . . . . . . . . . . . . . . . 397.2 A simple mockup of the desktop client. . . . . . . . . . . . . . . . . . . . . . . 39

8.1 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428.2 Call overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.3 Video integration in the existing web application . . . . . . . . . . . . . . . . 448.4 Video integration in the existing desktop application . . . . . . . . . . . . . . 448.5 Initial screen of the new interface . . . . . . . . . . . . . . . . . . . . . . . . . 458.6 The message interface of the application . . . . . . . . . . . . . . . . . . . . . 468.7 SMS2Go interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.8 The video type selection screen . . . . . . . . . . . . . . . . . . . . . . . . . . 488.9 The calling screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.10 Interface for video call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.11 Interface for voice call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.12 Interface for Call2Go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508.13 The login screen of the desktop client. . . . . . . . . . . . . . . . . . . . . . . 528.15 The notification displayed during an incoming call from the web client. . . . . 52

vii

viii LIST OF FIGURES

8.14 Screen showed when log in to the WMS is successful. . . . . . . . . . . . . . . 538.17 The call window when video is disabled on both ends . . . . . . . . . . . . . . 538.16 The call window during a video conversation . . . . . . . . . . . . . . . . . . 548.18 The settings window for the desktop client . . . . . . . . . . . . . . . . . . . . 55

B.1 Flow chart for desktop client. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72B.2 Flow chart for web client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C.1 The tab concept with spacing between components. . . . . . . . . . . . . . . 75C.2 A more compact version of the tab concept. . . . . . . . . . . . . . . . . . . . 76C.3 Another tab concept with no spacing and the presentation section placed

below the tabs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77C.4 A concept with where the the different pages gets flipped into place. . . . . . 78C.5 Design with speech bubble style menu bar. . . . . . . . . . . . . . . . . . . . . 79C.6 A concept that mimics a physical business card. . . . . . . . . . . . . . . . . . 80C.7 A concept that uses a knob for navigation. . . . . . . . . . . . . . . . . . . . . 81C.8 A simple mockup of the desktop client. . . . . . . . . . . . . . . . . . . . . . . 82

Chapter 1

Introduction

Communication solutions and telecommunication services is the core of Ericsson’s world-wide operations. About 40 percent of the world mobile traffic passes through their networks[8].Apart from building the infrastructure connecting billions of people around the world, Eric-sson also provides multimedia solutions that simplifies the possibility for people to commu-nicate globally. The Multimedia branch of Ericsson delivers communication solutions andcollaboration services that grant quick access with support for charging and billing users ofthe solutions. Ericsson’s vision is to:

”Be the Prime Driver in an all-communicating world. This means a world inwhich people can use voice, data, images and video to share ideas and informationwhenever and wherever they want."[10]

In order to be this prime driver, building new and innovative communication solutionsis important if Ericsson wants to keep their position as a world leading actor in the tele-com industry. This master thesis is a part of the development of these new innovativeapplications.

In 2009 a small agile team started the development of a new innovative communicationsolution called Cloud Communication (CloudCom). With a growing fear of exposing privateinformation on the Internet, an anonymous peer-to-peer communication service was devel-oped. The applications started out with a few use-cases such as making anonymous voiceover ip (VoIP) calls, sending SMS messages or emails. The aim of this thesis was to furtherexpand the functionality of CloudCom by adding support for video calls. The integrationof the video functionality consisted of actually adding support for the video in the back-endsolution as well as rebuilding the interfaces of the applications to support the new feature.In addition to the technical work two deep studies have been carried out. One study that isinvestigating the limitations and possibilities with video communication and another thatproposes guidelines for a successful business model with regards to CloudCom.

This report is a part of a 300 ETCS credit Masters of Science in Interaction designand concludes 5 years of studies at Umeå University for the authors Jonas Sandström andHannes Wikström.

1.1 Thesis OutlineThis section gives a brief overview over the structure of the thesis study. It also introduceseach chapter with a small summary of its content.

1

2 Chapter 1. Introduction

Chapter 1 - Introduction

– Chapter one gives a short introduction to the thesis study and a brief presentation ofEricsson and the division at which this thesis work was carried out. Furthermore itgives an introduction to the project that the thesis work was part of and introducessome key terminology and abbreviations that is used through out the report.

Chapter 2 - Background

– Chapter two presents the project which this thesis is part of. It describes the use-casesof the existing system, the system’s architecture and presents the existing applicationsthat are to be rebuilt.

Chapter 3 - Problem Description

– Chapter three specifies the goals with the thesis, and also defines the purposes ofachieving the goals.

Chapter 4 - Method

– Chapter four describes what methods are used to achieve the goals of the thesis. Meth-ods for planning, design and implementation of applications are presented togetherwith the tools and frameworks for doing so.

Chapter 5 - Video Communication - Possibilities and Limitations

– Chapter five defines video communication and investigates its possibilities and limita-tions.

Chapter 6 - Guidelines for a Successful Business Model in Cloud Communication

– Chapter six presents a literature study concerning how to incorporate successful busi-ness models with CloudCom. The study is concluded with guidelines that will helpimprove any business model that is adopted by CloudCom.

Chapter 7 - Design

– Chapter seven reviews some design guidelines used in the design of the applications.The chapter gives an overview over the different steps in the design process of theapplications and several design proposals are presented and compared.

Chapter 8 - Results

– Chapter eight presents the outcome of the thesis work. An overview of the systemarchitecture together with a description of the desktop and web clients are presented.Furthermore functional aspects, tests, and evaluation of the two clients are discussed.

Chapter 9 - Conclusion and Discussion

– Chapter nine discusses the outcome of the thesis work as well as limitations and futurework.

1.2. About Ericsson 3

1.2 About Ericsson

Ericsson was founded in 1886 by Lars Magnus Ericsson and has since then grown into aglobal telecommunication company with offices in Europe, North America and Asia. TodayEricsson has over 80 000 employees. Apart from the research and joint venture companies(Sony Ericsson, ST-Ericsson), the organization of Ericsson is split into four different businessunits. The units are networks, global services, mobile systems and multimedia. See figure1.1 for a complete overview. The Solutions Area Consumer and Business Applications(SA CBA) which was where the thesis work was done is part of Business Unit Multimedia(BMUM).

Figure 1.1: Organizational overview of Ericsson.

1.2.1 Solutions Area Consumer and Business Applications

SA CBA provides Ericsson with Consumer/Business products and solutions. The aim of SACBA is to secure a long term competitive product provisioning. New and innovative solu-tions are created through cooperation within Ericsson Innovation as well as other partnersand customers.

The branch of the SA CBA where the thesis work was carried out is called DevelopmentStockholm. This branch focuses on development of software solutions for the delivery ofnext generation corporate communication solutions as well as delivery of state-of-the-artcontent and application services.

1.3 Terminology

This section contains terminology that is used in this report. When describing a complexsystem as CloudCom has become it is easy to be confused with the different use-cases andnotions. This list is an attempt to clarify the terms used and to help explain the meaningof them.

4 Chapter 1. Introduction

– A-party The person initiating use of the CloudCom system (The person that clicksthe communication widget).

– B-party The person that has subscribed to the CloudCom service and has installedthe communications widget onto their website or in their email signature. (The personbeing contacted).

– Widget-owner Same as B-party.

– SMS2Go is a communication channel where the A-party and the B-party can engagein an anonymous SMS conversation with CloudCom acting as the mediating party.

– Call2Go is a communication channel where the A-party and the B-party can set upan anonymous phone-to-phone call with CloudCom acting as the mediating party.

– ECN-trial was the first real beta-trial where CloudCom was tested.

– (Communication) Widget is the button that is injected by CloudCom in the A-party’s website or email signature (see figure 2.1 for an example).

– Web client/application is the application displayed when the A-party clicks thewidget embedded on websites.

– Desktop client/application is the application that the B-party installs on theircomputer to be able to receive voice and video calls.

– Anonymous Anonymous in the context of this report refers to user not having toexpose any private information such as email or telephone number.

1.4 AbbreviationsThe following abbreviations are used in the report.

– CloudCom Cloud Communication.

– IPX Ericsson Internet Payment Exchange.

– SA CBA The Solutions Area Consumer and Business Applications, is a branch ofthe multimedia business unit of Ericsson at which the thesis work was carried out.

– WMS Widget Management System.

– MP Mobile Payments

Chapter 2

Background

This chapter gives some important background information about the Cloud Communicationproject which this thesis was part of. The basic concepts of CloudCom are explained, use-cases are described and some architectural aspects of the project are accounted for. Theexisting web and desktop applications are also briefly described.

2.1 Cloud CommunicationThe thesis work conducted was as mentioned in the introduction part of an innovationproject called CloudCom. What this project essentially has become is a toolbox for settingup an anonymous communication channel between two peers. Anonymous meaning thatno private information of either of the peers is disclosed to the other peer. Other greatadvantages of CloudCom is that you do not have to update your contact information inmultiple places and that it offers a simple way for the person being contacted to charge theother peer on a per minute basis. The users can in this sense determine a fee of how muchthey think their time is worth.

Imagine that you are a dog breeder and you want to provide the readers of your blog aneasy way to contact you, but you do not want to display your phone number or email addresspublicly on your website. With the help of CloudCom you can then insert a communicationwidget letting people contact you anonymously (see figure 2.1). Since CloudCom onlysupports communication in a one-way channel, meaning that communication channels onlycan be set up from one peer to the other and not the other way around we will from hereon refer to the person initiating the communication as the A-party and the person that isbeing contacted as the B-party.

Figure 2.1: An example of the communication widget that can be inserted on websites orin mail signatures.

5

6 Chapter 2. Background

2.1.1 Use cases

CloudCom is able to set up several different types of communication channels dependingon what the service provider supports. Apart from the planned video support the availablechannels are:

1. Web Client → PC Client (voice) This use case requires that the B-party has asmall desktop client installed on their computer. A VoIP call can then be made fromthe communication widget straight to the B-party’s computer.

2. Web Client → Mobile Phone (voice) If the B-party is not running the desktopclient or is not answering within 15 seconds the call is rerouted to the B-party’s mobilephone.

3. Mobile phone → PC Client (voice) If the A-party sets up a Call2Go call (seesection 1.4) and the B-party is running the desktop client, the call is routed to thedesktop client.

4. Mobile phone → Mobile phone (Call2Go) This use case does not require anydesktop client to be installed on the B-party’s computer. The A-party enters theirphone number in the communication widget and gets called up by CloudCom. Amessage is played asking if the A-party wants to connect the call. If the A-partyaccepts, the call is connected to the B-party.

5. SMS → SMS (SMS2Go) This channel adopts a similar procedure as the Call2Gochannel. The difference is that the A-party receives an SMS instead of a phone call. Ifthe A-party answers the SMS received from CloudCom it is forwarded to the B-partyand if the B-party in turn answers that SMS it is returned to the A-party. CloudComacts as an intermediary hiding the two peers phone numbers from each other.

6. One way SMS The A-party can send an SMS directly from the communicationwidget without the possibility for the B-party to answer it. Instead the A-party isable to provide their phone number and email address if they wish that the B-partyto get back to them.

7. Email Same as the one-way SMS channel except that an email is sent instead.

The first four of these use cases are all currently implemented in the Ericsson Com-munication Network trial (ECN-trial), which is available for all employees at Ericsson. Asmentioned, these use cases require users to download and install a desktop client on theircomputer. What is also important to mention is that the use cases where the A-party en-gages in communication with the Web client, it is currently not possible to implement abusiness model. This due to the fact that Cloudcom does not support a way of charging theA-party if the communication channel does not utilize the A-party’s mobile phone.

The fourth and fifth use-cases are running as a beta on one of Sweden’s largest blog sites.These support the use of a business model which both Ericsson and the B-party using thesystem can collect revenue from.

2.1.2 Business Model

As mentioned in the previous section the fourth and fifth use-case of CloudCom has anintegrated business model. Imagine that your are a famous blogger and you want to make it

2.1. Cloud Communication 7

possible for people to contact you, but you also want to be able charge people for the timeit takes you to communicate with them. This is exactly what CloudCom is able to do. Byutilizing the Ericsson IPX technology, CloudCom can charge the A-party’s mobile phonebill and make revenue payments to the blogger through the content provider. See figure2.2 for an overview of the revenue flow. The revenues can then be distributed between thedifferent parties, making it profitable for everyone.

IPXContentProvider

A-party B-party

$ $ $

Figure 2.2: Revenue flow for CloudCom.

2.1.3 Widget Management SystemThe development of CloudCom has resulted in a feature rich back-end-solution that supportsa set of different services and business models. As the project grew, the potential for reusingparts of the solution in other projects became evident. Consequently, the core architectureof CloudCom was renamed to the Widget Management System or in short the WMS. Exceptfrom the use-cases in section 2.1.1 the WMS solves business model tasks such as charging,multiple price groups and revenue sharing. It also has multitendancy support meaning thatit can handle multiple partners connecting to the same back-end server. Depending onthe partner needs, different provisioning GUIs and different communication widgets can bedisplayed by the WMS.

The WMS is split up into three different layers (See figure 2.3). First there is a presenta-tion layer that handles the presentation of the communication widgets and the provisioningGUIs. Secondly there is the business layer that handles logic and the exchange of databetween the presentation layer and the database layer. Finally there is a database layerwhich essentially is an abstraction layer on top of a database that stores all data. Theabstraction layer makes it possible for the WMS to connect to several different types ofdatabases without having to rewrite any code.

The plugin framework is another important feature to mention. The plugin frameworkmakes it possible to connect the WMS to several different operator backends or internalEricsson features by writing small plugins. Often these plugins connect to third party ser-vices trough REST interfaces. Examples of plugins currently implemented are the chargingplugin which connects to Ericsson IPX1 (Internet Payment eXchange), SMS/Email pluginthat makes it possible to send messages and the call service plugin which hooks up to aIP-telephony switchboard called Asterisk2.

1http://www.ericsson.com/ourportfolio/products/internet-payment-exchange-ipx2http://www.asterisk.org


Database Layer

Business Logic

Present.Widget

WidgetData

Provison.GUI

Config

Plugin (SMS, Em

ail, Charging..)

Presentation

BusinessLogic

Database

DB

Web Browsers

JEE Application

Figure 2.3: WMS architectural overview.

2.2. Existing Applications 9

The WMS also has a configuration module that consists of an administration GUI, aclient interface that manages the different widget types and a routing interface that providesthe right provisioning GUIs and widgets for the different partners.

The Goal of the WMS is to be:

”A platform that exposes complex Ericsson features and business models in asimple and easy to use way through widgets to regular Internet end-users"

This quote summarizes what problems the WMS solves and how it fits in with futureproducts and services from Ericsson. The entire WMS and most of its components arecompiled into a single Java EE application that is deployed on a Sailfin application server.

It is important to mention that the WMS only is a part of the CloudCom system.CloudCom consists of a few other architectural elements. There is a media server calledRed53 and a IP-telephony switchboard called Asterisk. These are needed to realize the usecases where voice calls are made through the system. Red5 records the users voices through aprotocol called RTMPT (Real Time Messaging Protocol Tunneled). An application runningon the Red5 server called Red5Phone4 then translates the voice stream to a SIP (SessionInitiation Protocol) stream and delivers it to the other peer. If a call is made to a mobilephone the SIP stream is rerouted to Asterisk which can connect the call to the cellularnetwork. Combined these components become the Cloud Communication system.

2.2 Existing ApplicationsThe CloudCom system can be divided into several branches, called partners. CurrentlyCloudCom has two live partners. One partner is one of Sweden’s largest blog portals and theother is the Ericsson Communication Network (ECN) which has an internal CloudCom trialrunning. Each partner has a unique widget which displays different communication appli-cations. The target for this thesis was the applications connected to the internal CloudComwidget.

In short, the client side of the system consists of two applications, one web applicationand one desktop application. A communication channel is then opened between the peersin the following way:

1. The A-party clicks the widget button on a website or in an email.

2. The A-party gets prompted by B-party’s personal CloudCom web application.

3. The A-party can in the web application choose from four different modes of commu-nication: SMS, Email, VoIP or Call2Go.

4. If the B-party is running the desktop application VoIP calls are directed to the client,otherwise they will be redirected to the B-party’s mobile phone.

Figure 2.4 and 2.5 are screenshots of the current versions CloudCom ECN trial clients.Figure 2.4 shows the web application. It is a Flash application which is embedded on aweb page. The user can make a VoIP call by clicking the green button, switch to Call2Gomode by clicking "Call To Go" and send SMS or Emails to the widget owner by clickingthe message icon. Figure 2.5 shows the login screen of the desktop client, which is an AIR

3http://red5.org4http://code.google.com/p/red5phone


application. The user logs in with an email-address and a password. If the user successfullylogs in, the application will run in the background, accessible from the system tray or dock.If a call is incoming, a small notification popup with the options to answer or decline thecall will be displayed in the bottom right corner of the screen.

Figure 2.4: The CloudCom web client

Figure 2.5: The CloudCom desktop client

Chapter 3

Problem Description

In this chapter the main task of this master’s thesis and the goals of the assignment arepresented. It also specifies the purpose of the thesis.

3.1 Goals

The assignment for this master’s thesis was to evaluate and redesign an existing communi-cation solution, Cloud Communication, that integrates communication on web sites basedon widget technology. This was to be done from a technical, design and business standpoint.The main goals of the thesis were:

Integrate a Video User Interface into the existing communication solution Thisgoal includes finding an appropriate technology to stream video between two partic-ipants, and integrate that technology together with a user interface into the existingsolution. This would involve updating the server-side with support for video stream-ing. In order to get support and understanding of the system and needs, workingclosely with the existing agile team that develops the Cloud Communication systemwas a necessity.

Design the next generation of the communication widget The second goal was todevelop the concept and a prototype for the next generation of the communicationclients, with focus on usability and user experience. The new communication solutionwas to be developed using similar technologies (Flash and Web 2.0 technologies) thatwere used for the existing clients. The redesign of the system included creating newinterfaces for the web-application and the desktop-application and to connect thesewith the existing back-end solution. The new solution was to be designed so that itcan be used to demonstrate how the widget communication can be utilized, not onlyusing existing communication channels but also adding new features.

Propose and evaluate business models The third goal was to find suitable use cases forvideo communication, and also propose and evaluate business models for CloudComwith video.

Benchmarking This goal includes comparing CloudCom’s strength and weaknesses withother solutions on the market.

11

12 Chapter 3. Problem Description

User evaluation Finally a usability evaluation was to be carried out, where a small groupof external users would test the new UIs, features and concepts.

3.2 PurposeConversation is much more than the exchange of verbal messages. Video has become acommon channel for communication and collaboration over a distance as it adds featuressuch as gaze, posture, gesture and facial expression to the conversations. This can add orimprove the ability to show understanding, forecast responses, express attitudes and muchmore (See chapter 8.16). Ericsson also states in their vision that video is a part of theall-communicating world in which they aim to be the Prime Driver[10]. The main purposeof this thesis is the addition of video in the CloudCom system, but also to expand thefunctionality of the Widget Management System to support video communication. Thiswould allow users to engage in video conversations anonymously over the web.

Chapter 4

Method

This chapter describes the process of the Master’s Thesis. Several methods have beenused in carrying out the work; the methods with the greatest impact are presented in thefollowing sections. This chapter also describes the creative, as well as the technical toolsused throughout the thesis.

4.1 Scrum

As an attempt to make research and development more agile, several departments withinEricsson use the Scrum methodology. However, rather than being a full process or method-ology, Scrum is an iterative, incremental framework for project management and softwaredevelopment. As we were included in the CloudCom team, which uses Scrum, we alsoadopted the method.

The framework was introduced by Ken Schwaber and Jeff Sutherland, inspired bythe Japanese management researchers Hirotaka Takeuchi and Ikujiro Nonaka. The word"scrum" originally refers to a term in rugby where the all players in a team collaborate ina specific formation.[30]

Scrum has been used to develop complex products since the early 1990s. It is ideallysuited for projects with rapidly changing or highly emergent requirements. A scrum teamis typically made up of between five and nine people, but can easily be scaled into thehundreds. The team does not include traditional software engineer roles such as programmer,designer, tester or architect. Scrum is a process skeleton which contains sets of practicesand predefined roles. The following are the three predefined roles in a scrum team[34]:

The Product Owner is the project’s key stakeholder and represents users, customers andothers in the process. The product owner is often someone from product managementor marketing, a key stakeholder or a key user.

The Scrum Master is responsible for making sure the team is as productive as possible.The scrum master does this by helping the team use the Scrum process, by removingimpediments to progress, by protecting the team from outside, and so on.

The Team is a cross-functional group of about 7 people who do the actual analysis, design,implementation, testing, etc. The team should be self-organizing and not have anelected leader.

13

14 Chapter 4. Method

Scrum focuses on the work process of a project and begins with defining a product backlog[30],see figure 4.1. The product backlog contains backlog items, which are broad descriptionsof the products required features. Every backlog item is prioritized by business-values anddevelopment effort. Projects progress via a series of iterations called sprints. Each sprintis typically 2-4 weeks long. At the start of a new sprint, a sprint planning meeting is held.Before this meeting the product owner prioritizes the product backlog. Every backlog itemshould be rated with a specific score of complexity which defines how much effort the itemrequires. This score is defined by letting each team member vote, with specially designedplaying cards for example. The complexity is not linearly mapped to the time requiredto complete the task, as a simple yet expansive task may be more time consuming thanan advanced task. However the complexity usually gives good hint of the time requiredrelative to other items. The scrum team selects the backlog items that they will be able tocomplete during the upcoming sprint. Those backlog items are then transferred from theproduct backlog to the sprint backlog, which is a list of tasks that the team has committedto complete during the sprint.

Product backlog

Sprintbacklog

Daily scrummeetings

2-4 weeks

24 hours

Workingincrement of the product

Sprint

Figure 4.1: The Scrum process

On each day of a sprint, the team gathers for a brief meeting called the "daily scrum"or "stand up meeting". All team members are required to attend to the meeting, whichmakes it a good opportunity to disseminate status information and set the context for thecoming day’s work. During the meeting every team member answers the following threequestions[34]:

– What did you do yesterday?

– What will you do today?

– Do you have any problems preventing you from accomplishing your goal?

By focusing on what each person accomplished yesterday and will accomplish today, theteam gains a good overview of what has been done and what remains[30]. The daily scrum

4.1. Scrum 15

is also a good time for members to make commitments to one another. The meeting islimited to 15 minutes.

One important artifact in Scrum is the burndown-chart[30]. It is a publicly displayedchart that represents the remaining work of the sprint backlog and gives an indication onwether or not the project is on schedule. After each daily scrum meeting the scrum masterupdates the burndown-chart. See figure 4.2.

Figure 4.2: Burndown-chart for the thesis’ third sprint.

Another artifact is the task-board[34], which contains all backlog items of the currentsprint (see figure 4.3). The backlog items are divided into minor subtasks, usually repre-sented as post-its or similar, which are time estimated. The task-board has three columns;one for items that are yet to be done, one for items that are in progress and one column foritems which have been completed. Each backlog item contains information about title of thetask and its complexity. The subtask contains information about the estimated time andmight also include the name or names of the persons working with the task. As a personchecks out a task, it transfers from the "todo"-column to the "ongoing"-column. A task isfinished when it fulfills all the criteria of a concept called "Definition of done". This is a gen-erally accepted term of when a task is done with regards to testing and delivery. When thetask is done it gets transferred to the "done"-column. In addition to the burndown-chart,the task-board gives further information of how much work remains to be done.

Figure 4.3: Task-board for the thesis’ third sprint.


At the end of each sprint, a public sprint-demo is conducted to present what the teamhas accomplished during the sprint[34].

4.2 Collaborative Software Development

When creating large scale J2EE (Java 2 Enterprise Edition) software solutions like Cloud-Com it simplifies the development process to have a simple way of building the entire project.Component based development can be tricky since the applications can be deployed on differ-ent servers and run in different environments, meaning different types of application serversand databases[23]. The modules that CloudCom consists of is built upon Java and Flex.In order to simplify the build process the team developing CloudCom uses a tool calledApache Maven1 for the J2EE based modules and a another build tool called Apache Ant2for the Flex modules. These build tools were also used during the development of the videosupported clients. A short description of the build tools used are described in the followingtwo sections.

4.2.1 Apache Maven

Maven builds the project into one easily distributable package that can be deployed on mostapplication servers. The core motivation for using Maven are the following. It makes thebuild process easier by abstracting the underlying build mechanisms. It provides a uniformbuild system that automatically generates valuable project information such as change logsand dependency lists. Finally it provides guidelines for best practices and simplifies theaddition of new features[1].

Maven achieves this by using an XML based scheme called a Project Object Model(POM) (see Appendix A.1 for an example). Each module in the project has a separate POMdescribing how the module should be built together with dependencies to other modules inthe project. POMs can also inherit dependencies from parent POMs. A project consistingof many modules will generate a tree structure of POMs that describes the entire projectwith its dependencies. Building the project with Maven will then ensure that the differentmodules are built in the correct order.

4.2.2 Apache Ant

Ant (Another Neat Tool) is another industry standard build tool that is built on Java. Antalso uses a scripting language that has an XML scheme to specify the build process. One ofthe great advantages of using Ant is that it supports cross-platform development[23]. Antis usually used to build Java projects but in CloudCom, Ant scripts are used to build theFlex modules. This is achieved through a Flex plugin called Flex Ant Tasks. This pluginallows Flex projects to be built with the same type of scripts used to build Java projects.The neat thing about combining Maven and Ant is that Maven has support for running Antscripts. This means that you can create one build script for projects containing both Javaand Flex components.

1http://maven.apache.org2http://ant.apache.org

4.3. Design process 17

4.3 Design processIt is very difficult, if not impossible to design a user interface completely relieved fromusability problem from the beginning. Therefore, a user interface should be designed byusing an iterative process. A common, simple design process, described by Preece, Rogersand Sharp[32] is the model displayed in figure 4.4.

Identify needs/establish

requirements

Evaluate

Build an interactive

version

(Re)Design

Final product

Figure 4.4: Simple interaction design process

The model consists of the following four phases[32]:

Identify needs and establish requirements The process begins with identifying theneeds and establish requirements for the application. This supports the designer inunderstanding the context of the product to make design decisions easier and to de-termine the required features. To gain the necessary knowledge needed for this the-sis project, a background study of the current applications and backend was made.Further on, flow-charts describing the application interaction were created to helpidentifying necessary features. The flow-charts can be found in appendix B.1

(Re)Design The next step is to generate some alternative designs as an attempt to meet theneeds and requirements that have been identified. This phase began with sketchingideas of the user interface using pen and paper, as well as simple drawings on awhiteboard. This made it easy to discuss features such as navigation, and some earlyideas could be neglected while others were refined. From the paper-sketches, digitalgraphical mockups were created to visualize the concept. This phase was revisitedcontinuously through out the design process as new features were added and othersneeded to be improved to increase the user experience.

Prototyping From the mock-ups, an interactive version or a prototype are to be developed.This is a good way to see if interface’s features work in reality, without having to spenda substantial amount of time on backend implementation, error handling etc. For thisproject, Flash Catalyst was used as a tool to create a prototype. This made it fairly


simple to go from computer graphical mock-ups, made in Adobe Illustrator, to aninteractive prototype. As the iterations proceeded the prototype converged towardsthe appearance of the final product.

Evaluation Finally, the interactive version is evaluated. Based on the feedback from theevaluation the team may need to return to identifying needs or redefining requirements.There are numerous ways to perform an evaluation. In this project, most evaluationwas made just by discussing results within the team. As some functions proved tobe inadequate, they were redesigned and implemented in a new prototype. Howeveras the team is fairly homogenous and not necessarily similar to the end user, theseevaluations are often insufficient. Having possible end users testing the prototype cangenerate some valuable information. Unfortunately, that mode of evaluation is notalways available. For this project, employees at Ericsson were the targets for mostevaluation.

4.4 Creative ToolsThis section describes the creative tool used during the design and prototype phases of thethesis work.

Omnigraffle is a diagramming application that currently is available for Mac OSX andthe Ipad. Omnigraffle makes it easy to produce diagrams, application mockups andwireframe designs. The program was used to produce interaction flow-charts anddesign mockups during the design stage of the project.

Adobe Illustrator CS5 is a vector graphics editor which can be used for creating vectorgraphics like logotypes, website designs and print work. Illustrator was used for cre-ating graphical designs for the web client and the desktop client. Some of the figuresin this report were also drawn with Illustrator.

Adobe Flash CS5 is an interactive multimedia editor which can be used for creating inter-active websites, cross-platform web applications and other types of multimedia content.Flash was used to create some of the animated content in the applications.

Adobe Flash Catalyst CS5 is a new interaction design tool that can create fully inter-active designs without writing a line of code. Catalyst was used to migrate the designsfrom Illustrator to interactive prototypes. These prototypes were then imported intoFlash builder where the back-end implementation was made. More information aboutthe catalyst work-flow can be found in section 4.6.

4.5 Technical ToolsThis section describes the technical tools used in the development phases of the thesis work.Both development environments as well as frameworks and SDKs are described.

Development Tools

Flash Builder CS5 is a an Integrated Development Environment (IDE) that makes iteasy to create cross-platform rich Internet applications (RIAs) using a frameworkcalled Flex. Flash builder was used for the back-end implementation, testing and

4.5. Technical Tools 19

debugging of the two clients. Flash builder can compile Flex projects as well as AdobeAir projects which makes it ideal for development of the web and desktop clientsneeded in CloudCom.

NetBeans 6.8 is a free open-source IDE that enables developers to create web, enterprise,desktop and mobile applications using the Java platform. NetBeans was used to buildand run and make modifications to the WMS locally and to write the javascripts, htmlpages and cascading style sheets (CSS) needed to display the web client correctly.

Frameworks and runtime environments

CloudCom is mainly built on the Java platform. The frameworks and runtime environmentsprimarily involved during the development in the thesis project were:

Flex is a free and open-source framework for creating web applications that can be deployedin most web-browsers or operative systems by utilizing the Adobe Flash player or AIRruntime environments. Flex uses an XML based syntax called MXML to specify thestructure of applications. Applications can then be skinned and styled by the builtin support for skins or by using CSS. Together with ActionScript 3, which is usedto implement functionalities and the back-end connection, it is possible to build richcontent applications.

Adobe AIR is a runtime environment that makes it possible to build web applicationswith standard web technologies such as html, javascript, flash and flex and run themnatively as a standalone client. The AIR environment is cross-platform which meansthat applications built with the framework can be deployed and installed on multipleoperative systems. The AIR technology was used to build a platform independentdesktop client with help of the Flex framework.

4.5.1 Red5

Another important software technology needed to realize the video use-case in CloudComis Red5. In order for a video conversation to take place a server that can send and receivevideo and voice streams is crucial. As mentioned in section 2.1.3 this is handled by a mediaserver called Red5. Red5 makes it possible to stream or record video and voice streamsfrom or to a web browser by use of the Adobe Flash Player environment. Red5 is an open-source implementation of the commercial Flash Media Server (FMS) and is built on Java[2].Features important for the video use-case of CloudCom which Red5 supports are:

– Streaming audio

– Streaming video

– Shared Objects

Streaming audio and video is pretty self explanatory, the support for shared objects isperhaps not. Shared objects makes it possible to share information across clients connectedto the server. Clients can change or send information through the object while connectedto the server and other connected clients are notified when this happens. In a CloudComperspective this made it possible for the desktop and web client to communicate and sendmessages to each other.


4.6 Flash Catalyst workflowAs stated in section 4.3, it is important to start a design with identifying the needs andestablishing the requirements. Then make graphical mock-ups and an interactive prototypeof the product, and continuously evaluate these. In this thesis a convenient tool, FlashCatalyst, was used to bridge the gap between the graphics of the interface and the imple-mentation. In other words, bridging the gap between the designer and the developer. Figure4.5 visualizes this work flow.

Ai Fc FB

Adobe illustrator Flash Catalyst Flash Builder

Designer - Developer gap

Figure 4.5: The workflow using Flash Catalyst

The process starts with designing all graphical components in Illustrator. In FlashCatalyst it is then possible to import the Illustrator-file and convert it to a FXG-file (FlashXML Graphics). Catalyst contains a set of predefined component-types; button, scrollbar,table etc. In Catalyst, the designer then defines the type of each graphical item, a bluerectangle becomes a button for example. The rectangle is then assigned predefined statessuch as MouseUp, MouseDown, MouseOver. The appearance for each state is then designedin Illustrator and simply dragged to the Catalyst scene. The project has got states too,however these are not predefined as in the button case but are defined by the designer.Between states, it is then possible to assign state-transitions, which is basically a transitionbetween two states. This could for example be to fade out and fade in items.

Further on, it is possible to run the application from Catalyst. This is a good way to testand evaluate navigation and transitions in an early phase. In fact, running the applicationwill generate an SWF-file, which can be embedded in a webpage for example, so it is possibleto create simple internet applications with Catalyst. However, to make it a rich internetapplication, further implementation such as backend connection is required.

In Catalyst it is possible to see the generated mxml code, it is however not possible tomodify or add code. The next step is instead to move on to Flash Builder (previously theAdobe Flex Builder IDE). Flash Builder can import the FXG-file generated by Catalyst andbuild a Flex project from it. In Flash Builder the developer can continue to combine thecode for the user interface with the business logic.

Chapter 5

Video Communication -Possibilities and Limitations

Over the past years the demand for video conferencing (VC) via the Internet has been grow-ing fast [38]. Even though video telephony has been around for over four decades it is inthe most recent decade that the public has come to appreciate the service as the costs de-crease and availability increases. VC services are currently provided as either utilizing a VCroom with professional high-end equipment and dedicated bandwidth or as an applicationon personal computers with simple web-cameras. The first category is usually expensiveand limited to a specific location, but guarantees quality. The second category on the otherhand is often cheap and easy to install and use, but without quality being guaranteed [38].The reasons to use video in communication applications have mainly been to support collab-oration between individuals or groups from different locations, and for friends and familiesto connect with each other over distance [17, 7].

From psychological and linguistic studies it is known that nonverbal behaviors fulfillmany functions in person-to-person communication. For example, the turn taking in aconversation is governed to a large extent by the gaze behavior and facial expressions ofthe interlocutors. Paralinguistic behaviors qualify spoken statements as ironic or humorous;doubt is expressed by frowning; body movements, such as shrugging, express indifference orhelplessness; and the positioning of the body toward or away from a person can express anattitude of openness or reserve [25].

Regardless of the fact that the technology is readily available, we still have poor un-derstanding of how VC systems are used by people and why it still has not become thesuccess that the market expected as early as 1970. This chapter attempts to highlight thepossibilities and limitations with video in communication applications from a cognitive andsociologically point of view, as well as list the factors that affect the Quality of Experience.

5.1 Background

Video conferencing uses telecommunications of audio and video to connect people for ameeting, in spite of physical separation. In its early days, video conferencing was usedmainly by American telecommunications company AT&T, for large corporate meetings. Thesuccess of the video teleconferencing meetings resulted in further development of a conceptinvented by Bell Labs in the 1920’s: Picturephone [7]. Executives had high expectations of

21

22 Chapter 5. Video Communication - Possibilities and Limitations

the Picturephone assuming it would become the household item of the decade, replacing thevoice telephone[18]. However, the project was a marketing flop. The reasons for its failurewere the hefty price and size. But also the fact that it was only useful for the purchaser ifhis or her friends or relatives also owned a videophone [7].

The general conclusion is that the first generation of video conferencing systems wasa failure. Nonetheless, by the end of the 20th century people started to embrace a sim-ilar technology, web-cameras. Web-cameras allow users to have video conversations overa personal computer. With an increased availability of cheap cameras, video conferencingservices based on free software began to flood the market.

5.2 Related workMost research on the subject focus on the design and network architecture of video con-ferencing systems as well as compression and streaming technologies. However, there hasbeen some studies on the factors contributing to the failure of early video conferencing[7]and also studies on how video communication can benefit collaboration between colleaguesworking at different locations [17].

Egido [7] ascribes the early failure of video conferencing to two factors. The first factoris the needs assessment methodology. The surveys to measure people’s attitude towardsan unknown product that they have never seen can produce questionable results[7]. Forexample, people may want a talking car (e.g.”your lights are on"), however when suchcars where introduced in the 80’s they were market failures[18]. The second factor is thequestionable portrayal to replicate face-to-face meetings without fully understanding thefunction of video. Video cannot replace face-to-face conversations as was originally intended,it can only be used to provide similar features[7].

5.2.1 Advantages

Isaacs and Tang [17] have made observations of engineers who were using a desktop videoconference system (DVC) to study the user interface implication of using video for remotecollaboration. They compared interactions through a DVC with face-to-face interactionsand phone conversations. The results show that compared to audio-only channels video hasthe following benefits[17]:

– Expressing understanding

– Forecasting responses

– Enhancing verbal descriptions without gestures

– Conveying purely non-verbal information

– Expressing attitudes in posture and facial expressions

– Managing pauses

The most common use of the visual channel is to show understanding and to some degreealso agreements by nodding the head while someone is speaking. According to Isaac, videoprovides an effortless and ongoing feedback channel which gives participants information ofeach other’s understanding. Without the video, the participants has to work harder to getmuch less information about each other’s understanding[17].

5.2. Related work 23

Another benefit is the possibility to use gestures to anticipate responses and enhanceverbal descriptions. Many people make gestures while talking on the phone, apparentlybecause it helps them express themselves verbally. Obviously it is impossible to perceivegestures over a voice-only channel. Therefore, participants have to explicitly express theirreactions verbally. This requires more effort, and so people may be more inclined to letsubtle problems pass. Seeing each other’s gestures is likely to increase the general level ofmutual understanding between participants, without requiring extra effort.

Further more, some gestures are not used only to anticipate reactions or to emphasizewords. Participants in Isaacs[17] survey occasionally responded solely with gestures, suchas shaking or nodding the head, smiling, looking confused, or other specific gestures. Thesegestures are a natural part of human-to-human interaction. Not only do these gesturesenable participants to perceive background information, for example another participantentering the room, but it also helps to express attitudes in posture and facial expression.We use facial expressions to indicate skepticism, surprise, amusement, confusion, convictionand so on. Even though occasions where the absence of non-verbal information has criticalimpact on the conversation are rare, it can easily lead to misunderstanding and confusionbetween participants. For example, a joke or sarcasm responded with silence and an unseensmile can easily be misinterpreted[17].

Finally, the visual feedback that video provides is effective to give explanation of pauses,which can be helpful in determining someone’s attention. For example if someone on theother end of the line is taking a pause to take notes or look for something, the participantwould not need to explicitly receive feedback of what that other person is doing to ensurethat the connection is still active.

In excess of the physical advantages with video conferencing such as gestures and facialexpressions, described by Isaacs and Tang[17], Judge and Neustaedter[19] highlights theimportance of video conferencing for families and friends to connect with each other over adistance.

People have a need to gain an awareness of remote families’ or close friends’ activities,locations and coordinate shared activities or simply feel close to others. Studies have alsoshown that people prefer in-the-moment sharing of information where sharing is directed atspecific people. However, they dislike feeling obligated to send information to others. Themode of interaction that people most prefer is face-to-face conversation. Therefore, if theyhave the opportunity and it is convenient, people prefer to talk to someone in person wherethey can both see and hear each other. [19]

Judge and Neustaedter’s study[19] showed that adults without children primarily usedvideo conferencing for conversation. Video link was used solely to watch the other per-son, their gestures, and body language. This augmented the voice/audio component ofthe conversation and was the main reason that these participants used video conferencing.Sometimes additional things pertinent to the conversation were shown such as a new poster,shirt, or furniture in the house. Secondly the study showed that for families with children,video conferencing was used primarily to share activities. Sharing activities and interactingthrough video conferencing helped the participants maintain a connection between familymembers, allowing grandparents to watch their grandchildren grow up for example and tomake sure their grandchildren knew them. These participants enjoyed the feeling of con-nectedness and awareness and did not mind being watched by their distant family. [19]


5.2.2 Limitations

Even though there are perceived advantages to video communication compared to audio-onlycommunication, the survey by Isaacs and Tang[17] reveals that compared with face-to-faceinteraction, video communication aggravates several aspects of interactions. Interactingremotely through video makes it difficult or impossible for participants to:

– Manage turn-taking

– Control the floor through body position and eye gaze

– Notice motion through peripheral vision

– Have side conversations

– Point at things in each other’s space

– Manipulate real-world objects

Videoconferencing reduces or removes the ability to regulate turn-taking, because ges-tures or other visual cues might be difficult to perceive. Isaacs and Tang [17] found thatparticipants did not exchange turns as frequently as in face-to-face interactions. Whichindicates that the participants are able to coordinate their utterance and reach mutualunderstanding to a higher degree when face-to-face.

Another important feature that is used frequently in face-to-face interactions is to useeye gaze to indicate to whom a person is speaking to. Eye gaze also helps in regulatingturn-taking. For example, if many persons are speaking at the same time, the next speakermight be determined by the eye gaze of the previous speaker. Gestures can also be usedto prevent others from taking the turn [17]. The issue with video conferencing is that it isdifficult to address information to a specific person in a multiway conference. As observedby both Isaacs [17] and Sellen [31], since everyone sees you through the same camera, itappears to everyone as if you are looking at them. Therefore, it is difficult to use words suchas ‘you’[18]. Most participants solve this unconsciously by using names instead[17]. Sincemost video conferencing systems have one shared channel for audio, it’s also impossiblefor participants to engage in side conversations (i.e. whispering with neighbors to clarifysomething), speaking to a specific person rather than to the general group.

A limitation within many VC systems is the size of the video window, which only coversa small part of the participant’s visual field. This disables the participant to use theirperipheral vision to notice a change in each other’s body, head or eye position and thereafterrespond appropriately by coordinating their own activity.

In face-to-face meetings, pointing is very common. For example pointing at objects,in other’s documents or at other participants. In conformity with eye gazing, pointing inVC is problematic, as it is difficult for other participants to figure out whom or what isbeing addressed. It is also not possible to manipulate real-world objects. Wether or notthis feature is of major importance to the meeting is however debatable, but to be able tobuild on other’s work or ”look over each other’s shoulder” can be meaningful to gain moreperspective [17].

In addition to the research by Sellen [31] and Isaacs [17], Jeffrey[18] argues that videoteleconferencing is disadvantageous for group collaboration. In his paper, he examines themain factors that contributes to positive group collaboration. These are: field of percep-tion, sense of presence, shared frame of reference and movement. According to Jeffrey, videodisrupts the opportunity for effective group collaboration within all of these areas. Field of

5.3. Summary and discussion 25

perception is one’s perceptual field of view that enables one to see objects in one’s periph-ery that are not directly being attended to. As also concluded by Isaacs[17], the limitedsize of the display visual in video communication disables the ability to recognize changesin body or head movements and therefore limiting the participant’s awareness. Sense ofpresence, highest when physically present, is the feeling of being part of a group. Sellen[31]found that participants did not feel a sense of presence while communicating over multi-uservideo communication systems. This contributes to aggravating the floor control. And asdescribed earlier, floor control is not as effective when interacting with video[17]. A sharedframe of reference occurs when individuals share the same physical space. The shared refer-ence provides conversational information about other individuals, such as "who am I lookingat?" and "who is looking at me?". Areas within the shared reference are turn taking, sideconversations and pointing, whose reasons for failure are explained previously. The lastfactor that is claimed by Jeffrey to contribute to good group collaboration, movement, is animportant part of conversation. With a video screen, three dimensional information is lostbecause the two dimensional video eliminates stereopsis, convergence (only one image avail-able) and movement parallax (changes in environment produced by independent movementof observer). Therefore, information necessary for discriminating objects and differentiatingthe movement of people is limited[18].

Another problem with video communication is the privacy concern. Privacy can bedefined in terms of three control modalities: solitude, confidentiality, and autonomy [4].Solitude can be violated if someone interrupts another at an inappropriate time, confiden-tiality is violated if someone sees things that are not intended to be revealed, and autonomyviolations occur when someone is unable to choose when and how she participates in anactivity[4]. By giving the user the possibility to disable the video link, the confidentialityissue can easily be overcome. Solitude and autonomy is however harder to regulate in somesystems. To prevent the solitude from being violated, the user must be able to define theircurrent state of availability and choose when they are accessible for video calling. Thisprevents them from being called at an appropriate time. By also restricting certain users tovideo call it is possible to regulate autonomy[19]. This is however difficult in systems suchas CloudCom, where the caller is unknown to the user.

5.3 Summary and discussionThe technology for video communication has been available for a long time. Yet, it is notuntil recently that we have come to appreciate its benefits. Early versions of the videotelephone is said to have failed as a result of poor knowledge of the market’s interests aswell as its unfavorable size and prize. It was also only useful for the purchaser if his or herfriends and family members also owned videophones. In the end, it was a vicious cycle, noone was buying it because no one else was buying it. Over the past years, the technology hasimproved substantially allowing the concept to take new forms. Globalism is likely to haveincreased the demand for good video conference systems as collaboration spans worldwideand travels are becoming a large expense for global companies and more focus is put onecological sustainability. Additionally, globalism has seemed to increase the amount of longdistance relations between friends and families. This is also likely to have increased thedemand for cheap video conferencing applications.

As an attempt to identify limitations and possibilities with video communication a lit-erature study was made.

Isaac and Tang[17] showed that compared with audio-only communication, video adds orimproves the ability to show understanding, forecast responses, give non-verbal information,


enhance verbal descriptions, manage pauses and express attitudes. Yet compared to face-to-face communication, it can be difficult in video interactions to notice peripheral cues,control the floor, have side conversations, point to things or manipulate real-world objects.Similar conclusions were drawn by Sellen[31], who also found that participants did not feela sense of presence while communicating over video communication systems.

Judge and Neustaedter[19] described the importance of video conferencing, used as atool for friends and families to connect with each other, despite a long distance relation.This category of users have a strong need to gather an awareness of relatives activities, andprivacy is more focused on autonomy and solitude - choosing when to connect and withwhom - as opposed to confidentiality, which seams to be the primary concern in a workplaceenvironment.

Jeffrey[18] argues that video teleconferencing is disadvantageous for group collaboration.The main reasons are that video disrupts the areas field of perception, sense of presence,shared frame of reference and movement, of which all are important for good collaboration.Jeffrey claims that although video provides visual information it is a problematic alternativeto face-to-face communication because it is restricted by design features such as image size,location of video camera and the audio availability. These design concerns create problemswith signals such as gaze and gestures essential for regulating the flow of conversation ingroup collaboration but easy to miss when not attending to that particular area on thescreen. What is needed is an alternative approach that removes that obstacles associatedwith video while maintaining the sense of ’being there’ currently present in face-to-faceconversations.

Peoples’ attitudes towards video communication will most certainly change as the tech-nology continues to improve. Many believe that as the technology gets included into popularcell phones the vicious cycle, where no one is using video because no one else is, will be bro-ken and people will start using video more frequently. Another possible solution to makevideo more interesting for families might be to design a more ubiquitous technology thatusers do not mind leaving on all the time to provide awareness information.

Behaviors will naturally differ between adults and children, who is likely to utilize theirown video conferencing routine. Video communication usage is also likely to vary acrosscultures and geographic regions.

Chapter 6

Guidelines for a SuccessfulBusiness Model in CloudCommunication

The Cloud Communication System has during its development grown from supporting asmall set of use-cases into a fully featured product, capable of hosting a wide array ofservices. The backbone of CloudCom, the WMS has many different features, one of whichis the ability to charge clients connected through the system with a solution called IPX. Theinteresting part of this solution is not the ability to pay for content or services, instead it ishow the payment is carried out that is interesting. With the help of IPX, a technology thatenables consumers to purchase content or services with the help of their mobile phones[9],the WMS charges the user prepaid mobile phone account or mobile phone bill instead ofcharging with more conventional methods as for example credit cards. With the help of theWMS this functionality gives an unique opportunity to create applications with businessmodels that are profitable not only for the administrators of the system, but also the actualend-users of the applications utilizing the WMS.

Trials with the system has been carried out for some time, most of them are commu-nication solutions where an A-party can contact a B-party anonymously. Communicationsolutions has since the creation of the WMS been a focal point, but recently other possibleuse cases has been found such as the ability to pay for content on the web with the help ofyour mobile phone.

The flexibility of the WMS makes room for many different types of usage scenarios andthus, several different types of business models are applicable. With the added support forvideo conversations even more possibilities should arise. The aim of this chapter is withregard to CloudCom find traits that affect the success of business models on the Internettoday. This was accomplished by performing a literature review, finding features that areimportant to consider in the creation of new business models.

For a large company as Ericsson a successful business model is important since they arenot likely to invest in development of new innovative applications if they will not generateany revenues[9].

27

28Chapter 6. Guidelines for a Successful Business Model in Cloud

Communication

6.1 Definitions of Business Model

Internet commerce has given rise to many new types of business models as well as reinventedsome old ones[29]. New information and communication technology is what has made thisdevelopment possible[36], and will probably keep precipitating the rise of new successfulbusiness models. But what exactly is a business model?

When reviewing literature about electronic commerce (e-commerce) there seems to belack of a unified definition of what the term business model actually means. Timmers definesit as an architecture for the flows between products, services as well as the business actorsand their roles. This together with a description of the benefits for the various businessactors and the sources of revenues are what together make up the business model[36].

A more simple definition was presented by Rappa. He defined a business model as"the method of doing business by which a company can sustain itself – that is, generaterevenue"[29]. The focus in his definition can be interpreted as how revenues actually aregenerated and collected.

Weill and Vitale gives a third more general definition where they define it as a descriptionof the roles and relationships between the stakeholders of a product. This refers to the flowsof money, information, and finally the benefits for the concerned parties[37].

These are just a few of the existing definitions and although they all have similaritiesthey also have some differences. To get an overview of the concept of business models Singhet al. [15] compared the different definitions found in the literature and identified 5 basicconstructs that were recurrent. These constructs were:

– Value creation

– Parties involved

– Revenue generation

– Links between parties

– Product/Service flows

Value creation is according to the study the most occurrent concept when defining busi-ness models[15]. Value creation refers to what use the product or service offered has and towhom. The perceived value of an product or service is according to Mahadevan[24] effectedby aspects as risk management, buying guides, quality assurance, security and trust to namea few. These should all be considered when you want to create a successful business model.Trust is a particularly interesting subject that we will get back to later.

Another frequently occurring concept is revenue generation. The revenue generationdescribes how income is collected and is perhaps a common interpretation of the termbusiness model.

When finding guidelines for successful business models with respect to CloudCom, fo-cus was put on the actual revenue generation/collection and the links between the partiesinvolved. In that sense the adopted the definition was most closely related to the one byRappa[29].

6.1.1 Existing Business models

One notion that is often occurring in the literature is the term value chains[36, 15, 29].Every business model can be broken down into value-chain elements and by recombining

6.2. Payment 29

how these elements are connected or where in the value chain your product or service fitsyou can create different types of business models. Rappa points out that different businessmodels can have different positions in the value chain[29]. Interaction patterns between theelements can also change the business model. There can be 1-to-1, 1-to-many or many-to-many relationships in a model. An electronic auction is an example of an 1-to-manyrelationship between the seller and buyers[36]. The possibility of combining, adding andremoving value chain elements in different ways yields a large number of possible businessmodels. Below is list of a few commonly used business models on the web[15].

– E-shops

– E-procurement

– E-auction

– E-mall

– 3rd party marketplace

– Value chain service providers

– Value chain integrators

– Collaboration platforms

– Information brokers

All of these models are of course not viable for CloudCom as a product, there are howevera few of them that are interesting and some that have been tested. Communities, valuechainservice providers, collaboration platforms and information brokerage are all interesting froma CloudCom point of view.

The existing trial that is running on the Ericsson Communication Network is an exam-ple of CloudCom adopting the collaboration platform business model. If the trial wouldbe migrated to a real product, revenues would be collected by managing or hosting theplatform in return for membership or usage fees, alternatively selling the entire product tolarger enterprises. Another model that has been tested is letting CloudCom act as a valuechain service provider. Together with a large blog portal Ericsson launched CloudCom as acommunications solution that enabled blog readers to contact blog owners without havingto disclose any sensitive information from either part. In this use case the blog owners wereable to charge people contacting them and revenues were generated by taking a percentage-based fee of these per-minute charges. CloudCom was in this use case put in the middle ofthe value chain between a buyer and a seller.

6.2 Payment

Since our interpretation of the business model is focused on how revenues are generated, an-other important aspect is how these revenues are actually collected. Paying for products andservices on the web is not as straightforward as in the real world[3]. A prerequisite for newsuccessful business models on the Internet is an efficient payment system that is welcomedby consumers[11]. Today, credit cards are the most commonly used payment method, eventhough people are having trust and security issues with this form of payment[3]. There have


Communication

however been a few new payment solutions introduced which focus on reduction of costs,improved transaction speed and increased security/anonymity for the customers[11].

The payment solution used by CloudCom is a Mobile Payment (MP) system. Since theWMS is built upon the use of MP, this type of payment service will probably also be usedin future business models for CloudCom. The focus of this part will therefore lie in findingimportant traits of a successful MP procedure.

6.2.1 Mobile PaymentsMP is a rather new concept but is growing fast, not only in the context of electronic com-merce but also in real world payment situations. There are several studies that have showedthat many consumers are willing to use their mobile device for payment purposes[28, 21].There is however a difference between willingness to use something and actually using it.Risks of failure are evident if a transformation from acceptance to actual usage of MP solu-tions is to become a reality. Consumer acceptance of MP was by Kreyer et al.[21] dividedinto three different groups of criteria:

Cost Concerning costs of usage, fixed costs and infrastructure.

Security Concerning integrity, authorization, confidentiality of the transactions.

Convenience Concerning ease of use, comfort and benefits of use.

These three groups are important to consider when creating a MP solution that is ac-cepted and used by the costumers of a product or service.

Pousttchi[28] made an empirical study further investigating what conditions that haveto be met in order to establish a general acceptance of MP solutions. The study wasconducted by letting a group of people rate a set of acceptance criteria extracted from thegroups above, this would according to the author give an overall picture of the relevance ofeach criteria. The study showed that confidentiality of data was the single most importantcriterion. Secondly, direct costs was also rated high by the participants. Lastly, convenienceissues were found to be of interest, in particular easy handling and fast processing were ratedhigh by the participants. Pousttchi means that the result of the study is highly relevant forcreating MP procedures that are easy to use and that will be accepted by the consumers[28].

6.2.2 Mobile Payment ProceduresWhat MP procedures are available then? Kreyer et al.[21] derived a number of standardMP solutions. The different solutions were grouped into: mobile money, premium ratenumber, conventional settlement and dual-card. The one used currently by CloudComis a special case of the premium rate number procedure. CloudCom is a communicationservice and the use-cases that today are utilizing a live business model, meaning that theyare generating revenues, all involve the users mobile phone. The choice of the premiumnumber model came natural for convenience reasons since the users are already engagingthe service with their phones. The upsides of the procedure is that settlement takes placeover an already existing billing relationship. A downside mentioned is that in some countrieslegal restrictions prohibits the payment of services other than telecommunication-coupledones[21].

An ideal procedure suitable for all types of MP situations is non-existing accordingto Kryer et al. Instead they suggest that a combination between several different typesare needed in order to meet the customers needs for convenience, security and acceptablecosts[22].

6.3. Trust and Business Models 31

6.3 Trust and Business Models

So far we have established what a business model is, investigated what business models areavailable, and looked at what influences the success of MP procedure such as the one usedby CloudCom. These are all important to understand in order to incorporate successfulbusiness models with CloudCom.

As mentioned in section 6.1 another concept that is important and that has been studiedextensively is the role that trust plays in the use of Internet applications, especially the onesthat require payment. Trust has proven to play a crucial role when people decide if anapplication is to be used or not[14, 16]. Thus it has significant effect regarding the successof any business model. Trust is characterized by human emotions as uncertainty, dependenceand vulnerability and these emotions are very much present in any online transaction whereconsumers cannot see or feel the merchandise or service being payed for[5]. In effect, onlinebusiness transactions require that customers trust what sellers provide and advertise andsellers must in turn be able to trust that the customers are able to pay for the products orservices provided. In a social sense, trust is about people acting in predictable ways. Konradet al. found that the level of trust that an application instills is approximately inverse tothe perceived risk of using the application[20].

Trust concerning e-commerce also has a few different interpretations. Garnison andSloman surveyed which role trust played in Internet applications and defined a trustworthyapplication as an entity that acts dependably, securely and reliably in the context of use[14].Gefen and Straub argue that a user’s trust is a consequence of trust in other people andthat the same principles applies for e-commerce. Trust should therefore according to theauthors be managed by an increased social presence in Internet applications[12].

6.3.1 Factors influencing trust

We have clearly established that trust is a factor that has major influence on the usage of anyInternet application[14, 20]. As mentioned in section 6.3 Konrad identified a relationshipbetween trust and and the amount of risk a consumer is willing to take[20]. Consequently,reducing the perceived risks of using any application should also increase the trustworthinessof it.

Risks assessments

Risks can be separated into several different categories. In an e-commerce perspectivethe ones people are mostly worried about are performance risks, financial risks and timerisks[5]. Performance risks are often that the service or product does not meet the customersexpectations. Financial risks concerns the customers belief that the product or service isavailable at a lower price, and finally the time risks regard customers worries about theproduct/service not being delivered in time. Corbitt et al.[5] studied consumer perceptionsof these types of risks. In contrary to what Konrad et al.[20] found, Corbitt et al. didnot find a linear relationship between perceived risk and degree of trust. The empiricalresults of the study revealed that the more experienced users are with the Internet themore they are likely to trust the technology. People can according to the authors trust andparticipate in e-commerce even though they see considerable risks. In this sense Corbitt etal. mean that the participation in e-commerce can not be explained obly by an approximaterelationship between trust and perceived risk, there are probably other influencing factorssuch as convenience and curiosity having significant effect on the level of trust[5].


Communication

Even though there is an inconsistency in the literature regarding the relationship betweentrust and perceived risks, the general conclusion is that lowering perceived risks increasesthe trustworthiness of e-commerce applications[5, 20]. Effective ways of relieving these riskfactors were identified by Tan[35]. He found that positive word of mouth, a positive brandimage and money-back warrantees had a positive effect regarding risk assessments. Thesesclaims were supported by Corbitt et al. who also acknowledge that cooperation with wellknown companies could be a way of enhancing these values[5].

Familiarity

Another factor found to influence the trustworthiness of an e-commerce application isfamiliarity[13]. Gefen studied the role that familiarity played in the context of e-commerceand used the definition of familiarity as an understanding based on previous interactionsand learning of why and how things behave in a certain way[13]. The study proved thatincreased trust could be achieved by increasing the familiarity of the product or service. Theauthor suggests that the simplest way of fulfilling this is through exposure and education, asopposed to repeated favorable interactions. Practically what this means is that e-commercepractitioners should strive to increase the recognition of their websites and put more moneyinto advertising in order to increase the level of trust users put in their businesses[13].

Privacy of information

Online experience is a notion that also has significance for trust. The more experiencedusers are with Internet use the more likely they are to trust the technology, which in turnsmeans that users are more likely to trust e-commerce applications in general. But growingInternet experience also has the effect that people become more concerned about privacy andsecurity, which has the opposite effect of lowering the trust people put in e-commerce[5, 16].

Hoffman et al. investigated privacy issues in online environments and found that thelack of trust in e-commerce comes from a consumer’s "perceived lack of control over theaccess others have to their personal information during the online navigation process"[16].The fear of secondary use of information is identified as a large contributing factor tothis lack of perceived control. Hoffman et al. suggests that in order tackle these issuesbusinesses have to recognize the user’s right to ownership of private data. Practically thisimplies opt-out polices concerning exchange of information and ideally opt-in consent policieswhere consumers are given choices how private data should be handled[16]. Corbitt etal. acknowledges these statements and expresses that customers privacy and data securityshould be protected and carefully mediated[5].

Other

Corbitt et al. found a few other factors effecting trust[5]. Site quality for one has influenceson the level of trust. Site quality is comprised of several different factors; Design, technicalaspects as well as usability can have impact on the trustworthiness of any e-commerceapplication.

Another one identified by Corbitt et al.[5] is the overall technical trustworthiness whichconcerns the reliability of the product or service. An effective and secure payment pro-cedure is something that can generate increased trust from a technical standpoint. Whatcharacterized such a payment procedure from a CloudCom point of view was investigatedin section 6.2.

6.4. Summary and Guidelines 33

6.4 Summary and GuidelinesIn an attempt to find traits of successful business models with respect to CloudCom aliterature review was conducted. The review revealed two distinctive features that areimportant to consider when integrating a business model with a product or service such asCloudCom. In section 6.2 we investigated how the payment procedure effects the businessmodel and in section 6.3 the issue of trust was described. It can be hard to pinpoint whatmakes some business models successful and others not. Perhaps sometimes the answer liesin the uniqueness of the concept itself and as mentioned earlier, new prosperous businessmodels are still emerging on the Internet every day (see section 6.1). The features foundin this study are by no means prerequisites but they have helped explain the success ofsome business models and are a reflection of consumer attitudes towards e-commerce. Thisstatement is based on the fact that many of the reviewed studies were empirical.

The following traits have been identified as important in order to support business mod-els that have greater chance of becoming commercially viable and endorsed by potentialcustomers. According to the literature these should all be taken into consideration whenincorporating new business models for products or services like CloudCom:

Effective payment procerdure A reliable and secure online payment procedure is of highimportance for any business model. From a consumer perspective, such a paymentprocedure should:

1. Be of low cost.

2. Respect privacy of personal data.

3. Be secure and reliable.

4. Be convenient and easy to use.

Increased trustworthiness Trust is fundamental for every business transaction. In anonline environment it becomes even more of an issue. Increasing the amount of trustconsumers put in your application is therefore vital for the business model. This canbe achieved by reducing risks and taking precautions as:

1. Creating a positive word of mouth.

2. Provide money back warrantees.

3. Increasing familiarity with product/service through for example marketing ef-forts.

4. Recognize user’s ownership of private data.

5. Increasing site quality through usable design.

6.5 Discussion and LimitationsResearch about e-commerce and successful enterprising on the Internet is of great interestfor both consumers and companies. For consumers it will yield a better, safer and moreconvenient buying experiences while the companies will attract more customers to theirproducts and services. The aim of this literature review was to find features important forthe success of these business models.

The proposed design guidelines were however developed with CloudCom in mind and allof the guidelines do perhaps not apply in a general e-commerce perspective. The guidelines


Communication

do not reflect on all factors influencing business models and there are probably many othervariables important to consider. Nevertheless, the result of the study can be used to improvethe business models already used by CloudCom or can be used when integrating new oneswith the system.

Chapter 7

Design

This chapter will describe the design process and the different design proposals that werecreated for the desktop and web clients. Some theoretical guidelines used for evaluating andcomparing the different proposals are presented and the final concept is presented.

7.1 Theoretical foundationWhen designing a graphical user interface (GUI) there are many choices to be made. Choicesregarding structure, feedback, constraints and metaphors are just a few concepts to considerthat all have an effect on the usability of applications. In the concept stage of designingany application, keeping all these choices in mind can impede creativity. In order to tacklethis problem a number of concepts were created without considering usability issues anddesign choices. These concepts where then compared using guidelines found in the literatureregarding user interface design. In the following sections these guidelines are presented.

7.1.1 Shneiderman’s Eight Golden Rules of Interface DesignBen Shneiderman proposed the following collection of principles to follow in order to improvethe usability of an application[33]. These interaction design patterns where derived fromheuristic evalutation and can be applied to most software interface designs. Each rule ispresented with an interpretation of its meaning.

Strive for consistency Means that similar sequences of actions should be applied in sim-ilar situations. Similar terminology in menus and prompts are two examples of in-creasing the consistency of an application.

Enable frequent users to take shortcuts Reducing the number of interactions and in-creasing the pace of the interaction for frequent users can contribute to a positive userexperience.

Offer informative feedback Every user action should be accompanied by some feedbackfrom the application. Small and frequent operations should yield modest feedbackwhile major actions should yield more substantial feedback.

Design dialog to yield closure Sequences of action should be separated into a beginning,middle and end. This gives user a sense of relief when a sequence is completed andsignals the user to prepare for the next sequence.

35

36 Chapter 7. Design

Offer simple error handling The simplest way is to design applications that do not per-mit the user of making an error. If an error is made, simple mechanisms for handlingthe error should be provided.

Permit easy reversal of actions Supplying users with means of reversing actions cangreatly reduce the anxiety of using the application. It also encourages exploration ofthe different functions and option in an application.

Support internal locus of control Giving experienced users the sense of them being incontrol of the application and not the other way around has proved to be important.Designing applications where the user is the initiator of action is crucial for achievingthis.

Reduce short-term memory load To reduce risks of information overload and stress ona user’s short-term memory applications should keep displays simple, split up infor-mation onto several pages and reduce window-motion frequency.

7.1.2 Norman’s design principles

In his book "The Design of Everyday Things" Donald Norman proposes guidelines for im-proving the usability of artifacts in general. These guideline are also applicable for softwareartifacts. According to Norman artifacts should be designed with the following propertiesin mind[27]:

Visibility The visibility of features are important since it makes it more likely that userswill find and use them.

Feedback Similar to Shneiderman, Norman expresses the importance of providing feedbackfor every action. Norman exemplifies different types of feedback such as auditory,visual, tactile and verbal feedback. The first two mentioned are the ones most oftenused in the design of software artifacts.

Constraints Restricting the ways in which users can interact with the artifact at anyparticular moment was identified to be of importance.

Mapping Relates to the relationship between controls and the effect these controls haveon the artifact. Mapping this relationship in a comprehensible manner will hinder theuser from making mistakes. In a software context, an example of good mapping is theup and down arrow on the scrollbar of your browser window.

Consistency Norman also identified the importance of designing interfaces that have sim-ilar operations for achieving similar tasks.

Affordance This term refers to attributes of an object that allows the users to know howto interact with it. Affordance is perhaps best used to explain usability propertiesof physical objects. But these physical properties can also be transferred to softwareartifacts. A graphical button could for example invite pushing as much as a physicalbutton.

7.2. Requirements 37

7.2 RequirementsAs mentioned in section 4.3 the first step of the design process is establishing requirementsfor the applications. Finding these requirements was not particularly hard since the videouse-case only was an extension of already existing use-cases. Instead focus was put onrefining the use-cases and adding small features that would enhance the user experience.The following requirements were found important when adding video conversation supportto CloudCom.

– The A-party should be able choose video or voice call.

– The A and B-party should be able to see both themselves and the other party duringa video conversation

– A and B-party should be able to enable and disable the video stream during a videoconversation.

– A and B-party should be able to mute and un-mute speakers.

– A and B-party should should be able to mute and un-mute mic.

These requirements were the initial core requirements that were identified. During thedevelopment process more features were added. There are of course many more obviousrequirements such as user should be able to hang up, etc, but those requirements are eitherself-explanatory or an extension of use-cases already in use. Those requirements are thereforenot presented.

7.3 Concepts and MockupsWith the requirements established, the process of designing the structure and flow of theapplications began. The initial sketches were created in small workshops and drawn onwhiteboards. Some of the whiteboard sketches were selected and then drawn on paper tofurther develop the concepts. From these a few designs were selected and drawn digitallywith Omnigraffle. The digital mock-ups were then used to compare the designs with respectto the guidelines in section 7.1. The guidelines were consulted recurrently during the wholeselection process, from whiteboard sketches to digital mockups. The following sections willdescribe some of these mockups.

7.3.1 Web ClientIn the last step of the selection process there were 5 different concepts left to choose from.A tab-bar concept, a page-flip concept, a speech bubble concept, a business card conceptand finally a knob concept. Mockups of these concepts can be seen in appendix C. Thedifferent mockups aimed to describe different navigational structures for the web client andto help determine which one that best suited the CloudCom project.

The first concept was a plain and simple tab-bar concept where the B-party’s informationand picture is placed on top of of a tab-bar menu where the A-party can choose from differentcommunication channels. A few different versions of this concept were created. In figureC.1 a spacious version of this concept is displayed. In figure C.2 a more compact versionof the same design is shown and lastly figure C.3 shows an alternate design where theinformation section is hidden when tabs are displayed. The tab-bar concept felt simple and


straightforward. At the same time it felt boring and plain. There is no obvious connectionbetween communication and the design of the widget and tab-bars are commonly used inapplications. Creating a design that easily could be extended with new features was alsoprioritized. This together with maintaining a small form factor made the use of a horizontaltab-bar impractical. Tab-bars do provide good feedback and great visibility of features butthis was not enough to motivate the use of a horizontal tab-bar in the web client.

The second concept which figure C.4 illustrates was based on the idea of having paperslying on top of each other. Each paper represented different steps in the application andnavigating between them would curl the papers out and in of view. Graphically this wouldhave been a nice concept, usability-wise perhaps not. The proposed concept would render adeep navigation tree and provide low visibility of features. These properties made it a lesssuitable candidate for the web client.

The third concept used a button and speech bubble layout (see figure C.5). Navigation-ally this concept was much like the tab-bar concept and thus poses the same problems. Thisconcept was therefore also dismissed.

The fourth concept consisted of a draw-down curtain and a knob. A mockup of theconcept can be viewed in figure C.7. The use of a knob for choosing communication chan-nel would perhaps have worked best with other input devices such as touch screens thanwith regular mouse pointers. Hiding the knob with a curtain was an attempt to make theapplication feel smaller and more "widget-like". This at the cost of visibility of the featuresand more clicks. The knob concept did at first feel fresh and innovative but because of thementioned shortcomings this design was also out ruled.

The fifth and final concept was the idea of creating a sort of virtual business cardwhere the B-party instead of providing different types of contact information provided directcontact channels. This concept was the one that in the end was chosen for the web-client.First of all it had strong correlation with communication since it mimicked a business carddesign-wise. The present GUI used in the ECN-trial focused on telephony and was not veryconsistent in the navigation between the different features. With a growing list of featuresnot all involving making actual phone calls a more consistent navigation and structurewas needed. The Business card concept provided a solution to this by use of a uniformvertical menu where the similar communications channels were grouped under three differentcategories. Since the menu was laid out vertically, extending the application with more menuchoices and at the same time keeping a small form factor was possible. Switching betweendifferent menu choices and always having an overview of the features would be easy toaccomplish and the structure provided easy and effective ways of constraining the user.These where the main arguments for basing the application on the business card concept.Figure 7.1 shows the final concept and more mockups can be viewed in figure C.6 in theappendix.

7.3.2 Desktop Client

Creating a concept for the desktop client proved to be much simpler than with the webclient. The desktop client was a much more simple application. The client basically providesa way to login in to the WMS, display call notifications, receive voice calls and change somesettings. There are not many choices or use-cases for the B-party to explore and the existingapplication did a good job of supporting those use-cases. Therefore the new desktop clientadopted the same structure and flow as the old one. A small mockup of the client with theadded video support can be seen in figure 7.2. Since the application already had a goodstructure, focus during the design phase was to generate better feedback in the application

7.3. Concepts and Mockups 39

and to improve the look and feel.

Hannes WikströmInteraction designer@work

Figure 7.1: The final concept chosen for the web client.

Incoming callAnswer? Yes No

User name:

Password:

Login

Disconnect

Call 10:13

Video

Figure 7.2: A simple mockup of the desktop client.

Chapter 8

Results

This section presents the results of the thesis. It begins with describing the architectureof the system and visualizes how parts of the system interact with each other. Then thetwo implemented applications are presented and their features are described. Further on,some results from a functional test are shown and finally, the results of the evaluation arepresented.

8.1 System Architecture

As stated in chapter 2, the previous version of the system consisted of two client parts andone server part. This thesis project has not added or removed parts from that setup, butrather it has modified individual sections. An abstraction of the current architecture of thesystem can be seen in figure 8.1.

The server is composed of Ericsson’s Widget Management System, a Red5 server and anAsterisk IP telephony switchboard. The WMS is the core of the system as it connects thepresentation layer with business logics and database. It also provides various plugins thatenables the presentation layer to communicate with external systems to handle charging forexample. The WMS is explained in more detail in section 2.1.3

Each registered user in the Widget Management System is allocated a unique key. Thiskey is referred to as wuuid, widget user unique identifier. With this key, it is possible tofetch information of the owner of the widget from the WMS.

Upon initialization, the web application speaks with the WMS, using the wuuid toget information about the widget owner. The data is returned as an XML and containsinformation with name, phone number, email, department etc. It also contains an addressand login data to the Red5 media server. The web client then connects to the Red5 server.The desktop application also connects to the WMS upon user log in, to verify that the emailand password are correct. If the connection is successful the desktop application receivesthe login data to the Red5 server.

Using the information gained from the WMS, it is possible for the web client and desk-top client to establish a mutual connection on the Red5 server in order to communicate.Additionally, a server application is installed on the Red5 server, called Red5Phone. Thisapplication enables VoIP calls to the public switched telephone network (PSTN). This isdone by routing the call to the Asterisk, which subsequently reroutes the call to the PSTN.

41

42 Chapter 8. Results

CLOUDCOM WMS

CloudCom - server side

Widget Managment System

Red5 Media server

Asterisk Call routing

Web application Adobe Flash

Desktop application Adobe AIR

plugins

Figure 8.1: System overview

Figure 8.2 visualizes how a video call between A- and B-part is performed. A-partyaccesses the B-party’s widget and receives the information about the user as well as theaddress to the Red5 server from the WMS. A-party attempts to make a video call to B-party, so the client invokes a function on the Red5 server. If B-party’s desktop applicationis running and B-party is available, Red5 then subsequently dispatches an event in thedesktop client, which will basically display a call notification window to make B-party awareof an incoming call. B-party can then choose to accept or decline the call. The answer isreturned to Red5 which notifies A-party that the call is either connected or declined. IfB-party accepts the call, both A- and B-party initializes two media streams each to Red5,one outgoing stream, with video and audio attached and one incoming stream, acquiringthe media broadcasted by the other part. The video streams are encoded with an RMTPTprotocol. In addition to the streams, a SharedObject, unique for the conversation is created.The SharedObject is a mutual file on the Red5 server from which both parts can read andwrite data to perform modest communication. It is for example used for each part to getknowledge of wether or not the other part has the video toggled on. The conversation willcontinue until one part hangs up the call. The other part will then be notified through Red5the same way as when the conversation was connected and both parts detaches the videoand audio from the streams and closes them.

If B-party is unavailable when A-party makes the call, the Red5Phone extension will askWMS to forward the call to the Asterisk application using session initiation protocol (SIP).Asterisk will then reroute the call to the PSTN and the B-party’s regular phone number.If B-party answers the phone, the call will be connected, otherwise A-party will be notifiedthat B-party is occupied. It is currently only possible to make voice calls via Red5Phone,so if A-party makes a video call to B-party and the call gets rerouted to the PSTN, the callwill be voice only.

8.2. Prototype Video Integration 43

If a third user, C-party, attempts to call B-party a request will be sent to Red5. Theserver application will then do a lookup to see if B-party is available and discovers that B-party is currently participating in a call session. Red5 forwards the information to C-partywhich gets a notification that B-party is occupied.

Pho

ne

SharedObject

SharedObject

SharedObject

SharedObject

Red5 media server

Asterisk

Audio/Video

Handshake

Audio/Video

Handshake

Handshake

1

A-party

B-party

C-party

B-party(phone)

2

34

5

SIP

Figure 8.2: Call overview

8.2 Prototype Video Integration

The initial goal of this thesis was to integrate video communication into the existing Cloud-Com application that was running as a trial on the ECN. This proved to be a good way tostart the project as we could test if video communication was compatible with the currentback-end, without having to build the entire front-end.

The result turned out more as a prototype for video communication, rather than a func-tional application. Yet, it supplied us with deeper understanding for further development.


Figure 8.3 and 8.4 show the web and desktop applications with the video feature imple-mented. The interfaces are close to the same as the existing versions with the addition thatthe user can enable and disable video while in a conversation. The video display is shownupon a successful call, it contains the incoming and outgoing video stream.

As this was more of a proof of concept to test the technical setup, no resources wereallocated to improve user experience and usability or to make it aesthetically satisfying.

Figure 8.3: Video integration in the existing web application

Figure 8.4: Video integration in the existing desktop application

8.3. Web Application 45

8.3 Web Application

From the mock-up phase the work evolved, focusing on realizing the business card con-cept that was considered superior (See section 7.3). The graphics were made in Illustrator,the animations and component definitions in Catalyst and all the functionality was imple-mented in Flash Builder. This section presents the redesigned web application and its newfunctionalities.

Figure 8.5 shows the initial screen of the application. Information of the widget-ownersname, title and department is gathered from the Widget Management System and is dis-played in the center of what is referred to as the cover pane, in the interface. The applicationdoes a lookup to the WMS to see whether or not the B-party has uploaded an avatar (profilepicture). If so, the image will be loaded and displayed, otherwise a default image will beused instead. On the left side are three buttons, where each button represents a way ofcommunication; message, video and voice. Initially the buttons are disabled until the ap-plication has successfully established a connection to the WMS to constraint the user frommaking errors. If the application manages to connect to the WMS but fails to connect tothe Red5 server, the message button will become enabled while the two other buttons staydisabled. This is because all messaging functionality is handled by the WMS only and therehave been cases when the Red5 server has been temporarily unavailable upon login. To pro-vide the user with feedback while attempting to connect to the server, an informational textis displayed describing the applications current state. This is important as an applicationin what could appear as a "frozen" state could be experienced as very frustrating to theuser. If something fails during the connecting phase, the user gets notified and an icon willbe displayed. When the application successfully connects to both the WMS and the Red5server, the menu buttons will become enabled. When the buttons are enabled its appearancechanges, to enhance the impression that it is clickable. The menu buttons can be classified

Figure 8.5: Initial screen of the new interface

as radio-buttons, as they have the same behavior. They have five states: enabled, disabled,mouse-over, mouse-down and selected, each with a unique appearance. Selecting one of thebuttons will deselect the other buttons. Clicking one of the menu buttons will animate thecover pane to invisibility, unveiling the interface for the chosen mode of communication.


8.3.1 MessageThe first communication mode is messaging. Figure 8.6 shows the message-interface, reachedby clicking the message button. This section provides three types of message: Email, SMSand SMS2Go. The type of message is selected in the toggle bar on top of the screen. Email isset as default. The SMS section and the email section have practically the same appearancewith mandatory fields for name, email and message and buttons to cancel and send message.The main difference between the two interfaces is that the user gets feedback on the currentlength of the message in the SMS-section. This is because an SMS can be no longer than160 letters. If the message exceeds that length, the informational text specifying the lengthwill become red and the send button will become disabled. Additionally, it is not possible tosend a blank message, so if the name field or message field are left empty, the send buttonwill stay disabled. Another feature to enlighten the user of the importance of correct inputsand prevent the user from making errors is email validation. The focus ring of the emailfield will become red and an informational label will be displayed if the email field is eitherleft blank or formatted incorrectly. When the name and message fields are valid, the sendbutton will become enabled. If the user clicks the button, an animation of the process willbe displayed to describe that message is being sent. When the message is successfully sent,the user will be notified briefly and the input fields will be cleared. If the message by somereason could not be sent, for example if connection was lost during the process, the userwill get a message that the process failed and what the possible cause could be.

Figure 8.6: The message interface of the application

The third method to send messages is through SMS2Go. This method lets the user set


up an SMS conversation between their mobile phone and the B-part’s phone. The userenters her phone number and clicks the start button. The system will then send an SMS tothe user with the message "Reply to this message to send your sms to the widget owner".If the user replies to the SMS, it will be forwarded to the widget owner, and an anonymousSMS conversation will be initiated between the two parties. The graphical interface differssomewhat from the other message types. The difference is that it has a list of countrieswhich defines the country code and a field for the user’s telephone number, see figure 8.7,and the button to process has a different label, "Start". The input field for the telephonenumber only accepts numbers and the sign "-", to prevent the user from making incorrectentries. As the text input is mandatory, the Start button will be disabled until the requiredfield has values. Upon click, the conversation will be initiated and the process animation isdisplayed.

Figure 8.7: SMS2Go interface

8.3.2 Video

The second mode of communication is video call. The initial screen for video communicationcontains a toggle bar with two choices: web and mobile (see figure 8.8). The idea is thatit should be possible to make a video call either through the web, to the widget owner’sdesktop client, or to the widget owner’s mobile phone. Currently, video communication fromthe web client to B party’s mobile phone is not implemented, so selecting the mobile choicewill disable the call button. This might not be optimal from a user perspective, this featuremight however be implemented in future versions of the system and is therefore includedin the interface. If the user selects the web choice and clicks the call button, the video callwill be initiated and an animation to represent the call process is displayed. The pictureshown in figure 8.9 illustrates this. The user can abort the call at any time by clicking thered button with a cross. The process will initially call B-party’s desktop client, but if it isunsuccessful to establish a call within 15 seconds it will forward the call to the B-party’s


mobile phone. As video communication to the mobile phone is currently unsupported, thecall forwarded will only be voice. Yet, as stated previously future versions might supportvideo to mobile phone.

Figure 8.8: The video type selection screen

Figure 8.9: The calling screen

If B-party answers through the desktop application, the video communication interfaceshown in figure 8.10 will be displayed. If both A-party and B-party have their video streamactivated, the screen will contain one video display for the outgoing video stream, positionedin the top-left corner, and one video display for the incoming display. Below the videodisplays is a setting bar with options to customize the conversation. The settings barcontains one button to activate or deactivate the own video stream and two buttons tomute the incoming and outgoing sound, it also has a timer which presents how long theconversation has been active and a button to hang up the call. If the user deactivates thevideo stream and the incoming video steam is active, the video display of the own videostream will fade out. If the incoming video stream from B-party becomes inactive and theoutgoing video stream is active, the display for outgoing video will be animated to full size.If both parties video streams are inactive, no video display will be visible and the interfacewill look the same as when in a voice call, figure 8.11.


Figure 8.10: Interface for video call

Figure 8.11: Interface for voice call

Evaluating the web client one can see that much of the interaction has been designed tofollow the guidelines in section 7.1. The entire client has an easy and consistent navigationmenu which gives a good visibility of features and that is almost always accessible. The callprocedure is designed to give the user a sense of always being in control and to yield closurewith a beginning step where the user selects communication channel (figure 8.9), a middlestep where the call is connected (figure 8.9) and final step where the call is connected orother feedback is given (figure 8.10). During this whole procedure the user is provided withmeans to easily reverse their actions. When a call is connected the interface constrains theuser by limiting the ways in which the user can interact with the client by restricting access


to other features. Feedback is given when an action has been performed or if the user hasmade a mistake. These are just some of the ways where the client has adapted to follow theguidelines.

8.3.3 Voice

The final communication mode is voice call. The interface is nearly the same as for making avideo call. The difference is that the voice section has an additional feature called Call2Go,in the call type selection screen. This call type allows the user to set up regular phone callsfrom the computer. This feature and SMS2Go are very similar to one another, with thedifference that one is for phone calls and the other is for SMS. The user enters her phonenumber and clicks the call button. The system will then make a call to the specified numberwith a voice prompt that supplies the user with further information about how the call isperformed. If the user accepts the terms of the call, the system will call the widget ownerwith a similar voice prompt asking him to accept the call. If the call is accepted the callbetween the two participants will be connected.

Figure 8.12: Interface for Call2Go

The other type of voice call is web, which basically is a VoIP call. Performing a voicecall over web is done by the same steps as for a video call: type of call selection, callingscreen and the voice or video call screen. The main difference is that when the widget owneranswers the call, the voice call interface will be shown, without containers for video displays,presented in figure 8.11. The toggle button for video in the settings bar will also be disabled,as it should not be possible to activate video if voice was selected as the communicationmode.

8.4. Desktop Application 51

8.4 Desktop ApplicationThe final desktop client was redesigned to resemble the look and feel of the web client andto support some new features that were added. As mentioned earlier the basic structureand navigation of the client was left untouched compared to the previous version. Thecolor scheme that was selected for the client was a combination of blacks and grays withblue color highlights. This gave a nice contrast from the earlier version and a nice modernfeel. There are also two other major differences compared with the previous version. Firstthere is the added transitions between the different states of the application. These are nowanimated giving the application a more seamless flow. The other difference is that the clientis running without a window or system chrome. This was motivated by that it simply looksnicer and gives the client more of a "widget-feel". The following sections give an overviewof the desktop client and describes the different parts.

8.4.1 Login procedureThe login window is the first window that the users see when they start the application.There are two input boxes, one for the username and one for the password. There are alsotwo checkboxes where the user can choose to save the login credentials or automatically login to the application. Figure 8.13 shows the login screen of the desktop client. If the userchecks the log-in-automatically box the application automatically logs in with the savedcredentials upon start up.

When the user logs in, the login window animates to another state where a progressspinner is displayed while the client is establishing contact with the WMS. Depending onthe success of the login attempt the client then transfers into a state showing that the userhas successfully logged in (see figure 8.14) or a state showing that the login attempt failedgiving the user a link back to the login window. If the user closes the client with the closebutton at the top right corner before the application has logged in it quits the client. If thebutton is pressed after login the window simply closes but the application continues to runin the background.

8.4.2 Incoming call procedureWhen the login process is completed the application continues running in the backgroundwaiting for incoming calls from the web client. If there is an incoming call a ringtone isplayed and a notification is displayed in the lower right corner of the users desktop. Thenotification asks the user to answer or dismiss the call. Figure 8.15 shows the notificationwindow. When the user accepts the call the notification is faded out and a new windowappears. Depending if the A-party has enabled video or not different windows are displayed.Figure 8.16 shows the window during a video conversation. The application provides similaroptions as the web client. The user can mute and un-mute the speakers and the mic duringa call. The user can also toggle the video stream being sent to the A-party. There are acouple of different scenarios for toggling video on and off. If the user stops sending video tothe A-party the small display at the top left corner fades out and the window only showsthe A-party. If the A-party at the same time disables the video stream sent to the user thedisplay showing the A-party disappears and the window showed in figure 8.17 appears. Thelast scenario is that the user has the video stream enabled and the A-party disables theirvideo stream. What happens then is that the small display showing the user scales up tocover the big display where the stream from the A-party was displayed. In effect you onlysee yourself. If the users gets an incoming voice call the toggle video button gets disabled


Figure 8.13: The login screen of the desktop client.

and the window in figure 8.17 is displayed. Except for displaying video the call windowalso shows the elapsed time of the call and has a button for ending the call. Comparedwith the old desktop client this is where most changes have been made. The added videofunctionality is obvious and as mentioned, controls for handling the sound were added.

Figure 8.15: The notification displayed during an incoming call from the web client.

8.4. Desktop Application 53

Figure 8.14: Screen showed when log in to the WMS is successful.

Figure 8.17: The call window when video is disabled on both ends

8.4.3 SettingsThere is one final task that users of the client can perform and that is to change somesettings with help of a settings window. If users right-click the icon in the dock or systemtray there is an option that says settings. If the user clicks this option a settings windowappears giving the user some configuration options. Figure 8.18 shows the settings windowof the desktop client. The window provides users means of changing the ringtone of theapplication, options to automatically log in and save the login credentials and to change theserver to which the client is connecting. One feature was added compared to the old client


Figure 8.16: The call window during a video conversation

and that is the ability to also listen to the selected ringtone.

8.5 System testing

During the development of the clients an increased possibility of launching the new clientsalong with the new features as an update of the existing ECN-trial became evident. Com-pared with just developing a concept this meant that extensive testing of the clients wascalled for. After the two clients had been implemented and the integration of the web clientwith the WMS was completed, testing was needed to verify the functionality of the newas well as the old features. Ensuring that the applications do what they are supposed todo and what they are not supposed to do are the key reason for testing an application. Inmost software projects today, 50 percent of the elapsed time and more than 50 percent ofthe total expenses comes from testing applications.[26]. Although the aim of these clientsonly was to be released as a beta-trial which also is a form of testing, these facts stressedthe significance of testing the two clients.

There are a lot different test strategies used in different projects and testing can bedivided into several stages during development[6]. There is unit testing where a small partof the program is tested individually by the programmer that implemented the feature.During the thesis project this kind of testing was done continuously in the developmentstage. There is integration testing where testing of subsystems are done, subsystems that

8.6. Evaluation 55

Figure 8.18: The settings window for the desktop client

consists of several units. This kind of testing was primarily performed during the integrationof the web client with the WMS and Red5. Finally there is system testing which is testingwith all involved subsystems. This kind of end-to-end testing was done when all the existingcomponents where implemented and integrated with each other. The ways in which youcan approach testing in the different stages are many. In the first two stages no particularmethod was used but in the last system testing phase a function test specification thatwas used in earlier versions of the CloudCom system was reused and expanded for the newuse-cases. The test specification gave a nice description on how to test different featuresand behaviors in the system and how the different builds performed on the various test.The entire test specification and the results will not be accounted for in this report. Thetest specification did reveal some issues that easily were fixed and some that have not quitebeen resolved yet. These issues are discussed in section 9.2.

8.6 Evaluation

As has been concluded earlier, evaluation is a critical part of the design process. Throughoutthis thesis, internal evaluations have been carried out continuously to refine parts of thesystem, for example when applying guidelines on mockups to choose one superior concept.However, before a product can be released it should be evaluated using the possible endusers as a test subjects. Unfortunately, due to lack of time, confidentiality and the failureto find suitable subjects, the only evaluation with external participants carried out wasthrough a workshop.


8.6.1 Workshop

The participants of the workshop consisted of six employees at Ericsson with various skillsand backgrounds. During the workshop, the participants received a presentation of theredesigned applications and were asked to reflect over anything that caused confusion orwas particularly good. To further generate discussion between the participants, a numberof topics were brought up. These topics could for example be "Are the icons easy to under-stand?" or "Is the informational text sufficient?". Which subsequently lead the participantsinto new topics for discussion.

As one of the authors lead the discussion and demonstrated the applications, the otherauthor acted as a secretary, taking notes of what the participants said and did. The result ofthe workshop was very valuable feedback. The most important reflections by the participantsare listed below:

Desktop client

– The name of the application, which is visible on OS X is currently Cloud Communi-cation Desktop Client. This should preferably be changed to just being Cloud Com-munication, as the term "Desktop Client" is unknown to the end-user.

– One participant states that it is superfluous to have two checkboxes for "Save pass-word" and "Log in automatically", it could for example be enough to just have acheckbox for "Log in automatically" or "Remember me". Another participant how-ever believes that this is standard and should not be changed.

– The password shown in the password field is the hashed password and not the actualpassword set by the user. The hashed password is very long. To increase usability, alltext could be selected if the user clicks the password field.

– It is hard to navigate to the "Forgot password" link, which is currently positionedin the Configuration window. One solution could be to place a link with "Forgotpassword" title on the Log in screen.

– The users expects something more to happen after successfully being logged in andclicking "Ok". Currently, no more feedback is available and the application is onlyvisible in the system tray (Windows) or in the dock (Mac OS X). To increase theuser’s awareness, further information such as "the application is now running in thebackground" could be displayed.

– The prompt displayed when there is an incoming call should display whether the callis video or voice. And the user should also have the possibility to choose whether toanswer with or without video.

– Some participants agreed that there is not enough feedback for person A when personB toggles off the video. At the moment, person B’s video display fades out and personA’s video display becomes fullscreen. One solution could be to display a cross overthe incoming video display when it is toggled off. And give person A the possibilityto set the outgoing video display to fullscreen.

– In the settings window, there is no "Cancel" or "Reset" option. The user’s only optionsare to press "Save and Close" or the cross-icon in the top right corner, which both dothe same thing.

8.6. Evaluation 57

Web client

– When a message is successfully sent the icon disappears rather quickly. If the icon isvisible until the user clicks on anything the user would most likely perceive the iconand understand that the message has been sent.

– If possible - use cookies to save email and name in text fields for future sessions.

– In the error prompt, the word "error" is too strong in the context where only the emailaddress is invalid. "Invalid input" would be a better title for the prompt, rather than"Input error". Also, having a blue Ok-button would make the prompt more consistentwith the application

– Some participants argues that the feedback which the user gets when an SMS is toolong, is not enough. To use a countdown for the message length could make it moreobvious. Another feature could be to make the focus rectangle of the message textarea red if the message is too long.

– The "connecting" / "connected" labels in the process that sets up an SMS-conversationis perhaps not the best way to describe the process. More appropriate texts could be"starting conversation" / "conversation started", or to just use the same texts as foremail and sms, i.e. "sending".

– The information text in SMS2Go is insufficient and might not be explanatory enough.It could become easier to understand if the widget owner’s name is used instead ofjust referring to him / her as "the user".

– The information texts "Select type of video" and "Select type of call" should bechanged to "Select type of video call" and "Select type of voice call" to make themmore descriptive.

– It should be stated that the mobile video service is not implemented, rather than justmaking the call button disabled, since this could be confusing.

– The overall information about Call2Go as well as mobile video call is insufficient, andthe user has to click on the Call2Go-button to get information about the service. Andsince the term Call2Go is unknown to the user initially, the user might be afraid toclick on the button and therefore never gets the information. One solution could beto include an information-button which overlays the interface with descriptions.

In addition to these subjects, there were also a few misspellings and inconsistent use ofcapital letters and dots after sentences that the participants reacted on.

In excess of the reflections over confusing details and suggestions for improvements,the overall design impression was described with words such as: clean, consistent, simpleand good looking. All participants who had experience from the previous version of theapplications agreed that the redesign was a great improvement and that it looked and feltbetter than its predecessor.

Chapter 9

Conclusions and Discussions

This master thesis was carried out with the goal to redesign an innovative communica-tion solution called Cloud Communication, and to incorporate video communication withthe concept. To achieve this goal, the thesis passed through several phases including abackground-study, a design phase, prototyping, implementation and evaluation. The resultis one web application and one desktop application, built with the Adobe Flex SDK. Dueto well-defined goals and good planning, the thesis could be completed without any majorissues.

The background-study gave valuable and necessary knowledge about the structure andfunctionality of the previous system and supported us in planning the forthcoming work.This phase also included a market analysis where other applications with video communi-cation, as well as the supply of these type of applications were investigated. The conclusionwas that there is currently no other concept, open to the public, where users can contact aspecific person and establish a video conversation to that person, anonymously through theweb browser. Wether or not there is a demand for this type of services is however debatable.

In the design phase a good interaction flow could be identified using several mockupsthat were evaluated and redesigned through a number of iterations. Using iterative designhelped motivating design choices and resulted in a user-friendly interface.

The design, prototype and implementation phases were carried out using Illustrator,Catalyst and Flash Builder. This workflow proved to be very efficient as it was easy togo from design proposals to a more detailed graphical interface, adding animations, andfinally connecting the interface to the back-end and implementing functionalities. And eventhough there were few tutorials for Catalyst, which at the time of this thesis had recentlybeen released, we experienced no difficulties in using the software. The only drawback withthis work method is that it is hard to return to the design and prototype phase, while in theimplementation phase. This is because of the limitation that it is only possible to go fromCatalyst to Flash Builder, i.e converting a FXG file to a Flex project, and not the otherway around. This means that when the developer has started to add functionality in FlashBuilder, it is not possible to redesign the interface in Catalyst without having to cut andpaste code. And as we believe that design should be an iterative process, this is slightlycontradicting. Our way to handle this was to evaluate the prototype made in Catalyst asextensively as possible. However, redesigning specific features while in the implementationphase was inevitable, and fortunately modifying graphical appearances can be done withoutany greater effort in Flash Builder as well.

At the beginning of thesis, the main goal was to integrate a video user interface into the

59

60 Chapter 9. Conclusions and Discussions

existing communication solution. However, as this task was accomplished at an early stage,more time and effort could be dedicated to designing the next generation of the clients.The prototypes of the redesigned applications were later demonstrated at Ericsson. Thisresulted in an increased interest in seeing the new concept live as a trial on the EricssonCommunication Network. Launching the system would naturally require a far more exten-sive implementation than just a prototype, therefore much time was spent on solving smallerbugs and glitches which would not have been regarded as problems if the clients had stayedin a prototype state.

The by far most time-consuming part of the implementation has been to set up theRed5 environment to work properly. The main reason is very poor, if not nonexistent,documentation, which basically makes it very hard to grasp and troubleshoot. As focusgot transferred to building a fully functional service, some goals got neglected due to lackof time. One of these goals was to perform a evaluation with external end-users and toinvestigate wether or not the public has an interest in this service. Another goal that wasput aside was the Benchmarking and comparison of CloudCom versus other similar solutionson the market. On the other hand, several features that were not requested initially havebeen added such as SMS2Go and Call2Go.

The result of this thesis is mainly a concept that can be used by Ericsson to demonstratethe possibilities with Cloud Communication and the capabilities of the Widget ManagementSystem.

9.1 Possible use-cases for videoRegarding the use-case of video in CloudCom, we are a little skeptical wether or not thereis any interest in anonymous video communication. Applications such as ChatRoulettehave become publicity successes, but could not really be compared to CloudCom as bothparticipants are anonymous to one another in those applications. There are however anumber of cases where video communication could be interesting.

One way to increase interest is to give users the possibility to make a profit by allowingthem to charge other users for calling them, similar to the way SMS2Go and Call2Gois implemented on blogs. By integrating video into the CloudCom system, the span ofservices would increase from not only voice communication but also services that require alive video stream. These services could for example be a doctor giving medical advice, afortune teller selling her services or other similar cases. Another nice use-case would be ifsellers on third-party marketplaces such as Blocket and eBay could incorporate a CloudComwidget into their advertisement so that possible buyers can contact them without havingto expose sensitive data such as telephone numbers and email addresses and protect bothparts integrity. With video communication, the seller could also show and demonstrate thespecific merchandise. The risk is however that the application will be utilized for commercialuse to broadcast inappropriate material.

Another case where the concept has possibilities to succeed is in a business scenariowhere video can contribute to collaboration between employees. The addition of video inthe CloudCom system gives users more options in what ways they can be contacted byclients or co-workers. Especially in the case with co-workers this kind of service would makeit easier to maintain a closer working relationship over distances. By adding features to easethe collaboration, such as file sharing for example, the widget could become more attractiveto use. And even though video conferencing has seen many setbacks since its introduction inthe 1970s, we believe that demand for video communication will increase as the technologybecomes more lightweight and gets included in influential products such as Apple’s iPhone.

9.2. Restrictions and Limitations 61

9.2 Restrictions and Limitations

During the development and testing of the clients a few limitations were found. First of all inorder to conduct a video conversation with acceptable quality, a decent Internet connectionis a prerequisite. Some testing of the clients were done on a public wireless network andduring these tests a substantial degradation in quality was observed. Both in video andvoice quality as well as delay times. The delay times is an issue that has been recurrentwhile developing the clients. The delay times have greatly fluctuated depending on thestream qualities sent to the Red5 server. Changing the frame rate, picture quality andbandwidth allocation all seemed to have an effect on the amount of delay. Balancing thoseparameters with respect to acceptable delay times and maintaining acceptable quality wasvery time consuming. What we finally ended up with was a delay time of about 0.5 secondbut sometimes the delay time still peaks at 2-3 seconds before returning to 0.5 secondsagain. The Red5 media server has been the source of most troubleshooting in this project.The biggest problem that remains to be solved is that sometimes Red5 drops the connectionto the clients killing the streams. This is done without any traces in the logs or the debugmode of Red5. Finding the source of this issue is therefore very hard.

All of the issues involving Red5 can give the clients a rather unstable feel. Sometimesit works without problems, but when Red5 does something out of the ordinary some weirdbehaviors can be observed in the clients. As an example, the clients have no way of handlingwhen Red5 drops the connection and therefore a call can proceed even though the connectionthrough Red5 is lost. Preferably the call should be disconnected but because there are nocall-backs from Red5 there is no way of achieving this.

Another issue that emerged late in the project during the test phase was that an updateof the Adobe AIR runtime environment prevented users of the desktop client to log in tothe system. Fortunately this problem only emerged on Mac OSX. A trouble report was sentto Adobe, hopefully the problem will be resolved in an update of the AIR framework.

9.3 Future Work

In order to release the clients and the added video feature as an update of the ECN-trial abit more work and testing is needed. First of all, a distributing channel of the new desktopclient has to be created so that the users of the ECN-trial can download it to their computer.

Testing of clients has mostly been done on a single user basis. A few multiple user testshave been conducted but these were done without monitoring any loads on the servers.More complete performance and load tests are needed before the clients can be released.

The Red5 stability issues mentioned in section 9.2 should be addressed in some way.We are by no means experts at troubleshooting servers. Much time was spent on findingthe cause of the issues but without success. Perhaps someone with more experience dealingwith media servers can get to the root of the problem. Using commercial solutions as FlashMedia Server1 or Wowza media server2 could perhaps be another way of getting around theproblem since they provide better support and more documentation then what Red5 do.

The results of the workshop presented in section 8.6.1 should be taken into considerationand changes based on the feedback from the participants should be implemented.

Finally there are some other features that we wanted to add to the clients, but no timewas found to do it:

1http://www.adobe.com/products/flashmediaserver/2http://www.wowzamedia.com/

62 Chapter 9. Conclusions and Discussions

Image uploader The new web client supports showing a picture of the B-party. An imageuploader in the settings window of the desktop client would be a nice way for the B-party to upload this image. Alternatively adding an upload feature to the registrationweb site.

Availability options Implementing a way of controlling availability from the desktop clientwould be a nice feature to support.

Mobile video A request from Ericsson was to investigate if connecting a video conversationwith mobile phones was possible. Adding video in pc-to-phone or phone-to-phonescenarios is a natural extension of the video functionally. Because of time restraintsthis was just briefly investigated. The results of the investigation showed that the SIPprotocol used to encode the audio streams has support for video and that asterisk canhandle it. The problem was that the Red5Phone application running on Red5 cannot encode the RTMPT video stream to SIP. In order for this to work an extension ofthe Red5Phone application or an entirely new SIP application has to be written. Theconclusion is therefore that the scenarios described should be possible if the necessarycomponents are available.

Chapter 10

Acknowledgements

First of all we would like to thank Ericsson for giving us the opportunity to carry out ourthesis work in an exciting and inspiring environment. We would like to thank our supervisorat Ericsson Mats Åkesson which despite a busy schedule has provided input and feedbackwith great enthusiasm during the entire thesis work. Thanks to the entire Cloud Commu-nication team; Michael Brodin, Martin Kurtsson, Johan André, Tomas "Figge" Larsson,Håkan Andersson, Andreas Åhlund and Olle Lindroos for giving us fantastic support andguidance both on and off working hours. We would also like to thank Richard Wållanderfor his inspiration and feedback. Together you all made our stay at Ericsson a memorableexperience. Thank you Prof. Lars-Erik Janlert our supervisor at UmU for the feedbackgiven on the report. As a last remark we would like to thank our families for the untiringsupport given during this thesis work.

63

64 Chapter 10. Acknowledgements

References

[1] http://maven.apache.org/what-is-maven.html, accessed 2010-07-15.

[2] http://red5.org/, accessed 2010-07-19.

[3] Dennis Abrazhevich. Classification and characteristics of electronic payment systems.In Lecture Notes in Computer Science, pages 81–90, 2001.

[4] Michael Boyle, Carman Neustaedter, and Saul Greenberg. Privacy factors in video-based media spaces. In Steve Harrison, editor, Media Space 20 + Years of MediatedLife, Computer Supported Cooperative Work, pages 97–122. Springer London, 2009.

[5] Brian J. Corbitt, Theerasak Thanasankit, and Han Yi. Trust and e-commerce: a studyof consumer perceptions. Electronic Commerce Research and Applications, 2(3):203–215, 2003.

[6] Siddhartha R. Dalal and Colin L. Mallows. Factor-covering designs for testing software.Technometrics, 40:234–243, 1998.

[7] Carmen Egido. Video conferencing as a technology to support group work: a reviewof its failures. In CSCW ’88: Proceedings of the 1988 ACM conference on Computer-supported cooperative work, pages 13–24, New York, NY, USA, 1988. ACM.

[8] Ericsson.com. Corporate information. http://www.ericsson.com/ericsson/corpinfo/index.shtml, accessed 2010-07-12.

[9] Ericsson.com. Ericsson ipx. http://www.ericsson.com/solutions/ipx/ipx-payment.shtml, accessed 2010-07-02.

[10] Ericsson.com. Vision and core values. http://www.ericsson.com/ericsson/corpinfo/compfacts/mission_vision.shtml, accessed 2010-07-12.

[11] Michael Fischer, Harald Gall, and Manfred Hauswirth. Towards a generalized paymentmodel for internet services. In University of Vienna, pages 81–90. Oxford SciencePublications, Clarendon Press, 2001.

[12] D. Gefen and D. Straub. Managing user trust in b2c e-services. E-service Journal,2(2):7–24, 2003.

[13] David Gefen. E-commerce: the role of familiarity and trust. Omega, 28(6):725–737,December 2000.

[14] Tyrone Grandison and Morris Sloman. A survey of trust in internet applications. IEEECommunications Surveys and Tutorials, 3(4), 2000.

65

66 REFERENCES

[15] Singh Harminder, Vikram Sethi, and Vijay Sethi. Changing inside, watchin outside:Understanding business model adaptations to guide information technology decisions.In 26th International Conference on Information Systems, pages 629–643, 2005.

[16] Donna L. Hoffman, Thomas P. Novak, and Marcos Peralta. Building consumer trustonline: The case for information privacy”. Commun. ACM, 42(4):80–85, 1999.

[17] Ellen A. Isaacs and John C. Tang. What video can and can’t do for collaboration: a casestudy. In MULTIMEDIA ’93: Proceedings of the first ACM international conferenceon Multimedia, pages 199–206, New York, NY, USA, 1993. ACM.

[18] P. Jeffrey. Videoteleconferencing: Why is it disadvantageous for group collaboration?Technical report, German National Research Center for Information Technology, 2005.

[19] Tejinder K. Judge and Carman Neustaedter. Sharing conversation and sharing life:video conferencing in the home. In CHI ’10: Proceedings of the 28th internationalconference on Human factors in computing systems, pages 655–658, New York, NY,USA, 2010. ACM.

[20] Kornelia Konrad, Gerhard Fuchs, and Jochen Barthel. Trust and electronic commercemore than a technical problem. In SRDS ’99: Proceedings of the 18th IEEE Sympo-sium on Reliable Distributed Systems, page 360, Washington, DC, USA, 1999. IEEEComputer Society.

[21] Nina Kreyer, Key Pousttchi, and Klaus Turowski. Characteristics of mobile paymentprocedures. In In: Maamar, Z.; Mansoor, W.; van den Heuvel, W.-J. (Hrsg.): Pro-ceedings of the ISMIS 2002 Workshop on M-Services, 2002.

[22] Nina Kreyer, Key Pousttchi, and Klaus Turowski. Standardized payment proceduresas key enabling factor for mobile commerce. In In: Bauknecht, K.; Quirchmayr, G.;Tjoa, A M. (Eds.):EC-Web 2002, LNCS 2455, pages 400–409. Springer, 2002.

[23] Nicholas Lesiecki and Richard Hightower. Java tools for eXtreme Programming: mas-tering open source tools including, Ant, JUnit, and Cactus. John Wiley & Sons, Inc.,New York, NY, USA, 2002.

[24] B Mahadevan. Business models for internet-based e-commerce: An anatomy. CaliforniaManagement Review, 42(4), 2000.

[25] Prussog Muhlbach, Bocker. Telepresence in videocommunications: a study on stere-oscopy and individual eye contact. Human Factors, 37:290–305, 1995.

[26] Glenford J. Myers and Corey Sandler. The Art of Software Testing. John Wiley &Sons, 2004.

[27] Donald A. Norman. The Design of Everyday Things. Basic Books, September 2002.

[28] Key Pousttchi. Conditions for acceptance and usage of mobile payment procedures. InThe Second International Conference on Mobile Business, pages 201–210, 2003.

[29] M. Rappa. Managing the digital enterprise, 2000. http://digitalenterprise.org/models/models.html, accessed 2010-07-02.

[30] K. Schwaber and J. Sutherland. Scrum. 2010. http://www.mountaingoatsoftware.com/scrum/overview, accessed 2010-07-12.

REFERENCES 67

[31] Abigail J. Sellen. Remote conversations: the effects of mediating talk with technology.Hum.-Comput. Interact., 10(4):401–444, 1995.

[32] Helen Sharp, Yvonne Rogers, and Jenny Preece. Interaction Design: Beyond Human-Computer Interaction. Wiley, 2 edition, March 2007.

[33] Ben Shneiderman and Catherine Plaisant. Designing the User Interface: Strategies forEffective Human-Computer Interaction (4th Edition). Pearson Addison Wesley, 2004.

[34] Mountain Goat Software. An overview of scrum for agile software development. http://www.mountaingoatsoftware.com/scrum/overview, accessed 2010-07-14.

[35] S.J Tan. Strategies for reducing customer’s risk aversion and internet shopping. Journalof Consumer Marketing, 16(2):163–180, 1999.

[36] Paul Timmers. Business models for electronic markets. Electronic Markets, 8:3–8, 1998.

[37] Peter. Weill and Michael R. Vitale. Place to space : migrating to ebusiness models /Peter Weill, Michael R. Vitale. Harvard Business School Press, Boston, Mass. :, 2001.

[38] F Kuipers P Van Mieghem Y Lu, Y Zhao. Measurement Study of Multi-party VideoConferencing, pages 96–108. Springer Berlin / Heidelberg, 2010.

68 REFERENCES

Appendix A

Source Code

A.1 POM ExampleThe source code below shows a snippet from a POM used to build the CloudCom project.

<?xml version="1.0" encoding="UTF-8"?><project>

<modelVersion>4.0.0</modelVersion><artifactId>wms-routing</artifactId><packaging>war</packaging><name>Routing</name><groupId>com.ericsson.radical.wms</groupId><version>1.0</version>

<build><finalName>wms-routing</finalName>

<plugins><plugin>

<artifactId>maven-compiler-plugin</artifactId><version>2.0.2</version><configuration>

<source>1.5</source><target>1.5</target>

</configuration></plugin>

.....

69

70 Chapter A. Source Code

Appendix B

Figures

B.1 Interaction flow-charts

71

72 Chapter B. Figures

Start application

Incoming call

Answer call?

YESNO

Call is connected

Video?

YES

Display V ideo Hide V ideo

NO

End call?

Call ended

YES

NO

Change settings

Adjust volume

Availability Status Image Password

Figure B.1: Flow chart for desktop client.

B.1. Interaction flow-charts 73

Click Widget

Chose contact method

Video/VOIP Send message Call 2 Go

Video?

YES

Display V ideo Hide V ideo

NO

Connect call

User answers with desktop client?

User answers with cellphone?

Connect to cell

N Y

Call is connected

End call?

N

Call ended

Adjust volume

Y

If through desktop client

N

Y

Figure B.2: Flow chart for web client.

74 Chapter B. Figures

Appendix C

Mockups

Video Call-2-Go Meddelande

Hannes Wikström

Upptagen

Samtal:12:56

Figure C.1: The tab concept with spacing between components.

75

76 Chapter C. Mockups

Jonas SandströmAvailable

MessageVideo/VOIP Call 2 Go

DisconnectVideo

Call 10:13

Jonas SandströmAvailable

MessageVideo/VOIP Call 2 Go

DisconnectVideo

Call 10:13

Figure C.2: A more compact version of the tab concept.

77

ImageCalle JohanssonDeveloper

12:23

Hang up

Make Call

ON

1

2

3

Figure C.3: Another tab concept with no spacing and the presentation section placed belowthe tabs.


Choose in what way you wish to contatc me:

ImageJonas SandströmDeveloper

Choose in what way you which to contatc me:




Would you like to enable video, orvoice chat only?

ON

Make Call

Hang up

ON12:45

Back

Back Back

Figure C.4: A concept with where the the different pages gets flipped into place.

79

Video Message Call

Steve JobsCEO Apple

Video Message Call

Steve JobsCEO Apple

WEBB MOBILE

CALL

cancel 03:40

Figure C.5: Design with speech bubble style menu bar.



Web Mobile

ConnectCancel

Type of video communication:


Cancel 03:40

Figure C.6: A concept that mimics a physical business card.

81

Hannes WikströmDeveloper@work

contact

Next

Hannes WikströmDeveloper@work

contact

Figure C.7: A concept that uses a knob for navigation.


Incoming callAnswer? Yes No

User name:

Password:

Login

Disconnect

Call 10:13

Video

Figure C.8: A simple mockup of the desktop client.

Appendix D

Build Guidelines

This section will provide instructions on how to build the web and desktop client locally ona computer. To build any of the clients ANT has to be installed on your computer and youneed the FLEX 4 sdk.

D.1 Desktop Client

To build the the desktop client on your computer a few configurations has to be made tothe ANT build file in the project. Follow these instructions:

1. Download the latest stable build of the FLEX 4 sdk from http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4 if you do not already have it installed.

2. Unzip the Flex sdk were every you like it on your computer.

3. Open the file

/trunk/Com2DesktopVid2.0/build.xml

4. Find the row at the top of the file that says

<property name="FLEX_HOME" value="..">

5. Set the value property to the path were you unzipped the sdk.

6. In a terminal window navigate to the

/trunk/Com2DesktopVid2.0/

directory and type ant to build the project.

The ANT script will then produce a file called Com2DesktopVid.air which can beinstalled on any computer that has the Adobe AIR runtime environment installed.

83

84 Chapter D. Build Guidelines

D.2 Web ClientThe build instructions for the web client is very much similar, the only thing changed is theproject directory.

1. Download the latest stable build of the FLEX 4 sdk from http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4 if you do not already have it installed.

2. Unzip the Flex sdk were every you like it on your computer.

3. Open the file

/trunk/com2Web2.0/build.xml

4. Find the row at the top of the file that says

<property name="FLEX_HOME" value="..">

5. Set the value property to the path were you unzipped the sdk.

6. In a terminal window navigate to the

/trunk/com2web2.0/

directory and type ant to build the project.

In this case the ANT file produces an SWF file that can be inserted on websites and bedisplayed in any browser that support the Adobe Flash Player environment.

Incorporating Video Support in an Innovative Communications Solution

Documents

Transcript of Incorporating Video Support in an Innovative Communications Solution