bbc - radio labs: how we make websites

5/20/2018 BBC - Radio Labs: How We Make Websites

1/13

17/04/2013 12:17BBC - Radio Labs: How we make websites

Page 1 of 13http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml

This page hasn't been updated for a while.We've left it here for reference More information

Share this pageShare

Facebook

Twitter

CommentsPost categories: Design

Michael Smethurst| 14:03 UK time, Thursday, 29 January

2009

Previous| Main| Next

How we make websites

Designing and building data driven dynamic webapplications the one web, domain driven, RESTful,open, linked data wayFor the past few months I've been touting a presentation around the BBC entitled 'How we

make websites'. It's a compendium of everything our team has learned from long years

developing/programmes, the recent work on/musicand the currently in development

/events.

As a warning there's very little original thinking in here. For those familiar with the concept

of one web, the importance of persistent URIs, REST, Domain Driven Designand Linked

Open Datait'll probably be old news. Possibly it's interesting to see all these threads t ied up

in one place!?! Maybe it's interesting to see them all from a user experience point of

view?!? Anyway, as ever, it's built on the thinkingandachievementsofmanycleverpeople

overmanyyearswhoaretoonumeroustomentionhere. Although obviously I'll makean

exception for Paul Clifford and TimBL. :)

The presentation is here and the (slightly) expanded text is below for the sake of

accessibility and Google.

How We Make Websites

iew more presentationsor uploadyour own. (tags: bbca&m)

About this blog

This is our new blog for BBC Radio Labs -

a place where we show some of our

prototypes for new sites and services.They are all at an early stage of

development and some of them might not

work quite right, some might look a bit

sketchy and they may never be taken any

further. They're what we call "betas".

We'll write about every new beta we

release on this blog so please play with

them and come back here to let us know

what you think. We'll also be writing

about other things we're working on, how

we do our work and anything else we

think you might be interested in.

For the latest updates across BBC blogs,visit the Blogs homepage.

Subscribe to Radio Labs

You can stay up to date with Radio Labs

via these feeds.

Radio Labs Feed (RSS)

Radio Labs Feed (ATOM)

If you aren't sure what RSS is you'll find

our beginner's guide to RSSuseful.

Other BBC blogs

BBC Backstage Blog

BBC Internet Blog

BBC Journalism Blog

BBC RAD Labs Blog

BBCi Labs Blog

Jump to more content from this blog
http://linkeddata.org/http://linkeddata.org/http://roy.gbiv.com/http://www.domainlanguage.com/about/ericevans.htmlhttp://tomheath.com/home/htmlhttp://www.bbc.co.uk/blogs/radiolabs/michael_smethurst/http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#jump_morehttp://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/help/web/mothballing/http://www.bbc.co.uk/http://www.bbc.co.uk/http://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#jump_morehttp://www.bbc.co.uk/blogs/bbcilabshttp://www.bbc.co.uk/blogs/rad/http://www.bbc.co.uk/blogs/journalismlabshttp://www.bbc.co.uk/blogs/bbcinternet/http://backstage.bbc.co.uk/news/http://news.bbc.co.uk/1/hi/help/3223484.stmhttp://www.bbc.co.uk/blogs/radiolabs/atom.xmlhttp://www.bbc.co.uk/blogs/radiolabs/rss.xmlhttp://www.bbc.co.uk/blogshttp://slideshare.net/tag/a-mhttp://slideshare.net/tag/bbchttp://www.slideshare.net/upload?type=presentationhttp://www.slideshare.net/http://www.slideshare.net/fantasticlife/how-we-make-websites-presentation?type=presentationhttp://dig.csail.mit.edu/breadcrumbs/node/215http://www.cookinrelaxin.com/http://interconnected.org/home/http://www.plasticbag.org/http://www.hackdiary.com/http://jonathan.tweed.name/http://twitter.com/rjollyhttp://whomwah.com/http://www.bbc.co.uk/blogs/bbcinternet/jamie_tetlow/http://www.metade.org/http://www.aelius.com/njh/http://derivadow.com/http://twitter.com/onpausehttp://twitter.com/hellomattyhttp://moustaki.org/http://tomheath.com/home/htmlhttp://www.domainlanguage.com/about/ericevans.htmlhttp://roy.gbiv.com/http://linkeddata.org/http://en.wikipedia.org/wiki/Domain-driven_designhttp://en.wikipedia.org/wiki/Representational_State_Transferhttp://www.w3.org/Provider/Style/URIhttp://www.w3.org/TR/mobile-bp/#OneWebhttp://www.bbc.co.uk/music/betahttp://www.bbc.co.uk/programmeshttp://www.bbc.co.uk/blogs/radiolabs/2009/02/better_audio_for_bbc_radio_onl.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/http://www.bbc.co.uk/blogs/radiolabs/2009/01/visual_radio_phase_1_final_tho.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/michael_smethurst/http://www.bbc.co.uk/blogs/radiolabs/michael_smethurst/http://www.bbc.co.uk/blogs/radiolabs/design/http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#commentshttp://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#http://www.bbc.co.uk/modules/sharetools/share?url=http%3A%2F%2Fwww.bbc.co.uk%2Fblogs%2Fradiolabs%2F2009%2F01%2Fhow_we_make_websites.shtml&appId=newshttp://www.bbc.co.uk/help/web/mothballing/


