Writing and publishing a blog post or press release is at the core of the Prezly product and we want to make it better, faster, more powerful and easier to use.

But building an editor is bloody hard and in a post last year I listed a number of things I find important when it comes to the writing experience.

Since then we've been spending a lot of time on improving the Prezly editor. One of the ways to measure our progress is to look at the time it takes for our customers to complete the journey from creating the draft to the final publication of that story.

In about 1 year we have decreased the time from an average of 33.8 minutes to 22.6 today. In this post, I am going to highlight the many changes we made.

Adding blocks to a story

One of the main ways to insert anything else than text is to use what we call 'the plus menu' which is a lot of CMS/content editing platforms perhaps like Notion.

We noticed through qualitative and quantitative feedback that some of our customers didn't know that there is a [+] menu in the first place. That's why we improved the empty state and added a tooltip and improved copy to encourage customers to try it.

The [+] plus menu

The menu is a powerful tool to mix text with any of the other blocks that are available in Prezly like galleries, videos, file attachments or regular embeds.

We looked at 100s of sessions of how people were using the + menu and made a lot of small/improvements:

• Improved positioning of the menu on different viewports or when scrolling
• Better (fuzzy) search
• Support alternative keywords (aliases) for blocks. Searching 'youtube' will find the video block
• Added a suggestions menu with the most used/important blocks
• Smarter positioning of the flyout menu (when scrolling). See below.

In-between content

Once you have a story with some content you might want to add some multimedia in the middle. One of the challenges is that the + menu icon only shows up on an empty paragraph. And to add an empty paragraph you need to move your cursor to the beginning or end of a paragraph and hit enter.

This works if it's a paragraph but becomes annoying if you want to add a block between two other blocks and even impossible if the first element in the story is a multi-media block 😱.

Initially, we wanted to solve this with icons that allow you to create an empty paragraph before/after similar to how CKEditor is solving it.

But the prototype we built came with some challenges and looked messy with the existing options/block menu we already have.

We landed on some virtual whitespace before/after a block that can be used to insert a new paragraph.

Keyboard Shortcuts

In addition to a workflow that involves touching your mouse we also added support for keyboard shortcuts:

• Ctrl + Enter (Cmd + Enter on 🍏) to insert below the current block
• Ctrl + Shift + Enter (Cmd + Shift on 🍏) to insert above the current block

The goal is to add additional keyboard shortcuts for common-used actions like inserting a video, linking the selected text, etc...

Component Controls + Placeholders

We cleaned up the UI of the component controls and made them dark. There was a lot of discussion around the dark UI but the main idea that ended up making it was that this way it contrasts with the rest of the editing experience highlighting that the dark menus are extra things/settings you can do with every editor block.

With that, we also touched the text menu and the campaign composer menu to all be dark and provide a consistent editing experience.

Additionally, we made the behaviour to add blocks more consistent where every time you want to insert a block we add a 'placeholder' in the editor. This placeholder can be used to provide more guidance/help links and implement some draggable zones where an image (or multiple images) can be dragged on top of the placeholder.

Pick a site before you start

Because Prezly supports multiple sites it's important to know in which space you are currently editing, because some settings and editing options are tied to the context.

• The available languages/translations are linked to the newsroom settings and defaults
• Newsroom contacts (think Author cards) are tied to the context of the newsroom
• Preview URLs are different

For any customer that had more than one space, we had some magic/hard-to-explain rules and combinations that guessed the site you wanted to create this story in. The problem was that sometimes we guessed wrong which made the editing experience much harder than it should be.

We'd see editors trying to change the language of their story, or insert a contact card that wasn't there. All because we picked the wrong site.

The decision to solve this was quite simple:

1) Pick your newsroom

The idea is to add a little friction to the flow to create a new story but avoid some headaches down the line.

Obviously, customers with only one site don't see this picker.

2) Show which space you're in

