How (any why) we redesigned Daily Digest

If you have visited Daily Digest at least a few days prior to this blog post, you may have noticed that we gave everything a fresh coat of paint, and redesigned the entire UI from scratch. While, personally, we think it looks a lot better (and we hope you do as well), you may have some questions: What is all this new stuff I am seeing? How did you build it? Was it complicated? What was your thought process behind it all? Why did you change it in the first place?

Actually, let's start there: Why?

A reason to redesign

When we first built up Daily Digest, we had an idea: to present the most relevant news, to everyone, and nothing but those news.

The idea was, and still is, to deliver the most “fresh of the press” news twice a day, in the most straightforward manner possible. Looking at our original UI, we certainly delivered news twice a day. But it fell short in the parts how we would like it delivered. While all the news was there, they were fragmented, siloed almost. Each category of news fell into its own little section, even though you may be interested in multiple or even all. Additionally, we found that the place most of you read the news, which is on the smartphone likely in the palm of your hand right now, was not that great of a fit for our former UI. Audio players looked different on various devices, the UX was not optimised to mobile readers, and in general it was unclear what we actually wanted to bring forward.

Looking back at that UI and the aforementioned mission statement, we can “digest” three key points of the Daily Digest experience: it should be all-news-encompassing, it should be fast, and it should be accessible to all, no matter the platform.

The UI debate of "how"

Given the above, we were presented with an easy question and an all-the-more complicated answer: how do you build a UI that fits that purpose?

There is certainly no shortcoming of ways how you can build a UI on the web. There are even less shortcomings of debates around which is the better or best way to do it. A popular meme among software engineers references an article stating that two engineers got into a knife fight after one of them suggested using Java in the frontend, with the other proclaiming that they “prefer death to doing screen in Java”. To say the least, debates around what to use for UI can be… divisive.

However, given that we wanted news to be presented fast and accessible, we settled on the most basic way you can do it, a classic HTML/CSS/JS combo. No frameworks, no server-side rendering, no 10 million dependencies to be loaded before the first headline is rendered, just good old DOM rendering.

In other words, we wanted to serve static files only. But what did we actually put in place to make it happen?

Getting that new feel

Despite wanting static files, our content is not static. After all, we generate new news articles twice a day, quite the opposite of static. So, in some capacity we needed to generate some of these files on the fly.

The first version of our UI already did that. We made use of Handlebars to fill out templates containing our structure and styling, and with that, we only had to fill in the dynamic content. In our case that would be the news, as well as some translations for the German and English versions of Daily Digest.

We made use of this approach again. The results of Handlebars are small size HTML files, ready to be served, and are as fast as you can possible get in terms of speed for download and rendering.

However, using Handlebars templates has one very significant drawback, and that is that they are rather hard to edit. To give an example, lets say you have a template that hosts your main front page. That page loads another Handlebars template, for example the header of every page. Separated into a different template, you are able to edit the headers of all rendered pages by just editing this template. This is also known as a partial.

To actually see what you page looks like, you need the content of said partials to be present in the DOM you attempt to render. But in Handlebars, there is only a reference to another file, and loading the template in a browser will not render anything. So, to make changes and see the result, you would need to copy-paste the header in place of the partial reference. But what if that header contains another partial, let’s say, a menu? And what if that menu contains another partial, like a menu option? And what if that menu option… you get the point.

Handlebars templates are hard to debug and change. Hence, we developed servebar. servebar is a local hosting script that hosts your templates with data you define, with all partials and also all helper functions you need, in order to properly render the site as you would like it to.

Using servebar, we could iterate quickly on what the new design should like. Given that, we could make some major improvements. For example, we made sure to include plenty of CSS breakpoints and conditional rendering that ensures that Daily Digest is now accessible on mobile.

One more thing we would like to highlight is the new player. If you open Daily Digest now, the first thing you will see is an audio player with chapter markers. This player is, again, a Handlebars partial, and we use it on multiple pages. However, one additional thing we introduced with the change are exactly these chapters, and the fact that you can now play all news as one continuous news showcase. No matter if you are only interested in some of the daily news, or would like to stay up-to-date on everything, this new complete format allows you to that.

Taking it all together, we now have a news portal that is fast (Handlebars renders), accessible for everyone everywhere (mobile and general UX improvements) and showcases the news relevant for you (both all-together and per category via chapters). We hope you enjoy this new look and feel, and if you have any feedback, feel free to let us know!