2/13



Explore the domainThis should be clear

from the business

requirements - it

might be food or

music or gardening

or...

Employ a domain

expert. Get them to

sketch their world

and sketch back at

them. Concentrate

on modelling real

(physical and

metaphysical)

thingsnot web

pages - try to blank

from your mind all

thoughts of the

resulting web site.

This work should never stop - you need to do this through the lifetime of the project as you

refine your understanding.

Identify your domain objects and the relationshipsbetween themAs you chat and

sketch with your

domain expert you

should build up a

picture of the types

of things they're

concerned with.

Make a list of these

objects.

As your knowledgeof the domain

increases you'll

build up a picture of

how your objects

interlink. You can

sketch basic entity

relationship

diagramswith your

domain expert and

keep sketching until the picture clears. Bear in mind you're trying to capture the domain

ontology - this isn't about sketching database schemas. The resulting domain model will

inform the rest of your project and should be one of the few artifactsyour project ever

creates.

Check your domain model with usersRun focus groups and speak to users. Get them to sketch their understanding of the domain

and again sketch back at them. After several round trips you should be able to synthesise

the expert model and the user model. User-centric design starts here - if you choose to

model things and relationships between those things that users can't easily comprehend no

amount of wireframes or personaes or storyboards will help you out.

Check to see if your website already deals with someof your domain objectsIf it does then reuse this functionality by linking to these pages - you don't want to mint

new URIs for existing objects. Having more than one page per thingconfuses users and

confuses Google. Try to think of your website as a coherent whole; not as a collection of

individual products. And as ever, don't expose your internal organisational structures

through your website. Users don't care about departments or reporting lines.
http://en.wikipedia.org/wiki/Entity-relationship_model


3/13



The glory will

always come from

building skyscrapers

- the real challenge

lies in decent town

planning. It's more

difficult to build new

services that stitch

into your site and

stitch into the webthan build shiny,

shrink wrapped, self

containedproducts.

Design yourdatabaseTranslate your

domain model into a

physical database

schema.

Source yourdataCheck if there are

business systems in

your organisation

able to populate

your schema. Check

if there are existing

websites outside

your organisation

you can use to

populate your

schema. Give

preferential

treatment to any

websites that offertheir data under a

liberal licencing

agreement - you

can buy in data to

help you slice and

dice your own data

but if you do this

you might not be

able to provide an

open data API

without giving away

the 3rd party's

business model. If

your organisation

AND an open data

website can provide

the data, consider

the danger in

minting new

identifiers for your own data - can you easily link out / can you easily get links in?

Data licensing is one of those areas that often gets ignored in project planning. If you fail to

consider it or get it wrong it can severely curtail your plans further down the line.

Pipe in your dataWhether you choose to use your business data or buy data or use open data you'll need a

way of piping it into your database schema. You'll probably have to reshape it to make itsuitable for publishing.

Make your models


4/13



In an MVC

framework your

models should

contain all your

business logic. This

mean they should

capture all the

constraints of your

database schema

plus all the extraconstraints implied

by your domain

model.

Design yourURI schemaYour URI schema

should follow

naturally from your

domain model. As

an example if you're

dealing with books

and a book can

have many authors

then

../:book/authors

should list all the

authors of that

book. At Audio and

Music we tend to

use large walls and

lots of post-its to

design our URIs.

