london fashion week - part 1 of 2: overview and preparation

[chris raettig <chris@raettig.org>]

[uploaded via a friends adsl connection]


london fashion week meant another live webcam event on behalf
of showstudio.com.  these events are the most visible part of my role
at show - the tip of the iceberg visible above the water. in the past
i've either journalled these occurences too late for me to remember
much of what they entailed, or not at all. therefore i would like to
get down as much of what happened on monday and tuesday as i can
recall - while its still fresh in my head.

in as much as my online journal is supposed to be a record of my
thoughts, feelings and actions (a life online) it self evidently
needs to include my bizlife. especially given the disproportionate 
amount of time i spend working. sometimes that is harder to do than
others given issues of confidentiality, trade secret and tact. however
i think the process and procedure behind showstudio live events is
something i can discuss more or less openly without landing myself
in choppy waters.

because i have rather a lot to say, i will divide this into two parts.
this first part is an overview of live events generally, and the
specifics relating to this one. including information about my
preparation for the day of the event. part two will focus on the
events on the day itself and my thoughts surrounding that.


my experience with webcams is a large part of what got me hired
by showstudio. though i have since taken on the technical directorship.
the webcams themselves are a reasonably small part even of my
role in the live webcam events we stage. primarily it is about logistics
and networking (both digital, and personal). 

these live events appeal to the extreme nature of my personality,
which has been amply documented in the past. the period of time spent
working on them is very dense, with a lot of things to do in a relatively
short space of time. it is intensive. this is probably why i forget
many of the things i might otherwise choose to journal. they are
extremely stressful, but equally rewarding. deeply challenging and
hard work, whilst at the same time being a lot of fun and often quite surreal.
there is always an amazing buzz in the air, which i love. working
to high pressure deadlines in amazing environments surrounded by the
fashion elite - this is about as glamorous as computer programming gets.
in short; i get a kick out of live events.

they begin with a concept. in this case it was to webcast the fashion
show being put on by boudicca - a popular young fashion house - so
that it could be viewed by all of the people wishing to see it who
were not able to be accommodated by the venue. the value in doing
this lies in the time criticality of fashion journalism. it also
affords an apportunity to obtain information about our audience.

on the web there are essentially three ways a visitor can pay for
content. they can pay with cash, they can pay with attention (one
of the most scarce commodities in the post mtv generation - and possibly
the most valuable. attention *is* money), or they can pay-by-profile;
giving information about themselves in exchange for content. this 
last currency is extremely valuable. knowing your customers offers
an enormous array of benefits, and a live event is a good way of
encouraging that transaction. 

i do not art direct these events. my eye for the aesthetic is utterly
untrained when compared to the complete masters of the field with
whom i work. people whose skill and judgement i have a total respect for.
the positioning of the cameras and the particulars of lighting i leave
to those with a calling for it. my job is to facilitate. whilst i'm 
usually involved in refining the concept and often grounding it in
reality, my role is to turn that concept into a reality. to make it
happen. and to make sure it goes as smoothly and painlessly as
possible, causing minimal disruption to all of the other people
trying to get their jobs done at the same time.

i am at the same time the most important person at an event, and
the least. in any commercial role you need (personally) to 
add value. that is, the value of having you *in* a situation, must
exceed that of you not being there. otherwise you are what
yahoo!'s chief solutions officer (and recent author of a very
good book which discusses this; love is the killer app) tim sanders
calls a 'value vampire'. there are an enormous range of ways
to add value, and most of these center around your intangibles.
(make up your own double entendre here). without trying to
sound pompous (i mean that), i am the only even remotely net-savvy
person at these events. i'm the only person there who combines a knowledge
of programming, unix, networking, bandwidth esoterica, webcam
management, the generalities of photography and lighting and the
logistical minefield of such events. my intangibles aside, it is
a situation where i can offer concrete value. the benefit of me
being in the situation is that the event can happen. the (commercial)
disadvantage of me dropping dead at lunchtime, is that it just couldn't. 
the only reason i mention this, is that there is some part of me
that thrives on bringing unique skills to a situation. 

a brief tangent; most of the projects (i'm not just talking about 
showstudio here) that hold my interest are those that involve applying 
one thing to another. this is the kind of thing i get very passionate 
about. computer programming is itself (mostly) disinteresting. but apply 
that to an unrelated area; running a business, or creating artwork. then
it starts to get interesting. most of my side-projects revolve
around applying the one deep-and-narrow thing i have skills in and
am good at to another area i'm less familiar with. 

i'm also the least important person, and this is something i have
to bear in mind at all times when working on an event. i'm
a facilitator, working in what is already a high-pressure environment.
fashion people do not understand the technical. my job as a technician
is to get things running with the least possible disruption to
everything else that is happening. highly stressed fashion bods do
not need technicians who create more work than they're worth. i'm
quite mindful of the fact that a reasonable portion of my job is
to not fuck anybody off. i'm slowly learning to be meek, and
quietly competent. 


the process behind an event involves firstly making sure i have a full 
understanding of the concept, and what everybody involved wants to achieve. 

