The
Challenge
1. To use a mix of 'genuinely-domestic-level' technologies
to bring Lorenzo's climb right here to us (wherever we are
in the world). So no satellite or video phones, a genuinely
tight budget and very short timescale!
2. To test (in extremis) Macromedia's
new MX serving of AV technologies.
Critical Research Topics
Presence - Where are you (physically and virtually)? And
what "state" are you in?
Telepresence - Can you and I share this experience over a
distance?
The Technologies
 |
The
Phone
What is it? A Nokia
7650 GSM/GPRS phone with an integrated camera. A new-to-the-high-street
item costing about 200gbp.
How does it work? Lorenzo
will take a picture or two before he makes a voice call
and mail them in to the server. If he labels the picture
(in the email subject line) with his height above sea
level (via a pre-agreed code) then the Flash movie can
not only show the latest picture but put a dot on his
current map location. |
 |
The
Phone Server
What is it? A PhonePro
Server - running on an Apple
Macintosh with a GeoPort modem and executing sundry AppleScripts
to communicate with the voice processing and file transport
apps.
How does it work? Lorenzo
calls in, the phone server will pick up his call. If someone
is in the lab, then you will hear the conversation, otherwise
you will just hear the 'audio diary' of the climb. The
call will be fed to the live broadcast Flash 6 client,
and converted for instant-replay. After he hangs up, the
phone server will produce an MP3 version and upload it
to the web server. So even if you miss the live call,
you can hear what he says within seconds of him having
said it, anyway! |
 |
The Client
What is it? A Macromedia
Flash 6 movie which can handle both external data and
connections to the Macromedia
Flash Communication Server MX.
How does it work? The
Flash movie picks up data, like location, latest pictures,
latest audio messages and displays it dynamically and
automatically. Flash allows us to do all this in a single
application and handle the data flexibly and quickly.
To speed development we decided to make use of Macromedia's
free pre-built Comunication Components available from
their site.
These are drag and drop items that allow a connection
to be made with a suitably configured Macromedia Flash
Communication Server MX.
Five were chosen for this project:
• A log on component
• A chat component
• A colour picker component
• A status component
• A streaming audio/video component
These are relatively easy to use in their standard format,
although somewhat harder to re-configure or re-skin
to any major degree, possibly because we were using
the available downloads. A simple reworking of some
of the component's assets was however used to conform
to the overall page design. The streaming component
was positioned off-stage as only it's audio streaming
function was required.
A painting of the Matterhorn formed the background to
the Flash movie. Positioned on this, along the proposed
route, are a series of movies containing a 'dot' and
a button. These only appear if a picture has been sent
from the location they mark and provide the user with
a way of viewing the pictures in context. The url's
to the pictures are dynamically updated for each button.
The latest photograph sent from the Matterhorn is inserted
at the time the user first loads the page. If an older
photograph is chosen to be viewed by the user, a button
appears allowing the reloading of the latest picture.
This is achieved by comparing the picture's file name
which is 'time-stamped'.
The live audio message from the Matterhorn is streamed
straight into the browser via the Flash component. It
is recorded at the same time 'at source' and an MP3
file created. This information is sent to the user's
Flash movie. When new sound information is received,
a button with the correct url appears in the 'Audio
Replay' submovie. This movie contains a dynamic list
of the ten most recent sound files. When the user clicks
on a button, the main streaming audio is muted and the
recording streams from the server. This movie also contains
a 'Mute All' button for the user's convenience.
The dynamic nature of the Flash content is 'driven'
by the periodic request for a string of variables. If
a 'key' variable has altered within this file, then
all the relevant variables and sub-movies contained
within the Flash are updated.
The result is a good 'fit-for-purpose' application created
within the project's time constraints, greatly aided
by the Macromedia Communication Components. Given more
time the interface could be made more 'flashy' and 'animated',
although of course the user would have to download the
extra graphics...
|
 |
Chatlogger
and Broadcaster Flash Movies
What is it? Two Flash
movies running in the background back at KMi.
How does it work? The
Chatlogger Flash movie monitored the 'Chat' progress.
When a predefined number of lines of text was reached
an auto save facility was triggered to save the chat text
to the chat log file that was accessible as a html page
from a link on the main web page. It also provided a way
to clear unwanted chat.
The Broadcaster Flash movie containing suitable Macromedia
Communication Components, took the live audio from the
telephone and 'broadcast' it those listening on-line.
Interestingly we had to remove the 'Chat Window' Component
from this movie as its inclusion interfered with the audio
stream making the sound break-up. |
 |