Add some string to

show links and

journeys and there's

no need to everdraw another site

map.

This isn't just about

designing URIs for

resources you link

to - sometimes your

pages will be made

up of other

transcluded

resources - all of

these subsidiary

resources should be

addressable too. Itmeans you can

easily change your user experience layer by taking out transcluded resources and linking to

them instead or removing links and transcluding.

By making every nugget of content addressable you allow other sites to link to it, improve

your bookmarkability and increase your SEO - cf. an individual 'tweet'. Bear in mind that

some representations (specifically mobile) will need smaller, more fragmented

representations with lower page weight - designing your subsidiary resources to be

addressable allows you to easily deal with this requirement - transclude the content on a

desktop machine, link to it on a mobile.

This is where we begin to talk about one web and REST. Each thingshould be one resource

with one URI - the representation you get back (whether desktop HTML or mobile XHTML

MP or RDF or YAML or JSON) should depend on what your user agent asks for via contentnegotiation. It means I can send a link to a friend from a desktop machine, they can click

on that link from a mobile and they'll get back a representation appropriate to their device.
http://en.wikipedia.org/wiki/Content_negotiationhttp://en.wikipedia.org/wiki/Transclusion


5/13



Or vice versa. One

web with no mobile

ghetto.

It's important not to

confuse URI design

with site structure

and user journeys.

If you're used to

working on

hierarchical silo

sites then the URI

structure often

determines the

navigation. This isn't

true here. Think of

the individual

resources as tent

poles - the user

journeys are the

canvas that gets

draped over later.

It's nice if URIs arehuman readable.

It's also nice if

they're hackable.

It's an absolute

prerequisite that

they're persistent.

Don't sacrifice

persistence for the

sake of prettiness or

misguided SEO.

URIs are your

promise to the web

and your users - ifyou change them or

change their meaning you break that promise - links break, bookmarks break, citations

break and your search engine juice is lost.

Remember: Cool URIs don't change.

Make hello world pages for your primary domainobjectsFor now all they

need is an h1 with

the title of the

object.

Make helloworldpages foryourprimary

aggregationsFor now all they need is an h1 with the title of the aggregation and a linked list of things
http://www.w3.org/Provider/Style/URIhttp://www.slideshare.net/deanna.marbeck/url-design-for-information-architects-presentationhttp://derivadow.com/2008/11/27/permanent-web-ids-or-making-good-web-20-citizens/


6/13



aggregated.

Define thedata youneed tobuild eachof yourpagesTraditional

wireframes lumptogether data

requirements (via

annotations), page

layout and (by

implication)

document design.

It's best to split

these out into 3

distinct tasks. The

first task is to define

the data

requirements.

For each URI define

the data needed to

build all

representationsof

the thing. Just

because the HTML

representation

doesn't need to

show the updated

date doesn't mean

the RSS or Atom or

RDF don't need it.

Some resources will

transclude others.

There's no need to define the data required for these - just reference the transcluded

resource.

Build up your HTML pages and other representationsNow you know what

data you need you

can begin to surface

this in your

representations.

If you're working in

HTML make sure

you design yourdocument to be

semantically correct

and accessible. Try

not to think about

page layout - that's

the job of CSS not

markup. Document

design should be

independent of page

layout. In general

your page should be

structured into title, content, navigation - screen readers don't want to fight through

calendar tables etc to get to the content.

Add caching and search sitemapsKnowing what can be cached and for how long is a vital part of designing your user
http://www.pantos.org/atw/f-35367.html


7/13



experience. Cache

for too long and

pages go stale.

Don't cache for long

enough and you

send unnecessary

traffic across the

wires and place

extra strain on your

application.

Cached pages will

also be faster and

smoother to render

in a browser. And if

your users are

paying for data on a

mobile every extra

connection means

bigger bills, which is

definitely a user experience issue.

An example: if you're creating a schedule page for today's TV you want to cache for

performance reasons but you don't want to cache it for too long since schedules are subjectto change. But you can cache yesterday's schedule more aggressively and last week's

schedule more aggressively still.

Creating XML search sitemapshelps search engines know which bits of your site have been

updated. Which helps them to know which bits to re-index. Which helps to make your

content more findable.

Apply layout CSSAdd layout CSS to

your HTML pages.

Experiment with

different layouts for

your markup by

moving elementsaround the page.