Instead of having a super-weird UX pattern where one dropdown (site dropdown) would serve as both a breadcrumb and a 'change your newsroom' flow was utterly confusing.

So we moved the 'change newsroom' to an advanced settings pane and made the site indicator prominent and read-only so there is no more confusion as to which space you're editing in.

Image Uploader

Behind the scenes, we're using uploadcare.com for all uploads like attachments, videos, media galleries and pictures. This is a tremendous help as they provide uploading tools but make it easy to transform and serve those assets through their CDN.

We have a deep integration of Uploadcare within Prezly but the most noticable integration for our customers is the upload modal.

So we looked at a lot of sessions where people were using this modal and came up with a list of improvements:

• Improve copy of the different tabs + text
• Provide quick access to help docs
• Allow reordering image galleries during upload
• Implement a 'recently uploaded' tab to avoid having to upload the same asset
• Shortcuts to set the image description based on the file name
• Bring the UI closer to our design system
• Add a 'newsroom media' tab enabling editors to pick content from their site media kit

We're not done yet. But between now and my previous post on building an editor-friendly writing experience we've made good progress.

• ✅ Auto-save to avoid losing work
• Awesome linking experience
  • Easily link to other content in the same CMS
  • Allow different type of links
  • Highlight (and upgrade) broken links
• ✅ Use good typography
• ✅ Great support for lists
• ✅ Show pasted images inline
• ✅ Essential features done right
• ✅ Wrap long lines
• ✅ Make it fast (speed/performance)
• ✅ Support text-correction extensions
• Undo/Redo (with shortcuts)
• Good pasting behaviour

We're currently working on a new interface for Story editing that goes beyond the Prezly editor (Snowbird). This will hopefully address most of the issues I listed in this previous post.

Are there any improvements you'd like to see?

The interface in which I am writing this blog post is over 5 years old and has UX issues. A quick write-up of what we're thinking about and what we are struggling with.

This project can be broken up in three different components:

1. The writing experience / Editor itself
2. CMS / The story editing interface
3. The publication flow

The editing experience

Turns out that building a good editor in 2022 is not as easy as it sounds. While Google Docs, Dropbox Paper, Notion and Coda have their own proprietary solutions there is nothing out there that comes close to that level of quality.

In our research, when it comes to open-source projects, there is only really SlateJs (24k stars) and TipTap (14k stars) worth considering to build an experience on.

Gijs Nelissen on Twitter

I've wrote about this in a previous blog post:

Create an editing experience people love

We've been investing in our version of slate editor and we've come a long way including keyboard shortcuts, a new + menu, embeds/website bookmark, auto-formatting/detection and improved text-alignment.

We still have long way to go but a solid plan how to get there. Short/mid term improvements include:

• better linking (link to internal references)
• improve the support for pasting from GDocs, PDF, ...
• placeholder components
• drag-dropping components
• more customisation on sizing/alignment of galleries

Most best practices can be borrowed from popular editors like Coda, Google Docs, Notion and even Microsoft Word. Oh, did you know the most requested editor feature is text-justification (for the web)! 🤯

CMS / The story editing interface

Turns out that this is a much harder problem to solve. Here is an overview of the story editing interface for a multilingual story with 2 translations in an account that has multiple newsrooms.

