Video over IP – Remmen
A Grensesnittdesign project
2004
Andreas Bergstrøm
Magnus Fredlund
Harald K. Jansson
Table of Contents
TABLE OF CONTENTS ............................................................................................................ 2
INTRODUCTION ....................................................................................................................... 5
PROJECT SCOPE .................................................................................................................... 6
VIDEO OVER IP – REMMEN ....................................................................................................... 6
LIMITATIONS ............................................................................................................................ 6
Users – The limitation ....................................................................................................... 7
SYSTEM OVERVIEW ............................................................................................................... 8
VIDEO OVER IP – REMMEN ....................................................................................................... 8
GRAPHICAL USER INTERFACE .................................................................................................. 9
APPLICATION INTERFACE ......................................................................................................... 9
BACKEND ENCODING INTERFACE .............................................................................................. 9
DESIGN PROCESS ................................................................................................................ 10
1. REQUIREMENTS ANALYSIS .................................................................................................. 11
2. SYSTEM DESIGN ................................................................................................................ 12
3. PROGRAM DESIGN ............................................................................................................ 12
4. CODING ............................................................................................................................ 12
5. UNIT AND INTEGRATION TESTING........................................................................................ 13
6. SYSTEM TESTING ............................................................................................................. 13
7. ACCEPTANCE TESTING ..................................................................................................... 13
8. OPERATION AND MAINTENANCE ......................................................................................... 13
PROJECT PLAN ..................................................................................................................... 15
VISUAL PROJECT PLAN ....................................................................................................... 18
THE USERS – WHO ARE THEY? .......................................................................................... 19
Two user-groups: ............................................................................................................ 20
DESIGN SPECIFICATIONS.................................................................................................... 22
SYSTEM REQUIREMENTS SPECIFICATION ................................................................................ 22
1 Introduction .................................................................................................................. 22
1.1 Purpose.................................................................................................................... 22
1.2 Scope ........................................................................................................................ 23
1.2.1 Relationships ......................................................................................................... 23
1.3 Definitions, Acronyms and Abbreviations ................................................................ 23
1.4 References............................................................................................................... 24
1.5 Overview .................................................................................................................. 24
2 GENERAL DESCRIPTION ...................................................................................................... 24
2.1 Product perspective ................................................................................................. 25
2.2 Product functions ..................................................................................................... 25
2.3 User characteristics ................................................................................................. 26
2.4 General constraints .................................................................................................. 26
2.5 Assumptions and dependencies .............................................................................. 27
3.0 SPECIFIC REQUIREMENTS ................................................................................................ 27
3.1 System requirements ................................................................................................ 28
3.2 Design constraints ................................................................................................... 29
3.2.1 Standards compliance ........................................................................................... 29
3.5 Attributes .................................................................................................................. 29
3.5.1 Availability .............................................................................................................. 30
3.5.2 Security .................................................................................................................. 30
3.5.4 Maintainability ........................................................................................................ 30
3.6 Use cases ................................................................................................................. 31
3.6.1 Overview of feeds .................................................................................................. 31
3.6.2 Turn feed off........................................................................................................... 33
3.6.3 Turn feed on........................................................................................................... 35
3.6.4 Change feed info ................................................................................................... 36
SYSTEM DESIGN DOCUMENT................................................................................................... 38
PROGRAM DESIGN................................................................................................................. 42
THE PROTOTYPES ................................................................................................................ 44
PROTOTYPE 1 – THE DRAWING ............................................................................................... 44
PROTOTYPE 2 – HTML/ PHOTOSHOP MOCKUP ....................................................................... 48
PROTOTYPE 3 ....................................................................................................................... 49
PROTOTYPE 4 ....................................................................................................................... 50
PROTOTYPE 5 ....................................................................................................................... 52
PROTOTYPE 6 ....................................................................................................................... 53
PROTOTYPE 7- THE DYNAMIC INTERFACE ................................................................................ 55
PROTOTYPE 8 – THE POLISH .................................................................................................. 57
PROTOTYPE 9 – THE FINAL PROTOTYPE .................................................................................. 58
DESIGN HEURISTICS USED ................................................................................................. 60
1. VISIBILITY OF SYSTEM STATUS ............................................................................................ 60
2. MATCH BETWEEN SYSTEM AND THE REAL WORLD ................................................................ 60
3. USER CONTROL AND FREEDOM ........................................................................................... 61
4. CONSISTENCY AND STANDARDS.......................................................................................... 61
5. RECOGNITION RATHER THAN RECALL .................................................................................. 61
6. AESTHETIC AND MINIMALIST DESIGN.................................................................................... 61
USABILITY EVALUATION ..................................................................................................... 62
USABILITY W ORKSHOP USABILITY TEST.................................................................................. 62
Executive summary......................................................................................................... 62
Methods .......................................................................................................................... 63
Results ............................................................................................................................ 64
Findings and recommendations ...................................................................................... 66
USABILITY TEST ONE .............................................................................................................. 68
Executive summary section ............................................................................................ 68
Method ............................................................................................................................ 69
Results ............................................................................................................................ 70
Findings and recommendations ...................................................................................... 73
REDESIGN .............................................................................................................................. 75
FIRST REDESIGN – USABILITY WORKSHOP RESULTS................................................................. 75
Program design - changes needed................................................................................. 75
Program design – changes ............................................................................................. 75
SECOND REDESIGN – FIRST USABILITY TEST RESULTS ............................................................. 77
Program design – changes needed ................................................................................ 77
Program design – changes done .................................................................................... 78
THIRD REDESIGN – SECOND USABILITY TEST RESULTS ............................................................. 79
CONCLUSION ........................................................................................................................ 80
APPENDIX 1 ........................................................................................................................... 81
USER MANUAL ....................................................................................................................... 81
Prerequisites ................................................................................................................... 81
Monitoring the system ..................................................................................................... 82
Making changes to the system ....................................................................................... 83
Introduction
Next summer all the different departments of
Østfold College is going to move to the new
campus at Remmen. At this campus there
won’t be any television sets or coax-cabling
and therefore the TV signal is going to be
digitized and transmitted over the IP network.
This project revolves around developing a user
interface for the administration of this system.
This UI (user interface) will be the front end of
the entire system, allowing the administrator to
configure a multitude of options on each
stream, and even to start and stop a stream.
Project scope
Video over IP – Remmen
The goal of this project has been to develop
the system administrators interface to a livestreaming TV over IP system to be used at the
new College campus at Remmen. The work
has been consentrated on the administrator
graphical user interface, and not on the
underlying system, which has been developed
in parallel, designed to fit the requirements of
the GUI.
Limitations
Although the original plan of the project was to
create a functional prototype of the system,
the final iteration is ready to be used as the
actual application, so the system as such has
no limitations imposed due to time constraints.
Users – The limitation
The system is meant to be used by system
administrators with a good and thorough
understanding of computers and how to use
them, but we chose to impose the additional
restraint of making it easily accessible even to
normal users with only basic computer skills,
such as being able to surf the web.
System overview
Video over IP – Remmen
The Remmen system is a distributed live video
over IP streaming system:
There are several interfaces in the system:
The primary interface, and the interface
worked on in this project, is the administrator
GUI in the web browser on the users machine.
The web interface between the users machine
and the web server, handled by the web
browser.
The Application Interface between the web
server script and the application server
The Backend Interface between the
application server and the encoding server(s)
Graphical User Interface
The GUI is web-based, using XHTML 1.0 and
Python.
Application Interface
The Application Server, although not
developed by the project group, is an import
part of the project. The project server
manages and holds all channel information.
Backend encoding Interface
The backend encoding server starts encoding
channels when it receives communication from
the Application Server to do so. The
Application Server sends this communication
over XML-RPC when triggered by the user
interface to do so.
Design Process
We chose to use the V-model design process.
The design process consisted of eight steps:
Requirements analysis
System design
Program design
Coding
Unit & Integration testing
System testing
Acceptance testing
Operation and maintenance
1. Requirements analysis
During requirement analysis we will analyze
the project contract, as well as user
expectations and feedback in order to
generate a system requirement specification.
Then during acceptance testing, we will use
this document and user feedback to ensure
that the requirements had been met.
2. System design
Using the system requirement specification we
will create a system design document,
specifying the general outline of the system.
This document will be used during system
testing together with user feedback to ensure
that the system meets the requirements.
3. Program design
Using the system design document we will
specify the requirements for the individual
software modules, enabling parallel
development against a common API, the
program design document is used during unit
and integration testing to ensure that the
individual components of the system can
cooperate and work together.
4. Coding
The actual coding of the system
5. Unit and integration testing
The individual components of the system are
tested, both singular and in concert to ensure
that they work together.
6. System testing
The overall system is tested, also with actual
users.
7. Acceptance testing
The system is tested against the system
requirement specification to ensure that all
requirements have been met.
8. Operation and maintenance
The system is used in a real-world
environment and tested and fixed as such.
Project plan
Visual Project Plan
The users – who are they?
The typical user of this VOIP system is one
with basic knowledge of how to surf the web
using a standard web browser. The user
interface should be self-explanatory enough to
let people with less than professional IT skills
handle the administration of the system.
Examples of the kind of people/organisations
that could be using such a system could be:
Homeowners – people who want to stream
video to different units in their homes
Hospitals/Universities/Large firms – easy
distribution of video across a rather large
construction complex
Smaller organisations – hotels, kindergartens,
elementary schools, smaller stores/malls
wishing to be able to easily distribute video
Two user-groups:
We have mainly focused on two user-groups,
which we have to create a balanced GUI for:
Users with good understanding of computers
Users with poor understanding of computers,
but trained at using web-applications
The first category of users will contain system
administrators, network managers and other
skilled individuals. For this group our interface
may seem oversimplified as they have good
knowledge of the underlying architecture. We’ll
have to consider if our system shall contain
more specific information about events and
settings if asked for.
The second category of users will in general
have no understanding of the underlying
system (and they shouldn’t need to). The
information presented in our interface will need
to use easy to understand metaphors for this
group of users.
Design Specifications
System Requirements Specification
1 Introduction
This document describes the software
requirements to the Video over IP (VoIP)
system. The document will define the
limitations and environments of the system, as
well as a description of the complete system,
while this document will only define the User
Interface of the system.
1.1 Purpose
The purpose of this document is to provide
the project customers with an easy to read,
highly defined specification of the software
project, VioIP - User Interface part.
1.2 Scope
An identification of the product to be
developed, what does it do (and what does it
not do), why is the product being developed
(including a precise description of its benefits,
goals and objectives).
1.2.1 Relationships
The product will be the user interface part of a
Video over IP streaming solution, allowing
administrators and users alike to quickly see
which channels are available, choose from
one of them to view, or to administrate these
channels.
1.3 Definitions, Acronyms and Abbreviations
This subsection contains definitions of all
terms, acronyms and abbreviations used in
the document.
VioIP - Video over IP
UI - User Interface
GUI - Graphical User Interface
1.4 References
XML-RPC specification:
http://www.xmlrpc.com/
1.5 Overview
In this document chapter two will describe the
system at the general level, while chapter
three will list all the requirements of the
project.
2 General Description
This chapter will describe the system wide
requirements for the VioIP - UI project. The
functionality, users and limitations of the
system. This general description will make it
easier for the reader to understand chapter
three.
2.1 Product perspective
This project is part of a larger project VioIP.
This project will define a web interface against
the VioIP backend; communication to the
backend will be over XML-RPC.
2.2 Product functions
The UI part (this project) will perform the
following functions:
List all available streaming channels to the
user/administrator
List all known channel identification
information
Allow the administrator to change the channel
identification of a streaming channel
Administrate new streaming channels
Reconfigure existing streaming channels
Administrate the coverage of the individual
streaming channels
Turn individual streaming channels on or off
2.3 User characteristics
The users of the system will have at least
basic computer skills, (powering a computer
on and off, surfing, using web forms.)
The administrators of the system will have all
the skills of the ordinary user, but will also
have at least a general understanding of the
backend technical solution (satelite receivers,
DVD players etc.)
2.4 General constraints
This project will use XHTML 1.0 Strict as
HTML codebase and all webpages must
validate according to the standard.
The web pages must work correctly in all
modern browsers
VLC or QuickTime must be installed on the
client computers
The programming language of the project will
be Python
2.5 Assumptions and dependencies
The system will need to interact with the
backend system, which will be developed in
parallel with the UI, but independently.
3.0 Specific requirements
This section contains all the details, which are
relevant for the design phase to follow. The
ordering given here is just one way to present
the specific requirements in a logical way.
Specific requirements will be such that one
may objectively determine whether they are
fulfilled or not.
3.1 System requirements
In this subsection, a description is given of
how the transformation of inputs to outputs is
achieved. The description is given for each
class of functions, and sometimes for each
individual function. To a certain extent, this
description can be seen as a solution to the
user. This component of the requirements
specification is the main starting point for the
design phase.
The system will adhere and validate to any
and all standards used in the project.
The system shall not need a manual to be
used
The administrator will not need more than ten
minutes to fully understand and be able to use
all the capabilities of the system.
3.2 Design constraints
3.2.1 Standards compliance
All HTML will follow the XHTML 1.0 Strict
standard
All interprocess communcation will follow
the XML-RPC standard
The configuration file must be validateable by
the configuration file DTD
3.5 Attributes
In this section, particular attention is paid to
quality aspects. These requirement must be
measurable and verifiable. They must be
stated in objectives terms.
3.5.1 Availability
The system must be able to quickly (less than
five minutes) recover from a system restart or
crash.
3.5.2 Security
The administration functionality must not be
available to any other persons than
administrators. SSL, IP checking and/or other
security routines must be used to ensure this.
3.5.4 Maintainability
The system must be completely module
based, with a clearly defined API for
communication between modules.
3.6 Use cases
3.6.1 Overview of feeds
Case name: Overview of feeds
Summary: User wishes to get an overview
over all the feeds
Steps:
User logs on to system
The user now has easy access to the status of
the feeds
Result:
The user has gained an overview of all the
feeds
3.6.2 Turn feed off
Case name: Turn feed off
Summary: User turns a feed off
Steps:
User log son to system
User selects the wanted feed
User enters the option box associated with the
wanted feed
User presses the off radio button
User applies the changes
Result: The user has turned one of the feeds
off
3.6.3 Turn feed on
Case name: Turn feed on
Summary: User turns a feed on
Steps:
User logs on to system
User selects the wanted feed
User enters the option box associated with the
wanted feed
User presses the on radio button
User applies the changes
User exits the option box
Result: The user has turned one of the feeds
on.
3.6.4 Change feed info
Case name: Change feed info
Summary: User changes feed info
Steps:
User logs on to system
User selects the wanted feed
User enters the option box associated with the
feed
User changes the info associated with the feed
User applies the changes
User exits option box
Summary: The user has changed the info of
one of the feeds
System design document
The system will be designed along a fully
modular approach, loosely coupled. The
modules can be divided into two main groups,
front end and back end. The front end handles
all user interface tasks, while the backend
handles all streamer interface tasks.
The first interface is between the user and the
GUI engine, and is known as the User
Interface. The GUI engine is responsible for
showing all data and sending user interactions
on to the UI-backend.
The second interface is between the GUI
engine and the UI-backend and is the
Common Gateway Interface/Application
Interface. HTTP and CGI communication will
be used for communication between the two
modules/layers. The UI-backend will handle all
user interaction tasks, interface with the
backend modules, and forward the reply to the
UI-engine.
The third interface is between the UI-backend
and the Application Logic, and is known as the
XML-RPC interface. XML-RPC will be used for
communication between the two
modules/layers. The Application Logic module
has full knowledge of which streaming process
is doing what, and will control the streams and
give the information to the UI-engine upon
request.
The fourth interface is between the Application
Logic and the Application Manager. The
Application Manager is responsible for
managing the various streaming processes.
Program Design
API-specification to the back end.
CreateStream(streamnumber)
Creates a new stream
GetNumberOfStreams()
Returns the number of existing streams
GetStreamCoverage(streamnumber)
Get coverage for stream streamnumber
SetStreamCoverage(streamnumber,
coverage)
Set coverage for stream streamnumber to
coverage
GetStreamMulticast(streamnumber)
Get multicast address for stream
streamnumber
SetStreamMulticast(streamnumber, address)
Set multicastaddress for stream
streamnumber to address
GetStreamStatus(streamnumber)
Get streamingstatus of stream number
streamnumber
ListStreams()
Returns a list of all existing streams
StartStream(streamnumber)
Starts stream number streamnumber
StopStream(streamnumber)
Stop stream number streamnumber
The Prototypes
While
working on this project we have put
together different prototypes. In the following
part of the document we’ll go through these
prototypes and explain a bit about what
changes were made between the different
steps. Our process was an iterative one. We
went through many, some small iterations as
the project took shape.
Prototype 1 – the drawing
This prototype is a free-hand drawing of how
the system would or could look like. We made
three variations on our idea. As you will se
later, one of them made it through.
Before we started out
with the prototyping we
had some basic
requirements to take into
account.
Our system should be
able to present an
Fig1. Three
overview of the current channels
to the
user
different
layouts
The system should be easy to use and not
display too much or redundant information.
The system should give visual feedback as to
what is currently on a channel
Fig1. depicts our first
brainstorming-session.
Firstly we came to the
conclusion that we
needed multiple boxes to
display the information pertaining to the
channel-feeds.
We started out with three different variations
on our basic ideas. The uppermost idea in
fig1. shows a simple implementation with one
box for each channel. The next idea shows
rows of channels with space for more textualinformation. The third idea tries to make the
elements smaller, which gives the possibility of
placing more channel-feeds on one screen.
After a brief discussion found out that we
should go for the first idea, since it is the
easiest to understand and gives a reasonablysized image that shows what the channel-state
(what is is sending).
Fig.2 shows a development of our first idea. It
introduces the concept of a information-bar at
the bottom where general information could be
shown. Further it shows icons in each box that
would pertain to the different choices a user
would have to manipulate a feed. The concept
of pull-down menus to change channel is also
introduced. As we’ll later see this was
functionality that our customer did not want for
technical reasons.
Prototype 2 – HTML/ Photoshop mockup
This
prototype is
really just a
HTML/
Photoshop
mock-up of
our original
idea. The
Fig3. 2
feed-boxes
consists of:
Feed-name
Dropdown-arrow
Feed-image
On/ Off-button
Representation of coverage-mode
Representation of which encoding-interface
that delivers the stream (i.e. 1/3, 1/5, etc.)
This is clearly not a good interface (all-red
buttons with diffuse symbols), but it acts as a
good platform for further development.
Prototype 3
Fig4. 3
Prototype 4
This prototype
This is just a clean HTML-
implements
implementation of the feed-
some basic
boxes. The design is HTML-
functionality –
form based, and implements
an on/ off -
a channel selector. The code
radio switch.
for this design will work as a
There were
platform for building the rest
some
of the
discussions
interface.
about how we
should mix
interactive and
non-interactive
items below
the streampicture (i.e.
Fig5. 4
on/off-switch, coverage-information, interfacestatus). As we added more features to the
interface we found it to become increasingly
cluttered. As a solution we decided to put all
interactive information on a separate page,
and this interface-design road was
abandoned.
Prototype 5
This is really
an interesting
prototype. We
implemented,
by request
from our
customer feed- Fig6. Note; all the feed-boxes
boxes showing
shows live movies in this
live-feeds
prototype.
(pictures
updating in real-time). It turned out to be an
agonizing experience with way too much
information to handle at one. After discussing
it amongst the group, and with the customer,
we decided to put up thumbnails, which
renewed themselves after a certain interval.
By doing this we could still have a interface
which was easy and clean, at the same time
as doing a good job representing the system
status.
Prototype 6
This is our pre-test
prototype. It's a static
representation of the
system that we used for
our first test with users.
Fig7. 6
Prototype 7- the dynamic interface
This is the dynamic
python-powered userinterface. Here we have
implemented a pythonbased backend. This is
Fig8. 7
the prototype we used in
our first user-test. The boxes have the
following static information in them:
Status (shown with a green background if the
stream is currently enabled, and red
background if it’s not enabled)
Coverage (in this prototype we show the
actual ttl(time-to-live) value of the stream.
The prototype also has
an ‘Option’-button which
takes the user to a
separate options-page
for the stream in
question.
Fig9. OptionsWe got some good input
dialogue from
from the usability test.
prototype 7
The most common
feedback we got was the following:
Ugly colours
Misinterpreting coverage-mode
No reload-button
We also came to the conclusion (although the
users did not comment it) that having a
separate options-page was a bit cumbersome
and confusing.
Prototype 8 – The polish
Our prototype 8
represents the near
finished product.
The CSS-code has
been reworked after
negative comments
from users about the
Fig10. 8
choice of colours
and the appearance of the system in general.
Improvements to the general 'niceness' of the
system can also be positive for the usabilityaspects of the system. For example the added
drop-shadows makes the feed-boxes stand
out against the background and separate them
from each other in a good way.
Prototype 9 – The final prototype
This is the result
of all our
iterations. The
following are
added based on
the userfeedback and
Fig11. 8
better design-ideas:
Snapshot-code
‘Reload’-button
‘Flippable’ boxes
More sensible labelling of options
The idea behind the flippable feed-boxes is
that the user
should be able to
see all the
streams while
editing one
particular stream.
Fig12. 8
This is to avoid
confusion of being presented with a ‘new’
page when the user wants to change options.
It should be noted that a user can only flip one
box at a time. This is to keep the interface
simple and avoid that the user forgets what he
is doing.
We are very happy with the final design and
the user-tests done with this iteration is
documented in the usability-evaluation.
Design heuristics used
There has been several usability heuristics
used on the project:
1. Visibility of system status
The systems always show clearly the status of
its various sub-components. The status of the
streaming process in the encoder backend is
colour coded (green: on, red: off), and a
snapshot of the current transmission is also
given, allowing the administrator to quickly
determine of transmission of media is working
as it should.
2. Match between system and the real world
Through user interviews and usability testing,
we have suited the wording of the system to
reflect upon the users language and concepts
as accurately as possible.
3. User control and freedom
No act in the system is binding without using
the OK button, and there is always an easy
way to cancel the operation with the Cancel
button without any dialogue.
4. Consistency and standards
In all situations, all words have the same
meaning throughout the system.
5. Recognition rather than recall
All objects, actions and options are always
clearly visible and self-explaining. The system
is meant to be used easily, without any
training.
6. Aesthetic and minimalist design
The main status boxes show only static status
information, hiding away irrelevant status
information. The option boxes allow allimportant functions to be changed without
showing irrelevant information.
Usability Evaluation
Usability Workshop Usability Test
Executive summary
The test was conducted in one of the
computer labs at IA and all the group
members were present and also the test
person. The test group consisted of 4 persons.
Each test person was given a brief introduction
of the system and what was going to happen.
The test people were made clear that it was
not they that should be tested, but rather the
system. The tests were performed with one
group member guiding the test person and
one member taking notes. All the notes were
entered into the chart you see above.
Over all the testers found the system mostly
enjoyable to use, but some problems were
discovered. The problems consisted of
sluggishness in the system, colour scheme,
unclear labelling and indication of stream
status.
Further development may be needed to find
better alternatives for labelling different
options, other than that the test proved to
confirm the notion that the system was nearly
ready for release.
Methods
The entire test was set up in one of the
computer labs at OS Allé 11. The test persons
were tested one at a time. After the test
person hade been given a brief introduction of
the system, they were asked to perform a
number of tasks. The user group consisted of
computer science students and teachers.
These students/teacher have very good
knowledge of general computer usage, but
they should have no previous experience with
the system we’re testing.
Data collection was done by taking notes of
the actions performed by the test person. The
only person in the test subject’s field of view
was the guide, the others tried to stay in the
background.
Results
The first task proved to be to most diverse
when it comes to the results. Most of the users
were able to point out that the system had
something to do with TV channels, but from
there the descriptions varied quite a lot.
The second task was fairly similar to the first
result wise. The different test persons were
able to differentiate the alternatives, but most
of them had problems understanding what
some the options actually did. The address
option seemed to be the main source of
confusion. The different users had no real
reference point or previous experience to
compare the address option to.
The third task was mostly completed without
any major difficulties. One test person did
however hesitate a bit while performing the
task, although completing the task. One test
person also complained about not
understanding what the coverage option
meant.
The fourth task proved to be no problem to
complete but the system sluggishness was a
major annoyance for all the testers. The
absence of a “back” button made certain users
insecure about getting from the option page
back to the system overview.
The fifth task consisted of three sub-tasks.
Almost all tasks were performed without any
real troubles. But again the slow system
response irritated the testers.
The final task showed that the system proved
to be quite user friendly but also showed that
some problems has to be dealt with to make
the system even better. One test person made
a remark about the option box being too left
centred. A better indication of the stream
status was also wanted. And finally, every user
commented on how slow the system was.
Findings and recommendations
Findings:
The general consensus of the user group
showed that the system proved to be generally
user friendly, and the stream layout was well
recieved. There was however one problem
that all the test persons made remarks about;
the slow system response.
Some users thought that the system colour
scheme was ugly and that the option page
was in need of improvement. Some indicators
were also perceived as unclear, such as the
“status” indicator. Users pointed out that they
expected the indicator to be green when the
status was on.
Recommendations:
Making the system faster is perhaps the most
needed improvement at this stage of
development. Since all of the test persons
made remarks about this it’s recommended
that speeding up the system becomes a major
priority before testing the system again. A
change in colour scheme used is also
recommended, as most of the user found the
current colours rather unpleasing. It’s also
recommended to implement changes in how
the option box is accessed and how stream
status is communicated to the user.
Usability test one
Executive summary section
The test was conducted in a relatively small
room with all the group members present and
the test person. The test group consisted of 4
persons. Each test person was shown into the
room and given a brief introduction of the
system and what was going to happen. The
test people were made clear that it was not
they that should be tested, but rather the
system. The tests were performed with one
group member guiding the test person, one
member taking notes and one member
observing/taking pictures. All the notes were
entered into the chart you may see above.
Over all the testers found the system pleasing
to use, only minor annoyances were
uncovered. Most of the problems were related
to the labelling of different options and what
they actually did.
Further research may be needed to find better
alternatives for labelling different options, other
than that the test proved to confirm the notion
that the system was nearly ready for release.
Method
The entire test was set up in one of the
computer rooms at OS Allé 11. The test
persons were brought in one at a time. After
the test person hade been given a brief
introduction of the system, they were asked to
perform a number of tasks. The user group
consisted of students from the SF line, mostly
language students. These students have
reasonably good knowledge of general
computer usage, but they should have no
previous experience with the system we’re
testing. It is this kind of people we’re tailoring
the system for.
Taking notes and having one of the groupmembers observing/take pictures collected the
data. The only person in the test subject’s field
of view was the guide, the others tried to stay
in the background.
Results
The first task proved to be to most diverse
when it comes to the results. Most of the users
were able to point out that the system had
something to do with TV channels, although
any further description of the system proved to
be pure speculation of possible solutions.
The second task was fairly similar to the first
result wise. The different test persons were
able to differentiate the alternatives, but most
of them had problems understanding what the
options actually did. The address option
seemed to be the main source of confusion.
The different users had no real reference point
or previous experience to compare the
address option to.
The third task was mostly performed without
major difficulties. Two of the test persons did
however hesitate a bit while performing the
task. The first person felt insecure about when
the changes actually took effect and ended up
changing the coverage as well. The second
person really showed a general insecurity
about all his actions but managed eventually
to perform the task.
The fourth task proved to be no problem at all.
The fifth task consisted of three sub-tasks.
Almost all tasks were performed without
troubles, only one of the test persons showed
some hesitation completing the first task. The
problem was what happens after the addresschange? Is it necessary to press apply/ok?
The final task showed that the system proved
to be quite user friendly and only minor
problems existed when it came to
understanding what the different aspects of
the system actually did.
Findings and recommendations
Findings:
The general consensus of the user group
showed that the system proved to be generally
user friendly. There was however some
confusion about the options, and what they
really did. Most of the users found the system
aesthetically pleasing and quite logical to use.
These problems were somewhat expected
since the user group weren’t expected to have
enough computer knowledge to recognize
some of the technical terms used for the
options.
Recommendations:
To clarify different options has to be the most
important aspect for improvement. Maybe
adding help texts to some of the alternatives
could remedy this problem to a certain
degree? Changing some of the option names
is another solution.
Redesign
First redesign – Usability workshop results
Program design - changes needed
The colour scheme needed redesigning
The options screen needed a back link
The system needed to be faster
The stream process indicator was unclear
The options pane needed rewording
General bug fixes were needed
Program design – changes
1. Colour scheme:
The background colour was changed from
lavender to white, which was neutral and more
aesthetical.
2. / 5. Options screen
The first design had a separate page for the
option screen without a back link; this was not
usable. Instead of adding a back link, we
chose to implement a “flip” effect on the
channel boxes. When the user clicks on a
channel box, it is now replaced by the options
box, while the other channel boxes remain.
As to the wording, “Toggle on/off” was
replaced by “Streaming” and “Multicastaddress” with “Address” to allow the user to
easily understand the box.
3. System speed
The system is distributed across several
computers, and the inter-process
communication between computers was too
slow when based on SSH (Secure Shell)
communication, and we chose to use XMLRPC all the way, instead.
4. Stream process indicator
We replaced green background on the status
(On/Off) indicator with text colour (green when
on and red when off), to make it clearer, as
well as change the description to “Streaming”
to indicate that only movie streaming status on
the encoder box was shown.
6. Bug fixes
Streaming status indicator was fixed to show
actual state of encoding, instead of a semirandom value, which a bug returned.
Second redesign – First usability test results
Program design – changes needed
Screen reloading
Help function
Program design – changes done
1. Screen reloading
A reload link was added to the top of the page
to ease page reloading and remove the
problems of the error dialog caused by the use
of the HTTP Post method.
2. Help function
No help was added
3. Stream snapshots
Actucal stream snapshots replaced static
pictures
Third redesign – Second usability test results
As no usability problems were detected and
the application is fully functional, and therefore
no longer a prototype, the project is complete.
Conclusion
Tralalalalala
Appendix 1
User manual
Prerequisites
To use ReStream you will need the following:
Access to a server running the ReStreambackend (encoding and snapshot-generation)
A modern web-browser (Mozilla, Opera etc…)
Fig. ? Showing a
Monitoring the system
feedbox in ‘view’mode
As an example we will
use the NRK1-feedbox. On the picture you can
see the following:
Stream-name
Snapshot of what is currently streaming
Status of the encoder (On/ Off)
Which coverage-mode the stream uses (local,
national or global)
There are mainly two things that may be of
importance. To see if the encoder is doing its
job, check the ‘encoder status’. To check if the
encoder is working with the correct channel,
check the thumbnail.
Making changes to the system
To make some changes
to the stream you will
need to press the
‘options’button. The
feedbox will then ‘flip
around’ and you will be
presented with the
picture shown on the
Fig. ? Showing a
feedbox in
right side.
‘options’-mode.
The parameters that can be set is:
Name – This is the name of the stream. It
works as an identifier and will show up at the
top of the feedbox.
Address – This is the multicast address for the
stream.
Streaming (On/ Off) - Here you can turn the
sream on or off.
Coverage – Use this to set the time-to-live
value of the stream.
When your’re done setting parameters you
must click the ‘OK’-button. The feedbox will
then flip round again and you will se the
normal overview.
If you wish to cancel the changes, just press
the ‘cancel’-button. You will then be sent back
to the overview with no changes saved.
Note: You can not edit multiple streams at the
same time.