You're wireframing!

Test anditerateYou should be

testing with real

users at every stage

of development but

it's particularly

important to

conduct usability

AND accessibilitytests now. It's like testing traditional wireframes but you're testing on the real application

with real application behaviours and real data (no lorum ipsum nonsense).

Sometimes the results of your testing will require changes to layout CSS, sometimes to

markup, sometimes to the data you need to surface and sometimes to the underlying

domain / data model. Bear in mind if you're using data from existing business systems

there may need to be heavy investment to make changes to that data model and employ

the staff to admin those changes. Occasionally it might even mean renegotiating contracts

with outside data providers. All design and usability issues are fixable - some just need

more lawyers than others : )

Apply decor CSSOver the top of your wireframe application you can now start to add visual design and

branding. This is exactly the same process as taking a paper wireframe and applying designtreatments over the top except you're mainly working in CSS.

Experiment with different treatments - see how far you can stretch the design with the
http://en.wikipedia.org/wiki/Sitemaps


8/13



markup given.

Sometimes you'll

need to add

additional markup to

hook your CSS off.

Now's the time to

add background

imagery for

headers, dividers,

buttons, list items

etc so best to open

Photoshop /

Illustrator to make

your design assets.

And testand iterateNever stop testing.

Remember that

personas are just

abstractions of

people - it's alwaysbetter to use real

people.

Ideally you should

be able to adjust

your code / markup

/ CSS to respond to

user requests. If

you can afford the

recruitment /

developer time

there's no better

way to test than

with a user sittingalongside a

developer - the

developer can react

to user requests,

tweak the

application and gain

instant feedback

without the

ambiguity that

sometimes comes

from test reports.

Again you should

accessibility test -

some of the design /

decor changes may

affect font sizes etc

- make sure your

users can still read

the page.

Add any JavaScript / AJAXBy designing your browsable site first and adding in Javascript / AJAX over the top you

stand a better chance of making an accessible web site - one that degrades gracefully.

As ever Google et al are your least able users - search bots don't like forms or JavaScript -

sites that degrade well for accessibility also degrade well for search engines.

Making every subsidiary resource addressable and providing these resources serialised as

XML or JSON makes adding AJAX relatively trivial.
http://www.37signals.com/svn/posts/690-ask-37signals-personas


9/13



Sign in

You'll probably need

to tweak your CSS

to adjust to life with

JavaScript / AJAX.

And testand iterateAgain test your site

for accessibility and

usability withJavaScript turned on

and off.

ContinueFollow the same

steps for each

development cycle.

Some development

cycles will just be

about surfacing new

views of the existing

domain model;

some will requireexpanding your

domain model.

Now you know your

domain model and

have made each

domain object

addressable layering

over new views and

more subtle user

journeys should be

trivial.

And keep testing!

Share this page

Share

Facebook

Twitter

Comments

or registerto comment.

1.At 23:1429th Jan 2009, trailbehindwrote:

I agree with all you have said, except for the bit about javascript/ajax. For a site like

mine (www.trailbehind.com), all we have is javascript and ajax, along with some data

embedded in the static pages for the search engines specifically.
http://www.bbc.co.uk/blogs/profile.shtml?userid=13804356http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=75116901#comment_75116901https://id.bbc.co.uk/users/register?target_resource=http%3A%2F%2Fidentity%2Fpolicies%2Fdna%2Fadult&ptrt=http%3A%2F%2Fwww.bbc.co.uk%2Fblogs%2Fradiolabs%2F2009%2F01%2Fhow_we_make_websites.shtml%23commentshttp://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml#http://www.bbc.co.uk/modules/sharetools/share?url=http%3A%2F%2Fwww.bbc.co.uk%2Fblogs%2Fradiolabs%2F2009%2F01%2Fhow_we_make_websites.shtml&appId=newshttps://id.bbc.co.uk/users/signin?target_resource=http%3A%2F%2Fidentity%2Fpolicies%2Fdna%2Fadult&ptrt=http%3A%2F%2Fwww.bbc.co.uk%2Fblogs%2Fradiolabs%2F2009%2F01%2Fhow_we_make_websites.shtml#comments


10/13



complain about this comment

2.At 02:4430th Jan 2009, ckorhonenwrote:


3.At 13:2631st Jan 2009, Alan Ogilviewrote:


