The simplicity of article rendering

We're trying out a new series of blog posts where we dive into different aspects behind building a news product. This first article will go into the most important part of a news product: the articles themselves, specifically the frontend part of it.

We'll look at it in three parts: the article body, the tracking, and the surrounding UI.

The article body is the real meat of the page: it's where the content lives. Tracking is what is used to keep track of how successful an article is. And the surrounding UI includes things like the navigation bar, and the login UI.

Article body

Your typical news article is composed of various components:

• An author line

• An image for the header

• A title

• The article body, composed of text, images, and rich components

• Rich components e.g fact boxes or videos.

In a typical newsroom, the journalists will use some form of a content management system (CMS) to write. These might range from your basic text editor, to a WYSIWYG editor that has rich concept. Since these tools are what the journalists use day in and day out, it's vital that the tool is as simple as possible to work with. The more complicated a CMS is, the longer it takes to produce an article - which can either be a blocker in a newsroom focused on covered breaking news stories, or a benefit to newsrooms that prefers longer, more rich articles.

As an example, if you're covering the death of a famous person, you'll typically want to get that news out as soon as possible. Every second you don't, another newsroom might beat you to it. But if you're covering an upcoming election, you have lots of time to prepare for that situation. So you might have an article that has a built-in quiz for figuring out what political party most closely aligns to a reader's beliefs - either through some standarized component within your CMS or via a manually inserted bit of code.

Rendering these components falls generally into two buckets: trivial work and complicated work. Things like titles, paragraphs, and a title image are trivial. For example:

<h1>{title}</h1>

<img alt="byline" src={src}>

<p>{body}</p>

These components require little code, and the majority of the work is in styling. Images might be lazy loaded, but for a majority of articles, it's not necessary. An article composed of these components can be thought of static: really, it can just be Html and Css, nothing fancy. There's no need to load JavaScript, there's no need for an SPA. Just plain old markup and styling.

Complicated components are typically referred to as rich components. These are components that might involve interactions, or have formats other than a typical image and paragraph format of an article. For example, a video involves more than just scrolling up and down: a user must interact with it in order to watch it. There's also a lot of expectations around how a video behaves: if you're on web, platforms like YouTube already have nailed a bunch of the UX problems of a video. If you're in a native app, the user expects a video to feel like a native component. So the code involved in creating these elements is a little more involved.

Tracking

We've made it this far without mentioning the forbidden word, but a rich component typically will have higher engagement than a static component. Users will click on them, and they'll be a focus of the article page. That doesn't necessarily mean that they are always best for communicating a certain story, but it does mean that in the right article, they can drive a lot of good looking stats.

When rendering an article, there's typically two main events that are tracked: the impression on the article, i.e the article view, and the engagement in the article, e.g scroll depth. Impressions are easy to count - and can be done either client side or server side with minimal code. Scroll depth however is a little more complicated. An event listener is attached to the page scroll event and then sends data to a tracking server recording at which point a user has reached. This could be sent with every scroll, or it could be done on page close or on a timeout. It could also be done on a component level - so rather than tracking a scroll position on a page, the tracker will check which components are visible on the page. In an article with rich components, the tracker will also ensure that interactions with components is tracked, e.g clicks on a video.

It might also be desirable to track things like which links are clicked within the article, or to what elements a reader leaves the page for (e.g navigation elements).

Surrounding UI

The surrounding UI is mostly made up of all the rest of your site that isn't actually that relevant to the article itself. Login buttons, privacy consent bars, navigation bars, the logo. It's not to say that these aren't important: they are, they guide your users further through your application and to their next article, as well as building behaviours like returning to view more content. But they generally are disconnected from an article. These elements can be developed independently from the article body, though it is important to consider how the user flow looks like from a reader of an article. Things like how to subscribe or get to news in a different topic. They are often controlled by different teams, if you're working in a organization that has standardized these elements across different brands and products.

That being said, it can be as simple as your product allows. Perhaps you only have 3 sections, in which case the navigation can be very simple. Flows like login or subscription tend to be complicated, since they may involve payment systems and user data. But not all products have that as a requirement.

Overall

The time to produce a simple, read-only article is short and efficient, with the majority of time spent on styling. Adding rich components takes more time to get right: particularly with components that have native equivalents like video. But not all articles need all possible rich components to exist. Tracking can be as simple or as complicated as your product team and journalists need. Surrounding UI requires a lot of work and code, but depends a lot on your product. You should not be afraid to write an article renderer from scratch, especially not if your article does not contain a lot of rich components. But the surrounding infrastructure and UI will probably take longer than the article body itself.