The
AV Server
What is it? A Macromedia
Flash Communication Server MX (maximum of 500 connections).
How does it work? The
Server handles all the communication data between the
clients and server. In this particular project five of
it's component features were utilized; the live sound
broadcast, the client logon process, the chat facility,
the chat colour picker and the connection information
icon. |
 |
The Web Server
What is it? An Apache
web server with PHP
installed, running on a Windows
2000 Server.
How does it work? Most
of the clever stuff on the server is driven by PHP scripts
which permit the dynamic generation of web pages and
the live updating of the client's Flash movie with the
latest picture and audio status.
The server is configured to regularly run a PHP script
which retrieves emails from the webcasts email account.
If a new email has been received with a picture attached
(i.e. sent from the Nokia 7650 phone which Lorenzo is
using during his ascent of the Matterhorn), the PHP
saves the image, creates thumbnail copies, and updates
a status text file. The client's Flash movie regularly
accesses another PHP script on the server, which gathers
together the latest information (i.e. pictures, audio
file lists etc) and returns this to the client's Flash
movie.
Another function performed by PHP scripts is to create
the 'Chat History'. A Flash movie was created specifically
for this purpose. This Flash movie is connected to the
webcast via the Flash Communications Server MX, and
as a result receives all the Chat messages like any
normal client, however, it also regularly calls a PHP
script with the latest messages. This PHP script appends
the new messages to a text file to create a permanent
record of the chat.
Other PHP scripts are used to dynamically generate the
'Gallery' of photographs, 'Phone Replays' and 'Chat
History' web pages.
|
Some obvious questions
Why
didn't we use video?
Are
you kidding! Video over GSM!?! Not in my current dreams
(yet).
Seriously, the data-rate we are likely to get for the piccies
will mean that each photo will take maybe 1-2 minutes to
reach us ... we need all the available datarate of live
for voice. We werent confident that GPRS will work on the
mountain (keeping our fingers crossed about GSM connection!)
and we aint holding our breath for 3G features ... but one
day ...
Why
didn't we use the classical KMi Stadium technologies for this
event?
For
the challenge! We thought that, if we were going to do this,
we should try to stretch Macromedia's new MX technologies
- which are actually closely related to the systems we have
based our own techhnologies upon. In the MX release of their
servers, Macromedia have stressed the (smaller scale) multi-party
features - esp. plug and play multi-party audio/video. This
is potentially so cool, that it was worth setting aside
our own scalable broadcast systems for this gig, to see
what MX could do for us - right out of the box! Actually,
in our development we found that this particular application
was much more suited to our own KMi
Stadium architecture, but we persevered and are extremely
pleased with the results!
Why
the Nokia phone?
It
is a single unit (very important not to muck about with
lots of fiddly extra plug-together pieces for a climber),
released in the UK the week before the actual climb. The
lens aint great - but hey, it is a phone! - and we felt
that good lighting up the mountain might compensate for
this. Also, it is robust, good battery life and simple to
use - especially, it involves remarkably few button-presses
to send a photo. Definitely, a must have piece of kit -
which I can already think of a dozen other cool uses for
- (I just need to figure how to switch off that annoying
and cheezy photo-click sound it makes when you hit the capture-photo
button ;-). Initially, I liked the 'totally handsfree with
bluetooth-headset' concept for 'talking with ones hands
full of rock'; but then this just sounded way too dangerous!
So we compromised, and asked him to only consider using
it when he could relax and was quite, quite safe!
Why
use a Phone Server?
Lorenzo
will be setting off up the mountain (and have some interesting
things to say) when all of us back home will be asleep!
We need to capture what he is up to on the server (for when
we wake) AND send it out live (automatically) for those
folks in the world who aint as sleepy as us. We have successfully
used a variety of phone-the-web servers for other projects
such as 'read the news' systems for Rostra
and most especially for 'yearbook entries' in the Virtual
Degree Ceremony. So a system that could answer the phone
for Lorenzo, take his chat and pump it to the live server
plus archive it to the web, was a piece of cake.
Click here to visit the
site |