i must then liaise with all of the different parties involved, ensuring
nobody is unaware of the implications surrounding what we will be
doing. i have learnt through previous events what questions i need
to get answers to in advance. what equipment i need to ensure is
on hand, what help i will require to pull off a successful event.

an event lives or dies on its planning. because when you're doing
live events, the deadline is immovable. failure is not an option. and
time is a scarce commodity on the day itself. to make the whole
thing appear to be easy, i must spend the previous day working hard
on planning.

if possible i obtain floor plans of the venue, as in this case. 
i create diagrams of how everything must be set out. lists of
all the equipment required, checked off as i make sure we have it. 
i draw up my own itinerary for the day itself; listing all of the
things that i need to do, to make sure i dont forget anything in the
heat of the moment. i carefully work out mini-deadlines for throughout
the day, to make sure we're on schedule. i write up a contact sheet
with the details of everybody who has some tangential involvement
with the event, and how to get hold of them. 

i need to make sure i'm aware of which other sets of people will be
on site, and what times they will be arriving. if there is a liaison
for the venue, i need to know their name and how to get hold of them
in a hurry. if there is an electrical contractor, they will need to
know how many sockets i'll need, where they must be located and
what ampage i anticipate using. this saves it from being an
unpleasant surprise for them once things are underway. in return i 
need to know at what time i can expect those sockets to be active.
if there is a communications of technical contact for the venue,
an introduction ahead of time often removes a lot of stress. with
any luck i will have visited the venue a few days earlier and this
often alerts me to what particular challenges the project will offer.

there are any number of things which can (and do!) go wrong on the day.
experience has taught me to anticipate as many of these things as
i can. to have backup plans for my backup plans. every eventuality
that can be anticipated and planned for, must be. because there are
a million other factors which cant be anticipated or planned for,
and time must be preserved for dealing with the unexpected. its fine
(i think) to hit the ceiling when something catastrophic happens.
but then you need to solve the problem. whatever it is. because
failure is not an option. and people are looking to you for solutions.
everything is in the planning. because even with the best planning
in the world, the day itself requires alertness, thinking on your feet
plus rapid problem solving and improvisation skills. resourcefulness
is next to godliness.

this was what i spent monday doing; meticulously preparing. making lists.
doing anything which could feasibly be done before the day of the event.

in this case it resulted in the realisation that we needed a mechanism
for capturing images on demand, rather than on a set time-lapse as
is usually the case. this was for two reasons.

firstly; the event was to be a short one. important action could be 
missed during the refresh interval. whilst we cant elliminate the
requirement for time-delayed refreshes we could at least implement
a mechanism for allowing ourselves to choose on the fly when it
would happen. 

secondly; one of our webcams was to be placed at the end of the catwalk.
the traditional fashion shot. because of the length of the catwalk, and
the depth of field the camera has, it was possible that on a statically
timed refresh we would capture unfocused shots of models at the far
end of the catwalk when what people really want to see is models at
the front of the catwalk in clear-focus. 

i spent some time on monday evening (finishing very early on tuesday
morning) writing some code to get around this. i created a
gtk app in perl to allow the art director for the event to choose
manually when images would be captured by our main camera (cam-1). 
every time he hit an oversized button positioned beneath a 10fps
video-stream from the camera, it would grab an image from the webcam,
perform the required preprocessing (save a copy to our local image
archive, reduce the image dimensions, rotate the image depending on
what angle the cam was mounted at, optimize the colour palette) then
upload the image to our live webserver. 

the way to get around the browsers static refresh time (without
resorting to flash) is quite simple. the html frame containing the
jpeg image is changed to have a 0 second refresh interval, instead
of the 30 or 10 second refresh we had in place already. the call
to both the html and the jpeg are actually requests for perl scripts
which essentially wrapper the html and the jpeg. what you end up
with is a page that tries to refresh itself as soon as it has loaded.
the perl scripts on the server can then delay sending a response back
until the moment a new image hits the server from the webcam. as
long as you dont send the content-type header back to the browser,
or exceed the apache timeout you have a pretty reliable way of forcing
variable rate refresh. (or at least, the best such system i could
implement at short notice). 

we also wanted another way to enhance the experience for people watching
over the internet. the cameras, after all, offer a limited glimse of
the action. our plan was to have a member of the press seated in the front
row. armed with a laptop computer, typing a running commentary to
be displayed over the web as a 'textstream' beneath the webcam images themselves.
the most straightforward way to enable this was by running a webserver
and a basic perl script from the primary unix server we were taking along.
the journalist would connect to this server via their web browser and
be presented with a simple form into which they could type a line of
text and hit 'return'. the server would then generate an html page containing
their text and upload it to the live webserver from where it could be
refreshed in a similar method to the images before allowing another
line of text to be entered. sometimes the simplest solutions are the best.
they create less opportunity for things to go wrong.
 

with this system in place i finally attempted to sleep at around 2.30am.
though my insomnia was fuelled by my excitement and mild nerves. 



(see part two)