
How we built the new BBC Homepage - achalkley
http://www.bbc.co.uk/blogs/internet/entries/47a96d23-ae04-444e-808f-678e6809765d
======
mikecmpbll
Christ, so much hatred.

I like the desktop site, I like the mobile site, and I like and appreciate
that you're giving us an insight in to your tech stack and how content is
published.

Cheers beeb.

~~~
legoisbest
Does anyone know how much of this development is paid for by the UK tax payer
vs BBC worldwide profits from DVDs etc?

I'm not sure website development should be paid by UK tax payers TBH...

Maybe at least some of the reason for hate.

My main hate is the idiotic cookie policy which makes everything look ugly,
but I guess the EU is to blame there.

~~~
fredkingham
you mean by license fee payers.

Given the bbc is the 7th most popular site in the UK, and a clear leader over
other news sites, I don't see why it shouldn't be paid for by the license. It
fulfils its requirements outstandingly well.

(There are questions about whether given the move away from a tv based model
the bbc should be paid for by tax payers, and that's fair)

~~~
legoisbest
Yeah but every few years they seem to reprogram the entire website in
"whatever is most fashionable at the moment". I'm not sure that's a good use
of the publics money.

~~~
vertex-four
You'd rather we kept with outdated layouts like this[0], forever? Part of
rebuilding the website is updating the layout and usability of the website. In
order to keep the website usable, the people administering it have to have
better tools to organise content on it (as we all know, UX isn't just design,
you can't just write a new template over a site with bad UX to make it
perfect).

Developers use whatever is most reasonable to use at the time with an eye on
it hopefully lasting 5-10 years into the future - much of the BBC website
still runs on legacy, unmaintainable Perl, and they've learned their lesson
from that.

[0]
[http://news.bbc.co.uk/onthisday/hi/dates/stories/december/4/...](http://news.bbc.co.uk/onthisday/hi/dates/stories/december/4/newsid_3228000/3228207.stm)

~~~
lmm
I'm happy with that "outdated" layout yeah. It's pretty narrow on my screen -
but so's the new one. The information is clear and accessible - more so than
on the new one, actually. And I'd bet the filesize is smaller and the render
time shorter as well.

~~~
vertex-four
Fine - but don't be surprised when a decade after letting their website rot,
everyone's reading Murdoch's newspapers and the BBC has no reach.

~~~
lmm
The BBC was never supposed to compete in the race to the bottom. If anything I
would think the opposite - a plain site becomes the voice of authority.
Certainly in the print-newspaper world, the eyecatching, flashy designs are
the domain of the tabloids; the more serious newspapers are more restrained,
and the public trusts them more.

------
Twirrim
Hmm. While it's nice to push rendering out to clients for saving your server
CPU, that can lead to a suboptimal mobile experience, requiring more CPU and
battery power on the mobile device to work on the javascript and render the
page. There are other factors, for sure, but you want to be keeping client
side javascript down to a minimum.

Taking a quick spin through yslow in the mobile browser suggests they've got a
number of areas to improve on to make the time to screen significantly better
on mobile devices (even on a fast connection here it took several seconds to
even start showing me content, and several more before it had finally loaded
everything)

Given the world wide reach of the BBC, expecting high speed and low latency
networks seems like a bad idea. In the US, 3G & 4G typically see 90-100ms
latency per request. Mobile Yslow is reporting that they've got 21 javascript
scripts alone on the page. IIRC The android browser will limit itself to 4
threads retrieving content typically so that's (21/4 * 100ms) 525ms just lost
in latency requesting the javascript, let alone actually downloading it and
the overhead of the javascript renderer. It's also pulling in content from 21
different websites, so at the bare minimum that's 21 DNS calls being made
(with the same latency penalty!) A bunch of those are being done just to load
a single piece of content too, which is a little crazy.

Don't get me wrong, the site looks good.. it's just for a 'mobile-first'
experience, they seem to be missing the all important time-to-screen and
giving the mobile user a lot of work to do.

A useful tool from google for analysing the site for both mobile and desktop:
[https://developers.google.com/speed/pagespeed/insights/?url=...](https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fm.bbc.co.uk%2F)

and a good talk from last year's Google I/O conference on optimising the
mobile experience:
[https://www.youtube.com/watch?v=WrA85a4ZIaM](https://www.youtube.com/watch?v=WrA85a4ZIaM)

~~~
notahacker
Plus this is the only time I've ever seen "mobile first" interpreted quite so
literally (i.e. on a desktop with a reasonable connection the mobile
stylesheet loads before the main styles and content and is visible for just
long enough for the eyes to register the layout, producing a horrible "flash
of unstyled content" effect).

n.b. plenty of people looking at the BBC site are still being shown the old
style.

~~~
Twirrim
The main sites from my last job load the mobile view/content first, then load
in the desktop experience as appropriate (some are still in the process of
transitioning to the newer design). However they were done in such a way that
it shouldn't result in any jarring transitions. A couple of examples:

[https://portal.ehawaii.gov/](https://portal.ehawaii.gov/)
[http://energy.hawaii.gov/](http://energy.hawaii.gov/)

------
meesterdude
I do love when companies share this stuff. Thanks.

> Rather than using PHP or Java (that was the requisite of the Forge
> platform), we have chosen a non-blocking framework, NodeJS with the Express
> framework . This allows us to serve more simultaneous requests, increasing
> the performance of the application.

I don't doubt this is true, but its worth noting you can get good performance
out of a "blocking" framework too. Node.js does better than others in some
situations, but in this its not a snowflake, and is in some regards worse.

But I will criticize priorities: I think this is too much fad, not enough
practical. the experience is notably worse than the old site, and it seems
like they just threw buzzwords at their problems instead of really crafting a
solid solution.

I think where they're coming from, maybe this makes sense - they needed to
overshoot from their previous platform. But I think they'll find it
problematic in the long run and change some of their approaches and release a
new site, and that will be a good platform and serve their needs for a good
while.

~~~
mercurial
I must confess I'm quite surprised that they would get more performance out of
NodeJS than with a decent Java framework. Java has its problems, but it's
usually fast.

~~~
hokay
They do mention prototyping with Scala and Clojure. I also doubt NodeJS beat
the JVM out and out in performance. Maybe they went with Node because it is
easier to hire web developers that know javascript than it is to hire web
developers with knowledge of the JVM

~~~
mercurial
Java developers are not exactly a scarce commodity.

------
alexcason
There seems to be some kind of bird theme going on with their CSS classes.

    
    
      class="distinct-component-group container-buzzard"
      class="distinct-component-group container-pigeon"
      class="distinct-component-group container-macaw"
      class="robin sparrow-container"
      class="sparrow-container sparrow-columns"

------
Domenic_S
Tons of tech buzzwords, yet the blog intercepts middle-clicks. I want to open
your links in a new tab so I can read them when I'm done with your blog!

~~~
clarkdave
It's not just the blog - news.bbc.co.uk also intercepts middle clicks to
external sites. Middle clicks on links to other bbc.co.uk pages work fine
though.

Is it an accident or intentional? Anyone know?

~~~
CatsoCatsoCatso
I've noted this to them in their feedback forms before. It's been like that
for over a few months. If I recall correctly when the Guardian (uk) was
developing their current version under Beta the same problem came about for a
short while.

------
super-serial
It's like they monitored the front-page of HN everyday for a year, made a list
of the top mentioned technologies and then gave that list to their management.

Their manager said "Your goal is to write a blog post mentioning each one of
these technologies, and add links so it appears in dark-bold-blue text. If we
don't have a project using a trendy tech-stack... you bust your ass and get
something up and running."

The engineers balked... "but why?"

Then the boss said, "I'm tired of being ignored in 'Who's Hiring' on Hacker
News. We make this article and they'll all come begging us for jobs. At the
BBC we don't wait for news to come to us, we make the news. And THAT'S what we
call journalism kids."

~~~
ricardobeat
This is extremely offensive to the team that built this product. Why the hate?

~~~
davb
I've been using the new design on mobile for a while here and the user
experience is awful compared to the old design. Although the parent comment
might seem a bit patronising, I think he's right - they've focussed too much
on the technology and design fads.

Compared to the old site, there's a lot of "big text", too much of a focus on
images (when you drill down into the site) and less on text, and low
information density.

Worst of all (for me) - when loading on latest stable Chrome on Android, with
a very fast internet connection, the page appears loaded but as soon as I
scroll a number of the images disappear and the layout changes. I have to
scroll back to where I wanted to be. Lots of scripts, client-side rendering,
etc. It's overkill for a site whose focus should be content, not interaction.

While I'm sure the team built a technically impressive website, I don't think
they've built the "right thing" and I certainly don't think it's better than
the old one (from a user perspective).

~~~
mattmanser
The guardian have also similarly screwed up their mobile implementation, with
at one point they broke the back key because they had expandos that couldn't
remember their state.

But both these sites still suffer from "the flash", where it renders once, and
then renders again half a second lafer with everything moving. It's
disorientating and simply a bad UX.

Also the BBC used yo have this terrible experience for a few months where it
would flash up a load of code, but they finally seem to have fixed that.

IMO both these sites are presently advertising that the responsive trend sucks
ass.

I have started to realise that compared to the desktop sites it's almost
impossible to get information out of these mobile sites at anywhere near the
speed or information density I previously used to simply using the built in
pinch and zoom and desktop layouts.

Like you scan broadsheets and desktop layouts, but the mobile you get a big,
useless picture and a story title.

~~~
smcgivern
I like the design of the new BBC and Guardian websites, but I agree that if
they're aiming for mobile first, they still have a way to go.

In particular, 'the flash' you mentioned on The Guardian means that often,
instead of iOS 8 Safari scrolling when I try to scroll, it activates a link -
or worse, an ad! It's infuriating, and it's significantly less usable than
their old site in that regard.

For a truly bad mobile site, though, try going to Cricinfo:
[http://www.espncricinfo.com/](http://www.espncricinfo.com/) Go to an article,
then go back. Notice that:

1) Your horizontal scroll position in the article list is lost.

2) The page renders, then re-renders exactly the same (for me at least), with
a jump to the top of the page in between.

------
ndreckshage
This mentions using Node/Express to help with concurrency. Ok. But this also
mentions using 'isomorphic' javascript with React, and also not completely
reliant on cache. React.renderToString (and all other isomorphic options --
Rendr, etc) are synchronous and slow. (rendering a large page in React w/
static data would take ~600ms; whereas the same page with with Mustache in Go
for example would take ~30ms). End result, decreasing concurrency, and hurting
overall performance.

OP - can you shed any light on how this is actually impacting your
performance? Or maybe things that you had to do to get around the problem (ex
- details of 'module level' cache with Redis etc).

------
Numberwang
I have not yet tested the new mobile site, but if the design of the normal
site is anything to go by it will have been designed in hell by some teen
demon reading too much Kafka.

------
nerdy
Most of their tests take half a second each to run? Some examples: "The first
story displays an image and not an alt text attr if one is defined. (793ms)"
"The module banner color is BBC News Red (552ms)"

The 13 tests shown in the screenshot take an average of 577ms each, a total of
over 7.5 seconds. 13 simple tests with wild variance in execution time.
Checking a module _banner_ color? 42ms. Checking a module _background_ color?
552ms. So a 12x increase for checking a different color within a module?

Those tests are going to rot because of the expense of executing them and
they'll be discarded. Over a 500ms average per test just isn't sustainable,
particularly at the scale required for checking every conceivable kind of
background color.

~~~
meesterdude
I work on a rails codebase with some tests that take 20 seconds to run. The
entire suite is normally 5 minutes. I made a ruby gem to take the entire thing
down to 20 seconds, which is much better for flow.

But I agree those are definitely smelly tests with questionable value return,
and would not be surprised if they do indeed rot.

------
rentamir
Thanks for sharing the tech stack. Would love to read more about the curation
kit and the microservice approach.

~~~
defenestration
I agree. More corporates should give these insights and don't care for a bit
of bashing when they do.

------
weavie
They mention using BEM ([https://bem.info/](https://bem.info/)) Any idea what
it is? The site is not at all clear.

~~~
yalooze
CSSWizardy say it better than me: "BEM – meaning block, element, modifier – is
a front-end naming methodology thought up by the guys at Yandex. It is a smart
way of naming your CSS classes to give them more transparency and meaning to
other developers. They are far more strict and informative, which makes the
BEM naming convention ideal for teams of developers on larger projects that
might last a while." [http://csswizardry.com/2013/01/mindbemding-getting-your-
head...](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-
bem-syntax/)

But basically: agreed rules for how to name and format css to make it
maintainable and performant in big projects.

~~~
weavie
Thanks. I dont know why they couldnt just say that on their homepage!

~~~
andrewingram
Essentially, the BEM website is the worst possible rule for learning the
underlying principles of BEM (ie what makes it good), instead it's all about
their tool that attempts to manage it all for you.

------
thesehands
The BBC produce quite a few intereting write ups of their R&D process
alongside odd things they are hacking on here:
[http://www.bbc.co.uk/rd](http://www.bbc.co.uk/rd)

Well worth a read.

------
ggitau
Home page displays a bunch of javascript before rendering the rest of the
page. Doesn't happen all the time though.Maybe you guys might want to look
into that.

------
noso
It nice to know what is happening in the BBC and the tech they are using.
Additionally, It is appreciated they spend the time writing up what they have
done/achieved.

Rock on!

------
collyw
Actually it doesn't look too bad. Its similar enough to the old one it doesn't
seem like when Facebook upgrades and you feel lost. Shame the quality
reporting has gone down so much over the years.

------
kirkus
Amazing insight into how large organisations manage projects.

------
esalman
Reading the article reminded me of this:
[http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/)

------
smegel
I wonder to what extent they are still using Perl.

~~~
draegtun
The days of the BBC being a "Perl shop" have long gone.

But they do still use Perl, for e.g. BBC Genome is a new project written in
Perl -
[http://www.bbc.co.uk/blogs/internet/entries/cedd1f30-ac95-32...](http://www.bbc.co.uk/blogs/internet/entries/cedd1f30-ac95-3271-8e8a-78c07b9a4d23)

------
Fastidious
I love the BBC. Very interesting news, fairly balanced.

I hope I can play their videos on the new website, as before they all used to
require Flash.

------
bruceboughton
In Firefox 29.0.1, on the new BBC News homepage, wherever I click, it takes me
to same story, even if I click on whitespace.

------
bencollier49
The new "BBC News (Beta)" website is bloody ugly. They've gone for a "flat UI"
thing, but it looks so clumsy that it reminds me of the internet from before
people used gradients.

~~~
coob
Haha has the internet groupthink gone full circle on 'flat' now?

Tech is fashion whether we admit it or not.

------
confiscate
wow you use nodejs. how amazing that is

------
rashthedude
Pleasantly surprised how 'up-to-date'the beeb is.

------
iuguy
For those that aren't aware, the BBC has one of the worst cases of "Not
invented here" syndrome you'll ever see.

~~~
Cthulhu_
And yet all I see in the article is off-the-shelf libraries and frameworks,
and they came from a commercial CMS - where's the NIH?

~~~
bshimmin
You won't find any in that article, but the BBC did build their own jQuery
once upon a time (now long-since abandoned, of course, as many "NIH" projects
tend to be): [http://www.bbc.co.uk/glow/](http://www.bbc.co.uk/glow/)

------
sklogic
The new BBC page is barely usable. Not to mention that the new BBC android app
is thoroughly disgusting. Bring back the old one, please!!!

~~~
MartynX
What do you not like about their new Android app? I use it daily and greatly
prefer it to the old one.

~~~
Nexxxeh
Obviously the tone wouldn't do at HN, but this Reddit post in /r/unitedkingdom
mentions a lot of the problems with the new mobile site and the Android app.

[http://www.reddit.com/r/unitedkingdom/comments/2vymm2/does_a...](http://www.reddit.com/r/unitedkingdom/comments/2vymm2/does_anyone_else_think_the_new_bbc_mobile_page_is/)

Re: Android:

>Jackal___ 121 points 1 day ago >Their new Android app is very very slow to
load the news and uses a fuck load of background data.

>Quagers 72 points 1 day ago >Also it doesn't download the stories when you
hit refresh, just the headlines and then downloads the story when you click
the headline. Completely bloody useless on the tube!