Although we do not have any major complaints (it's been in use for over 5 years) and is being used 1000x per day with over 300k stories published I feel there is a lot of room for improvement.

Some of the issues we might want to address:

• The left sidebar draws a lot of attention taking away attention from the content
• Language settings everywhere. The sidebar has a language switcher while translations and switching translations happens in the 'manage' dropdown
• Publication settings like visibility and publication date are in the left sidebar but the flow to finally publish a story is in the right top corner
• Newsroom picker is a setting but was lifted as some kind of super setting. On other pages it acts as a filter/navigation but on this page it's a setting
• General page canvas. The combination of the sidebar, sub-navigation and manage tab makes the interface overwhelming

The publication flow

In today's interface the publication flow is mixed in with the rest of the settings and the writing interface. And because some of the settings (scheduling, embargo, private story) affect the publishing behaviour this comes with some confusion.

To work around this we have introduced a 'great job publishing' success modal together with dynamic labels on the main publish button.

The more we work on the story edit and gather more information through desk research and customer interviews the more we are realizing that it might be better to break up the publication flow all together.

We're stuck

At this point I feel we're stuck. We've looked at all our competitors, the best CMS systems out there and have browsed the web for inspiration.

It feels like we've dug our hole too deep and are trying to solve too many things at the same time. Please send help!

Here is a list of assets/attempts (please note that these are just random picks from a larger project including low fidelity wireframes or idea sketches)

Text editors are central to most online apps. While text editors used to be important for Content Management Systems (CMS), they are now an important part of many more tools such as Project Management Systems and CRM systems. Customers are rightfully more demanding when it comes to how they create content.

But building a good editor is bloody hard. You'd expect that this is a solved problem in 2021 yet so many products have a poor writing experience. As a result, content is written off-line, using tools like Google Docs, Microsoft Word or a notes app and then pasted in an inferior editor.

This is a post listing some recommendations for creating a more friendly web-based writing experience:

• Auto-save to avoid losing work
• Awesome linking experience
  • Easily link to other content in the same CMS
  • Allow different type of links
  • Highlight (and upgrade) broken links
• Use good typography
• Great support for lists
• Show pasted images inline
• Essential features done right
• Wrap long lines
• Make it fast (speed/performance)
• Support text-correction extensions
• Undo/Redo (with shortcuts)
• Good pasting behaviour

Auto-Save to prevent lost work

If we want to get people away from the 'traditional' editors we need to protect people from losing their work. No internet connection when you hit save? Browser crash?

I can guarantee you that the author will never use your editor the same way ever again if they lost an hour of their work.

Online editors should invest in techniques to make sure this does not happen, the technology is out there. Some ideas:

1. Browser Local Storage (client-side)
2. Auto-saving in the background (server-side)
3. Versioning content (server-side)

Option #2 is the option most web apps will pursue but for CMS systems that allow publishing content, it comes with another challenge which is to know which content has been published which is where option #2 comes in.

Awesome linking experience

Most WYSIWYG editors have ported the Microsoft word linking behaviour to their online counterparts. We're so used to applying a link to an element:

This is a missed opportunity with two big area's of improvement:

Easily link to content in same CMS

Most blog posts refer to previous posts or paragraphs. Forcing editors to visit their blog, find the URL/anchor and paste it as a link is such a waste of time.

A few exceptions (Google Docs, Notion) are helping writers to browse/search for other content but I'm disappointed every time I have to open a new tab to find the URL for something I want to link.

ℹ ​ Bonus points for the ability to link to anchors which I think only Google Docs can do (only within the same document).

Allow different types of links

A link used to be a few underlined words pointing to an external page. In 2021 there are so many more ways to present links (cards, embeds).

Editors could help with 'upgrading' links to an embed or card. Preferably the editor has the ability to specify how the link is displayed.

Highlight (and upgrade) broken links

The web is filled with broken links 😵 Make sure the editor indicates broken links by checking the page in the background and hinting at the status (status code).

While you're at it how about improving/fixing the link? If the server replies with a 302 redirect (for example from http:// to https://) update the link without asking the editor. It does make the web a better place!

ℹ ​ Personally, I prefer not to see the schema in any link. If a user pastes https://www.lifelog.be in your editor you'd like to see it auto-link that phrase to the webpage and at the same time change the link text (or label) to www.lifelog.be.

Use good typography

Many online editors use weird fonts and font sizes. ​ No content creator is going to spend an hour writing content in an editor that makes them squint.

Readability is a big problem on the web with many initiatives and resources to solve that. Learn about the best practices in those projects and apply them to your editor.

The example to follow here is Medium.com where the editing experience equals the reading experience.

Great support for lists

People use lists. A lot. Make sure your editor has good support for it. A list 😎of suggestions:

• support hitting tab to indent lists
• auto-detect lists once a person starts a few (or one line) with -
• allow nested lists
• shift+tab should decrease indenting
• think about how people 'exit' the list (enter+enter?)
• allow people to convert lists from bullets into numbers

Writing this piece in Bear reminds me how important the support for lists really is.

Show pasted images inline

While initially, only some editors allowed you to attach images to your posts it's 2021. People do text -> image -> text.

Regardless if one is writing an article on a blogging platform, sharing feedback on a design in a project management platform or updating an internal document in your intranet please support pasting images!

The ideal flow is that while writing the text you can just hit paste to add an image from the clipboard. Please don't attach it at the bottom of the post (I'm not drafting an email) but add it wherever the cursor is.

