Can you ditch the 'breaking news' whilst you're at it too please? It's never really 'breaking' and is usually the headline of the landing page anyway. Usability wise, it's as bad as a pop-up ad. Like this, for example:
The breaking news banner is a source of much internal conflict, at least within the engineering teams. I think most people agree that it's too big, and most people also agree that it's over-used. Unfortunately it's one of those things that editorial will not back down on — they must be able to push their breaking news to people, and it must be prominent (and therefore quite intrusive).
There is a small improvement to the banner on the new front page (/news/0), which is that it's about 4 pixels shorter, and it's now grey instead of black which I think is much less abrasive.
I just realized that wasn't an ad; I've never read the text because the placement/intrusiveness triggered my ad blindness, I've blocked it with ublock as well.
Aye, I use Ublock Origin to block more than just ads.
It's also handy for the comment sections on newspapers, sections of news sites you are never gonna click/read (in my case sport) and comments on youtube.
Is there no way you can at least track that a user has already been exposed to the breaking news (banner or article etc) and stop re-showing it? I always see it after I've already hit the homepage, seen the 'breaking news' and then gone to somewhere else on the site and then 'breaking news' banner all over again.
It reminds me of the early 2000s when websites would initiate a pop-up ad and the first thing I would do is automatically close it without looking. Thankfully browser makers stepped in and blocked them automatically. That's my hope. That news outlets will spam the feature so much that web browsers will make it easy to switch them off.
Won't happen. Pop-ups were a specific browser API and could be easily turned off without affecting anything else, banners are just content and can't be singled out by the browsers (unless by an adblock-type arms race).
...or maybe you could decide what you wanted as 'breaking news', so if you did not want to know the football results because you are watching the game later, then you could un-tick 'sports'.
This could be really useful for onboarding people, once onboard they could set up alerts for topics or tick 'follow this story' if for instance they read about someone being brought to trial and they wanted to know the sentencing or even what crimes get committed five years hence once the culprit is out of jail.
Things in the news and the weather could then be pushed/pulled from an app.
As well as topics for 'breaking news' there could also be a colour coded level so if you don't really care about some unknown unknowns getting droned out of existence in far-off-istan (in a 'yellow' terror threat incident) then you don't get an alert for it. Meanwhile, if you are British and some idiot kills people outside parliament then that one pops up as 'breaking news' with no hesitation.
Tsunami alerts are probably handy as 'breaking news', it would be annoying to die in some massive flood due to having turned off the 'breaking news' wholesale just because you had no interest in the French election or 'Frexit'.
I think that they need to just be a bit more imaginative with the feature so that it works for all stakeholders, the editorial department, the reads and everyone in between, up to and including No. 10.
You're doing God's work and a national service that is IMHO worthy of a knighthood, the BBC front page is one of those rare places where a few little engineering cogs can really make a huge difference. Keep up the good fight! Thanks from all of us -- the UK, still missing the old news.bbc 5ish years later :)
And if I ever have the privilege of your CV gracing my inbox, I'd do everything to ensure we got to work together. Thanks again!
Adopting data-driven decision making requires cultural change. I understand cultural change in large organisations is difficult, you don't need to explain this.
Difficulty of changing culture is, however, no excuse. The BBC is competing with Buzzfeed who've been doing data-driven decision making since inception.
I'm fine with being downmodded by people who disagree, but it's worrying "get data on it" is being flagged on HN.
"It's not "get data on it" that's being flagged, I suspect, it's "who cares what editorial thinks?". Because as a recipe for success, riding roughshod over the opinions of 2000+ people who make all the content in your product is not a great one.
What's more, BBC News editorial has reasons to be wary of pure data-driven decision making. It's not a pure Buzzfeed competitor -- it exists to serve the public purposes, not to drive eyeballs to ads. So arguments like "the data says nobody is reading our Welsh-language output, why don't we stop doing it?" or "The expensive pages covering Cornwall are getting terrible numbers, who care what editorial thinks, CLOSE 'EM DOWN" are not the slam-dunk you might be imagining.
That's not to say there isn't useful data that can be put at the heart of the newsroom to try and capture things that matter to the BBC, as BBC News is well aware. They're building tools right now to support that [1]. But I think any editorial team will always want a way to say to its audience "we think this is important right now and you should know about it". So a constructive approach might be something more like "here is the most effective way you can highlight news to audiences" not "we don't care what you think, people don't like the breaking news ticker so it's gone, welcome to cultural change granddad".
> Because as a recipe for success, riding roughshod over the opinions of 2000+ people who make all the content in your product is not a great one.
That's a gross mischaracterisation of data-driven decision making. The point is that non-data backed opinions belonging to anyone don't matter so much as the results of what you actually measure.
> It's not a pure Buzzfeed competitor -- it exists to serve the public purposes, not to drive eyeballs to ads.
Acknowledged, but effectiveness at that purpose is still measurable, and certainly should be measured as the BBC is publicly funded.
> not "we don't care what you think, people don't like the breaking news ticker so it's gone, welcome to cultural change granddad"
I'm unsure whether you're unfamiliar with media engineering, or simply creating a bizarre straw man of what was being suggested. Assuming good intention, and therefore the former, here's a more likely version:
"We've measured the breaking news ticker and find out it that X% of users find it useful, Y% read it, Z% engage with it, engagement with other stories happens A% more/less when the breaking news ticker is displayed over the top of it. Given that our goals are B, this indicates we should.
> That's a gross mischaracterisation of data-driven decision making.
It is! And I'm v. pro D-DDM. But as I read your post -- given it has been flagged to death I don't think I'm alone -- you didn't appear to be calling for that. As I recall, you appeared to be saying "who cares what editorial think, work out what you want and get some damn data" (which is where the straw man comes from, fwiw).
>> Act like engineers, work out what you want, test it and get some damn data on it.
Which is quite different from:
> riding roughshod over the opinions of 2000+ people who make all the content in your product
I hope you don't need it explained, but just in case: we're ignoring all things not backed by data, which very different from ignoring a specific subset of people.
The downvotes are for my saying 'damn' and writing angrily (ie, being pissed off with the poor engineering discipline of the public service). I'm intending to leave this thread, however, and enjoy the downvotes as "editorial doesn't like it" is frankly pathetic.
The problem isn't the breaking news banner. If aliens make contact with humanity, you better believe I want an intrusive popup. The problem is what the editorial board considers breaking news has been completely diluted and diminished both for the BBC and CNN
That sounds like a compelling argument not to always have it there. If anything, it would be more noticeable if it only showed up sometimes as opposed to it always being present.
I so agree with this. On mobile the BBC "Breaking News" popover is particularly annoying as you screen real estate is at such a premium and there's no keyboard to dismiss it.
The best solution I've come up with is immediately reloading the page in the hope that there's a cookie to stop the "Breaking News" showing again.
I'll just add, really like the new update. The new page feels much better (and the old one is really good already).
Please, please this. I don't care if news is just breaking. Just show me news in the order of importance. Or at the very very least, fix it so if I close the annoying breaking news box it doesn't jump back to the top of the page. Infuriating.
On your last point — the new breaking news banner doesn't have the infuriating jump-to-top behaviour. At the moment the new banner is only on the new front page but I think we're going to backport it to other pages in the not-so-distant future.
This is at least an improvement. But can't the breaking news only appear if something breaks after I load the page, rather than on initial load? Even then... give me an option to set a cookie to never see it please.
I'll raise this with our product team. I think it's totally reasonable to expect the banner not to appear as soon as you load the page — if there's a breaking news story, it will already be on the page, right? So there's no need to also pop up a banner with the same story.
But —this is a big "but"— I wouldn't expect this to happen soon. Changes take a long time at the BBC :)
The OP explicitly mentions a "Mobile - Emerging Markets" speed test, which is a nice benchmark. I sometimes try to browse the web on EDGE or weak 3G, and 99% of sites do not load in reasonable time, or at all. The old-wide-web of 56k modems would be perfect for it, but websites and javascripts got really obese nowadays:
This does feel a lot faster, but hasn't fixed my pet peeve (on bbc.com): clicking on a link to a news article and getting taken to the wrong one because the ads loaded and everything moved just as I clicked. This often happens to me 3 or 4 times in a row. Space needs to be blocked out for ads as soon as the page renders.
Yes! For me its the lazy loading of the images (not necessarily ads). Just as you are about to click on a link, the whole page jumps down and you end up clicking the wrong link. And then you click the back button, and the same thing happens again. So, you end up just having to wait 5-10 seconds for all the images to load just to ensure that you don't mis-click on the next article.
Yeah, I get the same issue with another part of the page - the little 'bell' icon they use for notifications at the very top. It appears just as I'm about to click on the link for 'sport', and I end up in 'news' instead.
Those of us aiming for the news link get to click the little bell instead. It's an infuriating order of loading.
Not much point complaining in this particular thread though. As the article says, 'We are essentially hamstrung by the “white BBC bar” at the top of the page.'
What annoys me most about this is that there is a valid GlobalSign SSL certificate there and the server can clearly handle TLS handshakes. It's just deliberately being used to make the user's experience less secure.
I realise this is being worked on and somewhat tangenital to this post, but the BBC's rollout of HTTPS has been shockingly poor and incredibly slow comapred to other news organisations. What's the point of serving account.bbc.co.uk securely if all links to sign in can be MitM'd? The parts that can be accessed with HTTPS don't seem to use HSTS either.
Hi, BBC employee here (although not in News). Basically, we're working on it. The main issue is that by making a page HTTPS only, that all content also needs to be HTTPS too. We're working with our CDN providers to enable that (not only for new content, but for our archive too), and we also have to support a much longer tail of browsers and SSL configurations than other sites (China being an important market for us, and anecdotally I've heard we still get >1% IE7 from China, presumably from pirated XP machines) which makes it more complicated. It's not really an excuse, but there are people working very hard at enabling TLS without breaking the site for others. Other parts of the BBC website are available over HTTPS, hence the redirects that are in place. Similarly, we can't use HSTS as that applies to the whole domain.
Slightly off topic, but can you please allow fallback when there is no Flash. The player works, but you have to hack you user-agent string to get it. I don't have Flash in Firefox and the BBC news is only site, that I visit regularly, for which this is an issue.
This is again something we're working on, a lot of it matters which video you're trying to watch. Because of reasons* some videos get transcoded into codecs that don't play in all browsers, hence Flash by default on News. In the mean time, you can opt in to the HTML5 by default trial: http://www.bbc.co.uk/html5
> Similarly, we can't use HSTS as that applies to the whole domain
Is this a problem for e.g. account.bbc.com though? I can't see how that can impact bbc.com/bbc.co.uk if the header is set on the subdomain only.
I remember it used to be that e.g. news was accessed via news.bbc.co.uk but this seems to have been changed more recently to be accessible at /news. As you note, this makes HSTS a no-go because of all the other products on the same domain need to support HTTPS. This makes me wonder why this change was made in the first place. It would also seemingly mean that (without e.g. https://w3c.github.io/webappsec-suborigins/) an XSS in one product means an XSS everywhere.
I'm sympathetic re. the SSL configurations you need to deal with and it's reassuring that this is being worked on.
Ah true, I'm not close enough with the detail of some of the subdomains to know what's going on there.
A few years ago a decision was made that the BBC site should be all under www.bbc.co.uk, I believe this was mostly for marketing purposes, but also to simplify our internal routing for the site. news.bbc.co.uk was previously separate as News had it's own infrastructure separate from other parts of the BBC, but that's been rationalised now (leaking subdomains for technical reasons was something we frown upon).
You're right, it's not a problem for account.bbc.com, which off the back off your parent comment I've raised pull requests to get HSTS added. To answer why that subdomain exists: firstly cookie compartmentalisation allows us to set particularly sensitive cookies off to a separate domain, as well as allowing us to do different arrangements for traffic management separate from www.
HSTS is not something you can realistically implement until every path under the domain can be served via HTTPS. For the BBC this is problematic because there are hundreds of products and inter-dependencies under the bbc.co.uk/bbc.com endpoints. The amount of work required to do this is non-trivial, and not something that can be done in blanket - each product needs to test their product, its dependencies etc. There's also other issues like CDN endpoints (and the BBC uses several providers, including its own CDN), a relatively large and complex traffic management set up and the politics that comes with a relatively large organisation running a very big website.
I mean, okay, it's faster than it was a year ago, but it's still considerably slower than it was a decade or so ago, before there was a plague of javascript o'er the land.
I miss when the major constraint on page load time was the server-side rendering time...
According to my Safari console, it's loading the page on average in 50ms, with some samples as low as 20ms. That's considerably less than the blink of an eye (at 100ms).
I doubt that a decade-old CPU/OS and a decade old browser were rendering any page (even without JS) at that kind of speed.
There is one thing that annoys me about http://www.bbc.co.uk/news I use VPN node in Finland. When I visit the news site the page loads very quickly, I start reading and after 3 seconds you figure out that I'm not in UK (based on IP I guess) and you reload to the international page with different articles.
Sorry about this... The BBC has some extremely strict rules around not showing advertising to UK users (who already pay a license fee to the BBC). We attempt to prevent this by redirecting people to the "correct" edition based on their location.
Unfortunately, for legacy reasons, the geolocation lookup and subsequent redirect happen in the browser. It might be possible for us to issue the redirect from the edge soon, since most non-UK users now come via Fastly which does some geolocation.
In the mean time, you can prevent the redirect by ensuring you go to bbc.com or bbc.co.uk, depending on whether you are in the UK or not.
Great. I religiously visit BBC news throughout the day. This definitely loads quicker than before.
That said, there is performance and then there is perceived performance. Why introduce an arbitrary fade-in animation on the images (aka a delay)? Just show them as soon as they are available from the lazy-loader. This makes it feel slower for me.
It was the one thing I noticed actually. The loading speed seemed about the same to me (its always loaded quickly here) but I found the fade-in really quite distracting. If you could pass on my downvote :)
And this has a sort-of easter egg: if you open developer tools in Chrome when at the page, they invite you to apply for developer jobs:
Hi there! Do you want to help build a fast and accessible web experience used
by over 300 million people around the world each month? We're hiring people for
all sorts of roles. Head on over to http://careerssearch.bbc.co.uk/ (search for
"News") to find out more!
As a long time Internet user I could actually imagine myself becoming passionate about "Make The Internet Fast Again". I wonder how one would start a career in that direction. It's a bit of a dilemma: In order to build fast modern websites you probably need to know how to build horrible modern websites. And I can't really motivate myself to imitate horrendous websites just for kicks. In fact, I stopped creating websites when jQuery wasn't enough anymore. In other words, more than ten years ago... It's not that I shun more recent technologies, I am willing to learn. I just don't want to create Frankensteinish websites first.
Any tips for a more direct path towards website optimization jobs?
Wow, this is awful. Would you mind telling me what combination of settings/add-ons you have so that we can reproduce this?
Our "no JS" fallback styles are not done in a very nice way at the moment: they rely on the browser reading noscript tags. We never did any testing with NoScript or similar add-ons, and I remember hearing somewhere that those sort of add-ons don't always evaluate noscript tags.
FWIW Privacy Badger isn't blocking anything, I think this is all from script blocking. I notice that low-res images get sent by default, which suggests that the design conflates 'no script' with 'mobile'? That's not true at least in my case.
Thanks! We'll take a look at this ASAP. In the mean time, I guess all I can do is apologise for the broken experience...
We use a technique called cutting the mustard to determine whether a browser is modern (read: >=IE9). This allows us to write one set of CSS that should work in pretty much any web browser (we call this the "core" experience), and another set that uses modern-ish CSS (the "enhanced" experience). One of the major drawbacks to this technique is that the technique relies on JS — it is literally just modernBrowser = ('addEventListener' in window && 'querySelector' in document && 'localStorage' in window).
So when you browse the BBC News website with JS disabled, you are getting a page that has been styled to work on a Nokia E65, BlackBerry OS4, IE8, and everything in between. Unfortunately right now we don't have a way to give you the enhanced version of the page without JS. In the future it might be possible for us cut the mustard at the server (or the CDN edge) based on User-Agent but that isn't something I can see happening in the foreseeable.
It's great that you're trying so hard to accomodate such a broad landscape; of course there will be trade-offs. Being a weird intentional corner-case you get what you ask for, I suppose!
I found that the "new" site looks reasonable with javascript completely disabled (i.e. turn it off in the browser settings). The problem appears to be when using a plugin to selectively restrict javascript (I use uMatrix) - in this case, the browser apparently doesn't interpret <noscript> tags. This is unfortunate, but I think its more of a bug/limitation in the script blocking plugins than a problem with your design.
Another hindrance when browsing without JavaScript is that changing to a news sub-region ( e.g. Northern Ireland ) requires three jumps-and-clicks to the bottom of the page. A CSS-based menu would be a wonderful alternative.
I find the opposite - without JS permitted for at least a couple of domains, one only sees the mobile site and extremely low resolution images.
Edit:
And even with JS, images remain low resolution (or invisible) until you stop middle-button scrolling which makes for scanning through articles very painful.
It's a great site but internationally the ads ruin the experience. You think you've clicked on a link but the site still hasn't loaded all of its ads and you have clicked on the wrong link.
Also waiting 30 seconds for a video ad to see 10 seconds of content is kinda stupid.
H2 support is happening at a much higher level (like, the BBC-wide infrastructure team level) but I think it's coming pretty soon. We did some testing and saw a positive impact on all front-end metrics: first paint, interactive, DOM complete, document onload.
Just to clarify: We aren't redirecting HTTP -> HTTPS and don't have any plans to do so, at least in the short-term. All we're doing is enabling HTTPS for bbc.{com,co.uk}/news because at the moment we issue a 301 for HTTPS -> HTTP.
The Guardian did a lot of work on pagespeed, made a lot of it public - I wonder if much of this was referenced. Especially given the planned 'masonry' effect shown midway down the page.
Good to see major public resources taking the lead (gov.uk being another) on reducing cruft. Most likely out of necessity, but it wouldn't hurt to start a trend :)
they can and often do -- code your own bespoke lightweight A/B testing software
that'll be the easy bit, of course, the hard bit will be influencing people to part with the £silly amount of money it'd likely cost vs. off the shelf alternatives
Does the cookie statement have to be so large? On first load it takes up ~ 3/4 of my usable screen space on an iPhone 5S in safari? It also feels unusual to be at the top of the page as opposed to hovering over some space at the bottom of the page.
Also on iOS lots of unnecessary line spacing (to the right of images) occurs when listing headlines.. image heigh, font size and line spacing could be worked to look better.
Congratulation on achieving the performance gains however :)
React is only used on the server. We do not load it in the browser.
My apologies in advance for my ignorance, as I have so far read about React, but not actually used it. Isn't the main advantage of React the virtual DOM it sets up and its reconciliation algorithm with the DOM? How can this be applied without using on the client side? Wouldn't all the responsive aspects be lost, requiring a round trip to the server for each event?
We've found that React is actually really great for building complex UIs out of small reusable components. I often struggle to put into words just how much better it is than, say, using Mustache templates or PHP/ERB/etc. I think it mostly comes down to how React makes component composition super-easy, and support for higher-order components makes component reuse a breeze.
I would also like the site NOT to be sending me a tonne of nugatory whitespace in the HTML, and to enable gzip/deflate as a minmum to reduce bandwidth...
Today is the first time I've seen gzip actually happen though! If only all my other problems were so easily solved by whining!
But still: sending, compressing, uncompressing stuff that definitely adds no value and would be trivial to statically omit almost all of is still a downside...
The question you should be asking is why it's there: is saving an extra nanosecond or two of easily-cached compression time really worth having to rearchitect a backend templating or content assembly system?
It's not a bad thing to do but I'd be surprised if they didn't have higher priorities for their engineering staff. If you look at the trace I linked before, note that even if you could eliminate all of the time to generate the page the most you could save is less than 100ms on page which uses multiple seconds of CPU time to render. Look at the video – the page doesn't even render for almost 5 seconds in a low-end browser:
If you were in charge of that project, would you commit your limited developer time to something cannot possibly produce a human perceptible benefit or instead have them work on removing a borderline-uncomfortable delay?
Most of the work would be essentially quick and one-off: no one blinks at minifying JS or CSS and I bet that 50% of this would be entirely the same and at low dev cost.
I entirely see your point, but disagree that it's not worth doing any of it, given an almost certain quick small win + saving CPU time and bandwidth and a bit of planet while we're at it!
> Most of the work would be essentially quick and one-off:
Again, think about the complexity of what's generating that content. Do you really think they have a single index.html template floating around rather than the system described pulling blocks of content in from various sources, all of which need to be updated in various places? You could build a system to collapse whitespace runs after the content is generated but now you need to develop that and test it to make sure it doesn't trigger on something where the whitespace actually matters … and suddenly you're taking time away from changes which actually benefit people.
> given an almost certain quick small win + saving CPU time and bandwidth and a bit of planet while we're at it!
How much CPU time do you think you're talking about, anyway? Here's what doing this in a naive manner which will break things looks like:
So we're talking an extremely small amount of CPU time and one packet saved. That's might seem useful until you look at this in context of a page which loads a couple MB of content and uses multiple seconds of CPU time:
Image compression, enabling gzip on the remaining resources which lack it, etc. are all going to save more data on individual files and have the nice property of not breaking anything else.
I'm not saying don't do the other things too, but a ~5% saving (maybe more at a more typical gzip TX setting) for no semantic change at all saves some outgoing BBC resource but is more significant for the RX side in CPU, etc.
Anyhow we can agree to disagree but many of my clients over the years have been very happy with 5% resource savings, although 5x is nicer when available... B^>
(And yes I'm fudging CPU and bandwidth, but with a compressor involved and the CPU often being a bottleneck on lower-end devices for example, I think that simplification can be justified.)
Plus of course anything that helps get meaningful content on its way to the browser in the first (pref 2) TCP frames helps hugely. The current page header makes me cry...
always love how you optimise the news front page. are you guys still running the Perl backend and "Html Put" :) @joseph_wynn ? a former BBC News CSD here.
Nope, the Perl backend went away a long time ago! (at the point of switching from news.bbc.co.uk -> www.bbc.co.uk/news). The site is dynamically generated at origin now.
There used to be this resident Perl-guru in an obscure area, back when we were sitting over in TVC (FM&T J area), who would debug stuffs for us when things were not working right. Can't remember his name though (Scott? Paul?). I wonder where he went...
When you put it like that, yep, pretty costly! But a large chunk of this project has been building up the frameworks, infrastructure, tooling, and processes that enable us to migrate from our legacy PHP 5.3 apps running in 2 physical data centres to ~the cloud~.
Also, did you read the part about we have collaborated with over 60 other developers and testers from all around the BBC to build this page? That's actually the best part — News websites are pretty simple; you just display headlines, summaries, and images in various formats. So part of this project was building the lego blocks that we're going to use to rebuild not just the rest of the BBC News site, but also parts of BBC Sport and potentially other BBC products too! So yeah, costly for one page. Hopefully very cost-efficient in the long-term.
It's nice someone cares about performance in modern websites. Shame about the BBC being no better than any other clickbait website as far as news goes. Truly, my licence fee well spent.
I never understood that. Surely, since you're already paid for you could just report the news and not bother with clickbait since you're not getting paid for the clicks?
The first rule of UX is "you are not your user", and you are breaking it (I'm guessing the BBC has done significantly more user research than you). I think your comment is basically "I want a website to look like this, therefore all users must want a website to look like this".
https://pbs.twimg.com/media/Cu_KsFAWgAADCJR.png