4.At 23:161st Feb 2009, oudinechewrote:


5.At 01:042nd Feb 2009, dradfordwrote:

But the ajax/Javascript can't just be a tacked on thing. We have thousands of lines of

Javascript. It's fundamental.

@trailbehind I see what you are saying, but I think in most cases the approach outlinedworks - with most websites you need to consider your data and the views you create

atop of that data, which can be translated into your run-of-the-mill HTML/CSS.

If we look at your site, you have what looks like a google map with data - something

which could otherwise be represented as data in a table.

Where Ajax/JavaScript/Flash/Flex/Silverlight comes in is where you start considering

how the user will be interacting with the data. Not fundamental at any way to the data

structure or how the backend works.

Same goes for video players, or any other kind of rich interface.

In the case of the article, I'd say that whilst it is keeping with the principles of

progressive enhancement, it makes sense to start thinking about the need for these

rich-frontend-technologies a bit earlier, around the same time you are designing your

decor/layout CSS, since the frontend-experience will make or break your website.

In my days as a web-developer I remember giving a presentation at the Design Council

about 7 years ago with colleagues from information architecture and design. We

presented how important it is to make sure all areas are represented when starting to

build a website.

Michael's presentation, as I understand it, is from a stage further on from the beginning- as there obviously has to be input from engineering about what is possible.

By maintaining collaboration effort between the disciplines during development -

engineering, design, information architecture and the 'business' - successful delivery can

be achieved. In the same way as one wouldn't wish to end up with something that looks

fantastic, but performs so poorly that is unusable - we wouldn't want to have something

that has all the amazing engineering to make it top-performing but the interface is

unusable.

I remember working for an agency where we worked on a key implementation of a new

CMS system for a big organisation. If it hadn't been for engineering work with

information architecture we wouldn't have used all the facilities that CMS had available

as the engineers were able to interpret the CMS and explain those features to the

Information Architects. In the other direction - the IAs pushed the engineers to make

the CMS 'sing' so we could implement, what was described by the CMS company, the

most innovative use of their technology at the time.

Team work.

This comment was removed because the moderators found it broke the house rules. Explain.
http://www.bbc.co.uk/blogs/moderation.shtmlhttp://www.bbc.co.uk/blogs/profile.shtml?userid=13808974http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=75256106#comment_75256106http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=75254026&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=13808925http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=75254026#comment_75254026http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=75179216&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=11945512http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=75179216#comment_75179216http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=75117841&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=13804413http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=75117841#comment_75117841http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=75116901&s_start=1


11/13




6.At 23:1118th Feb 2009, Andy Mabbettwrote:


7.At 16:0019th Feb 2009, afrodigitalwrote:


8.At 09:5525th Feb 2009, tristanfwrote:


9.At 18:502nd Apr 2009, Monker09wrote:


10.At 17:133rd Jun 2009, bigalanbuchananwrote:

Hi there,

I was first introduced to domain driven software design about five or six years ago,

building enterprise software. A group of us started really getting into the Fowler ideas

through the PoEAA and Analysis Patterns books. It's great to see the methods applied to

web application design.

The BBC work is looking really good at the moment, with the Comet-based radio

visualisation, the iPlayer and the music beta site. Can't wait to see the new events site!!

Damien

web developer, triple j radio (Australian Broadcasting Corporation)

And not a single mention of microformats!

Nice work, Michael.

This is fascinating. Well done. Not only is the thinking lucid and logical -- the fact that

coherent, conscious thought happens in this aspect is very satisfying to know.

Question: WHO makes the decision(s) as to what content is publiched online -- and HOW

(i.e. on what bases)?

PS: E.g. particular bugbear of mine for years: Why does Moral Maze have neither a

podcast nor an archive?

PPS: From your exposition, it seems that you (info arch) go get the domain expert:

would that be upon your having been commissioned for the site etc?

@afrodigital - Decisions on what sites are built and what content is published are

generally taken by a combined team of technical staff (who design and build things) and

editorial staff (who work closely with the radio networks and audiences) based on our

strategy and the requirements of the radio networks.

As you suggest, this will happen before the process described above, but it won't

necessarily be a completely different set of people.

Hi there,

I liked your clearly presented account, you make it sound so simple ! I would add that

you should bear in mind rendering issues between browsers especially internet explorer

because it is riddled with bugs.

Monker