ℹ ​ Bonus points for auto-sizing/optimising the image or allowing controls for the editor to size/align the image

Essential Features done right

All the power features you have added to your editor (image wrapping, code editing, advanced text styles or colour picker) do not mean anything if you have not nailed the basics.

Seriously, I don't need font colours or backgrounds if I can't paste an image inline. Start with the basics before you spend time on the advanced stuff.

Wrap long lines

There has been plenty of research that a line longer than 70 characters is hard to read. While this rule is well known in web readability it's often ignored in editing experiences.

This problem is even more noticeable with full-width (focus mode) text experiences.

Use max-width in combination with optimised font size/typography for an editing experience that has good readability. It really does wonders.

Make it fast

This should not even be here but I'm adding it anyway. If your editor is clogging up my browser window (I'm looking at you Confluence) you'll never convince me to use your editor to do the writing.

Evan You on Twitter

Spend time on performance! Some people will take 1/10 of the features for 10x the speed.

Support text-correction extensions

How long did it take for google docs to support Grammarly?

There are so many good correction engines (Grammarly, slick write) out there that provide browser extensions to make sure the text correction can be done wherever you write. Surprisingly not all editors support those extensions forcing you to copy/paste your text into Grammarly just to do text corrections 🤯

Also, please don't try to build text correction yourself (maybe unless you are Google) but allow existing solutions to hook into yours.

Undo/Redo (with shortcuts)

For me undo/redo is a solved problem and much expected in any content editor. Surprisingly there are editors that do not support undoing.

Good pasting behaviour

Following the suggestions in this post is not a guarantee that people will stop pasting stuff. Spend time on figuring out what/how they are pasting and make sure it works well.

In our case, we triggered a survey the first time we detected a paste from an unknown source (weird formatting or elements). In that survey, we asked the user where they were pasting from and questions around why they didn't write in Prezly in the first place.

Results of this survey were then used to help us figure out which pasting behaviour (from which source) we needed to prioritise.

Word has been around for a long time. It's unlikely that the tips in this post would mean people trust your editor to be 1:1 alternative. Like it or not, MS Word will continue to be an enormous force behind the content that finds its way online.

However, it's also true that a lot of online editors are super annoying to content authors. While some platforms have a great tech stack and are growing rapidly they oftentimes have poor experience for long writing sessions. So it's little surprise authors actively avoid them to perform their writing.

Maybe this post is one step in the right direction

In this article, I am going to break down how this blog works. When I started this project my main requirements were 1) developer experience, 2) performance and 3) simplicity.

Update July 2022: New blog theme

The stack

This blog is a Next.js application that is pulling in content from the Prezly CMS.

Using Next, you have a few options when it comes to page rendering: “on-demand” (server-side rendering) or ahead of time (static site generation). I've opted to build all the pages posts ahead of time when the site is generated (so on every deployment).

The site is deployed on Vercel (the company behind Next). The developer experience is awesome where it auto deploys the blog on every commit/merge to main.

