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.
I for one think it is fantastic the BBC are sharing this information and am liking the direction they are taking. It might not be perfect - I too have experienced some issues with the site over the past few months - but I'd much rather a BBC that looks to refresh itself and attempt to improve the experience for their users. Glitches happen - as long as they are fixed then it is all good with me.
Besides, the BBC amasses fortunes selling their programs abroad; Top Gear in its original form and in the formula license is shown in over 150 countries worldwide. And that's just one of their productions.
* BBCs insistence that it is unbiased is unrealistic imo (but not as outlandish as Fox's 'fair and balanced'). Its more of an ideal rather than something anyone/org can achieve. I admire their attempts to achieve some kind of balance, although sometimes the BBC can filter too much thats not 'centre-ground' (but less so than US networks).
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.
http://downloads.bbc.co.uk/annualreport/pdf/2013-14/BBC_Fina...
And the BBC's mission is "to enrich people's lives with programmes and services that inform, educate and entertain". Building a website to better distribute the content they've already paid for seems like a no-brainer.
Disclaimer: I used to work for a subsidiary of BBC Worldwide. Plenty of bureaucratic nuttiness in there, but this seems like one of their more sensible moves.
We pay for it mostly via the TV license fee. The BBC is not allowed to make money off UK citizens for any of its core services (TV, radio, news) - hence why some BBC links for the rest of the world are blocked for us, as they contain advertisements.
BBC News is primarily intended for a UK audience, so it makes sense that it's paid for by UK taxpayers. It's distribution infrastructure, just like the Freeview transmitters and the Freesat satellite - why wouldn't it be paid for by the taxpayer, who overwhelmingly demands online access to news and TV catch-up?
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)
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=...
and a good talk from last year's Google I/O conference on optimising the mobile experience: https://www.youtube.com/watch?v=WrA85a4ZIaM
http://www.webpagetest.org/result/150217_BB_Q71/1/details/
There's definitely plenty of room to optimize the time-to-first-render – in particular, switching to an async model would make a huge win since rendering is currently blocked by 6 stylesheets and 7 JavaScript files, most of which appear to be specific to certain content sections.
How true is that though? Given that native apps render client-side too. In a much more optimized, device-specific fasion, I admit, but still - that too is client-side rendering.
n.b. plenty of people looking at the BBC site are still being shown the old style.
Is it an accident or intentional? Anyone know?
How can they break something so basic?
They broke the middle-click? Good god, shut it down!
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."
Or perhaps those technologies were actually useful for them? I don't know, just a thought.
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).
> The new <sitename> design is terrible! Bring back the old one!
Whether it recognises the irony that it also moaned about the 'old one' when that came out, I'm not sure.
http://www.reddit.com/r/unitedkingdom/comments/2vymm2/does_a...
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!
2. Tiny cache, compared to the previous one, so totally useless offline
3. Intrusive UI
4. Much slower
> 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.
But basically: agreed rules for how to name and format css to make it maintainable and performant in big projects.
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.
But I agree those are definitely smelly tests with questionable value return, and would not be surprised if they do indeed rot.
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...
Tech is fashion whether we admit it or not.
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"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).
Well worth a read.
Rock on!
I hope I can play their videos on the new website, as before they all used to require Flash.