Link Building Specialists
http://www.acornsuperlinks.com/http://www.bbc.co.uk/blogs/profile.shtml?userid=13924376http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=80996438#comment_80996438http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=78042907&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=13899029http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=78042907#comment_78042907http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=76413151&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=8061455http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=76413151#comment_76413151http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=76157981&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=13838299http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=76157981#comment_76157981http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=76132652&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=3293774http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=76132652#comment_76132652http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=75256106&s_start=1


12/13




11.At 13:5226th Jun 2009, HughDPwrote:


12.At 12:598th Sep 2009, Saurav_Rimalwrote:


13.At 18:088th Sep 2009, dextacy10-13wrote:


14.At 19:469th Sep 2009, Jon-Jaunceywrote:


15.At 11:4611th Nov 2009, Mark Croninwrote:


16.At 20:0412th Nov 2009, i_amGeorge123wrote:


17.At 22:1028th Dec 2009, Ticowrote:

Although I enjoy making my websites at home it would be great to be part of such a

huge organisation like BBC and be part of the web design team. I'm jealous.

Alan

Interesting article but why do the BBC (and many other sites) still insist on fixed width

layouts?

Screens are getting wider and wider yet many sites still use a thin strip of content down

the middle.


Another good read, "If you're working in HTML make sure you design your document to

be semantically correct and accessible" In regards to this section I read a couple of

articles in dot net magazine one about reset browser styling to help ensure cross

platform usability and another about printing out a design of the page with the most

complex layout and then writing the html elements such as "img, h1, h2, a " on the page

ignoring elements such as div so as to guage the best way to create a uniform site

layout with tidy css pages. The articles was in dot net may 2009 entitled "slicing like a

pro" and "css/reset documents".

Regards

James Myers

Website Designer


This is awesome stuff. I have been web building for quite a while now, and i would love

to get into the nooks and crannies of the BBC site. Dynamic pages are always going to

be the way forward, and learning things like ASP and PHP are a given.

I'm just going to enjoy my Egypt holidays, until i must return to the dreary office from

whence i came! :)

http://www.bbc.co.uk/blogs/moderation.shtmlhttp://www.tropicalsky.co.uk/Egypt_holidays.htmhttp://www.bbc.co.uk/blogs/moderation.shtmlhttp://www.webdesign-midlands.co.uk/http://www.bbc.co.uk/blogs/moderation.shtmlhttp://www.bbc.co.uk/blogs/profile.shtml?userid=14276162http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=90306191#comment_90306191http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=88401640&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=14163555http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=88401640#comment_88401640http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=88328683&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=14201715http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=88328683#comment_88328683http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=85536848&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=14125842http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=85536848#comment_85536848http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=85485007&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=14130051http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=85485007#comment_85485007http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=85466241&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=14129168http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=85466241#comment_85466241http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=82096859&s_start=1http://www.bbc.co.uk/blogs/profile.shtml?userid=4428100http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml?postId=82096859#comment_82096859http://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=80996438&s_start=1


13/13




This entry is now closed for comments

Topical posts on this blog

What happens to The Proms

after the Royal Albert Hall?

(13)

Podcast OPML - change (5)

RealMedia - follow up (30)

RealMedia - an update (76)

BBC Radio Waves - exploring

what we play (4)

Immersive audio for Planet

B (8)

Windows Media - Listen Again

- Update (25)

What's your musical taste? (5)

Windows Media - Listen Again

- Update 2 (11)

More Mooso (2)

Archives

Past twelve months

October 2010 (1)

April 2010 (1)

March 2010 (1)

January 2010 (1)

December 2009 (3)

November 2009 (2)

October 2009 (7)

September 2009 (1)

August 2009 (2)

July 2009 (2)

June 2009 (4)

May 2009 (1)

complete archive

Categories

These are some of the popular

topics this blog covers.

betaconferencesdesignflash

gaminglinkslive eventsmobile

musicprogrammesr&d

radiorealmediarealplayer

streamingtechnologyvistrial

visualising radiowindows media

Latest contributors

Jem Stone

Tristan Ferne

Chris Bowley

Duncan Robertson

Michael Smethurst

Alan Ogilvie

Mark Kortekaas

Caleb Knightley

More from this blog...


Mobile site Terms of Use About the BBC

Advertise With Us Privacy BBC Help