For analytics I decided to use Plausible Analytics which took me 3 lines of code to set-up:

Content/CMS/Deployment

This all started as a big experiment while I was trying to figure out what we needed to do to make Prezly more developer-friendly. By trying to power an (external) blog with content written within the Prezly editor it would allow me to identify the parts of the chain that need more attention.

Every time I create or write a story in Prezly it triggers a Vercel webhook which in its turn generates+deploys the site.

Because of the limited number of blog posts the rebuild takes less than a minute:

Story Renderer

The Prezly editor stores content in a rich text format (and not HTML). This is a common practice in today's Content Management Systems as this allows for more flexibility when it comes to the rendering and management of that content. There is even a standard for it.

Here is a great article (2018) about the benefit of rich content types.

On Rich Text Editors

In Prezly's case, it means that content you write in a SlateJS powered editor is stored as a JSON object in our data store. That raw content object is fetchable through the API and we provide a renderer to then turn it into HTML.

So take this example content in Prezly:

The content (starting from hi %contact.firstname%) will be stored JSON:

Github Gist: Example email campaign (slateJS)

As we're using SlateJS as an editor you can read more about the content structure (not mobile doc) in their help article. Using the Prezly provided slate renderer the code that turns this JSON object into the HTML you are reading right now looks like this:

https://github.com/digitalbase/lifelog.be/blob/main/components/Article/Article.tsx#L36-L40

How content is rendered can be customised by feeding options into the renderer which I had to use to display code snippets (see below).

Other Pages

For other pages such as the home page, the list of blog posts and sitemap I used the Prezly Node SDK to do some very simple API fetching.

For example, the home page that lists the latest 3 articles (source code):

https://github.com/digitalbase/lifelog.be/blob/main/pages/index.tsx#L32-L42

Which by itself is just a simple wrapper to list content

https://github.com/digitalbase/lifelog.be/blob/fbb7d1d2fb56f0f2369b50e4606f975fbf49243a/src/providers/prezly.ts#L40-L63

Embedding Code Snippets

The Prezly supports embeds by making use of Iframely which natively supports github embeds (see JSON sample above). But if you have a lot of code to show off copy-pasting code into secret Github gists is cumbersome.

So I wanted to be able to show off code in a github repo or branch and Googling a solution for this got me to emgithub.com which looks to be exactly what I wanted.

Integrating the embed code in within the project was pretty clunky (dangerouslySetInnerHtml, embed.js being calls numberous times, ...) so decided to extract the code. Actually, my colleague did it for me.

https://github.com/digitalbase/lifelog.be/blob/main/components/GithubSnippet/GithubSnippet.tsx

So what the code is doing:

• fetching the raw github code (client side) using https://raw.githubusercontent.com
• use 'react-syntax-highlighter' to show a code pane
• add 'view raw' and 'copy to clipboard' functionality. Stole from stackoverflow

Styling

When it comes to styling I think I overdid it. I decided to use ChakraUI (as an experiment) but in the meanwhile I have been playing around with TailwindCSS (and more specifically with Just in Time generation). Now I want to throw out ChakraUI and switch to vanilla tailwind.

There are some upsides to using ChakraUI. For example, check out the source code for this hero component on the homepage:

Overall I feel using Chakra forced me to learn another syntax/way of doing things and I might be better off investing this time in properly learning TailwindCSS which can do the same stuff anyway.

Todo list

A list of things I want to do with the blog

• Use theme-starter boilerplate code to fetch content
• Score better on Lighthouse Audit tools
• Allow paging from home page
• Support Search
• Implement subscribe functionality (stay updated)
• Improve SEO/meta tags
• Add RSS feed (and any other feed protocols people use)
• Get rid of ChakraUI
• Make better use of Uploadcare.com (using uploadcare-image)
• Bring back sitemap.xml
• Fetch intro text from newsroom boilerplate (make customiseable)