Ad Choices Cookies Accessibility Help

Parental Guidance Contact UsBBC 2013The BBC is not responsible for the

content of external sites. Read more.
http://www.bbc.co.uk/help/web/links/http://www.bbc.co.uk/feedback/http://www.bbc.co.uk/guidance/http://www.bbc.co.uk/accessibility/http://www.bbc.co.uk/privacy/bbc-cookies-policy.shtmlhttp://www.bbc.co.uk/bbc.com/ad-choices/http://www.bbc.co.uk/help/http://www.bbc.co.uk/privacy/http://advertising.bbcworldwide.com/http://www.bbc.co.uk/aboutthebbc/http://www.bbc.co.uk/terms/http://m.bbc.co.uk/http://www.bbc.co.uk/blogs/moderation.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/caleb_knightley/http://www.bbc.co.uk/blogs/radiolabs/mark_kortekaas/http://www.bbc.co.uk/blogs/radiolabs/alan_ogilvie/http://www.bbc.co.uk/blogs/radiolabs/michael_smethurst/http://www.bbc.co.uk/blogs/radiolabs/duncan_robertson/http://www.bbc.co.uk/blogs/radiolabs/chris_bowley/http://www.bbc.co.uk/blogs/radiolabs/tristan_ferne/http://www.bbc.co.uk/blogs/radiolabs/jem_stone/http://www.bbc.co.uk/blogs/radiolabs/windows_media/http://www.bbc.co.uk/blogs/radiolabs/visualising_radio/http://www.bbc.co.uk/blogs/radiolabs/vistrial/http://www.bbc.co.uk/blogs/radiolabs/technology/http://www.bbc.co.uk/blogs/radiolabs/streaming/http://www.bbc.co.uk/blogs/radiolabs/realplayer/http://www.bbc.co.uk/blogs/radiolabs/realmedia/http://www.bbc.co.uk/blogs/radiolabs/radio/http://www.bbc.co.uk/blogs/radiolabs/rd/http://www.bbc.co.uk/blogs/radiolabs/programmes/http://www.bbc.co.uk/blogs/radiolabs/music/http://www.bbc.co.uk/blogs/radiolabs/mobile/http://www.bbc.co.uk/blogs/radiolabs/live_events/http://www.bbc.co.uk/blogs/radiolabs/links/http://www.bbc.co.uk/blogs/radiolabs/gaming/http://www.bbc.co.uk/blogs/radiolabs/flash/http://www.bbc.co.uk/blogs/radiolabs/design/http://www.bbc.co.uk/blogs/radiolabs/conferences/http://www.bbc.co.uk/blogs/radiolabs/beta/http://www.bbc.co.uk/blogs/radiolabs/archives.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2009/05/http://www.bbc.co.uk/blogs/radiolabs/2009/06/http://www.bbc.co.uk/blogs/radiolabs/2009/07/http://www.bbc.co.uk/blogs/radiolabs/2009/08/http://www.bbc.co.uk/blogs/radiolabs/2009/09/http://www.bbc.co.uk/blogs/radiolabs/2009/10/http://www.bbc.co.uk/blogs/radiolabs/2009/11/http://www.bbc.co.uk/blogs/radiolabs/2009/12/http://www.bbc.co.uk/blogs/radiolabs/2010/01/http://www.bbc.co.uk/blogs/radiolabs/2010/03/http://www.bbc.co.uk/blogs/radiolabs/2010/04/http://www.bbc.co.uk/blogs/radiolabs/2010/10/http://www.bbc.co.uk/blogs/radiolabs/2009/12/more_mooso.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2010/01/wma_listen_again2.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2009/10/whats_your_musical_taste.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2009/12/wma_listen_again.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2009/10/binaural_audio_for_planet_b.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2009/10/bbc_radio_waves_visualising_mu.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2009/10/realmedia_an_update.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2010/03/realmedia_follow_up.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2010/04/podcast_opml_change.shtmlhttp://www.bbc.co.uk/blogs/radiolabs/2009/10/what_happens_to_the_proms_afte.shtmlhttp://www.bbc.co.uk/dna/blog100/comments/UserComplaintPage?PostID=90306191&s_start=1

bbc - radio labs: how we make websites

Documents

bbc radio labs

bbc radio labs

radio labsvia

radio labsyou

new blog

new sites

new beta werelease

blogs homepage