Concept for a better Netlify CMS editor / Part 1

I’ve been following Netlify and the JAMStack movement for quite some time now and have become a huge fan of it for various reasons. And that fanboy excitement means a lot coming from a strong +10 years WordPress background. It just means that things can be made better while being simpler.

One exciting thing about JAMstack is how things are connected together, like lego blocks on the dev side and layers on the front-end. One of my favourite blocks is the Netlify CMS which is open source and this post is a small contribution to the project. It’s hard for designers to do open source contributions since there is the “right place at right time” for these projects. If you’re too late it may get really hard to make decent contributions (yes I’m talking about WordPress).

This small project of mine is going to be a concept for the UX/UI editor part of the CMS. One of many tries of what and how I would create, design and use the next CMS Editor of the future. I will take some inspiration from 3 major cases we already know of, these are WordPress, Medium and the new Dropbox Paper. These were also mentioned in one of the Netlify CMS – Github Issues. These are strong products and their use has influenced a lot of people, even Paper being really new is doing great. But to plan a new editor for a specific community we should also focus and get ideas at the starting line instead of taking too much inspiration at the finish line. The finish line is for learning, the starting line is for doing new things.

A note here is that this concept may solve some problems and improve various things but it’s not a short-term solution (time and working hours are needed to move this idea/concept forward) and making it happen will need some help from the community. The goal of this post is not to force an idea but rather have a focus or “a right path” for future contributions. I hope to see it as something that will change and grow with time by brilliant minds that can push it forward.

Eagle eye view and gathering data and information

Now before I start on any project I tend to look and reverse engineer some things first. The more information I can gather, analyse and understand, the easier will it be to come up with a new tailored solution for a specific user segment or a problem.

And with that, any CMS has at least 3 main groups using or influencing it. Developers, designers and content writers. It has to work for all so it satisfies all the technical needs as well as usability ones, in short, it has to make everyone happy, but mostly content writers as a CMS is for them mainly.

I’m gonna really enjoy creating a system that can work for each of these 3 groups but function as one product. Any system can be either closed or open, but in this case, it’s going to be a bit flexible on some parts. Closed with some specifically designed rules for its use so things don’t go out of hand (for example WordPress can get really chaotic over time), but still open so any of the 3 groups won’t be limited by its use.

One downside may be, that any of the 3 groups may have to learn some new things but hopefully, these could be really intuitive making the transition easier and later on the use of it a fun and enjoyable experience for everyone.

Let’s look into these 3 groups a bit closer.

Developers (front-end developers) and a CMS Editor

A CMS for developers at its basic sense means that there need to be some input fields (text area, image,…) that need to be later on shown in a specific layout or place of a context of elements designed with structure and hierarchy. Let’s just call it a template or a layout.

Now with WordPress, there is a well-known plugin called Advanced Custom Fields that lets you add specific fields to a layout in the backend and then you call those fields in the templates which show the data to the user on front-end part of the site.

It’s a similar thing with Netlify CMS but here each of these fields doesn’t need to have 2 rows in a database and have key values etc. As it writes in Markdown we can just directly “hardcode” these fields to the markdown file as specific front-matter values. Some ACF designed pages with lot’s of fields can query the database +500 times if not developed right. JAMStack doesn’t have a DB so the difference just here in performance is massive.

Another thing ACF does well is their modular approach to building blocks or layouts called Flexible Fields. With that, you can add sections with specific input fields and mix and match them to create a page.

I used to really like that approach but it’s not really made for writers. Also, a big problem is you give out too much control and a writer can “design” things instead of writing making things messy. The Divi or Visual Composer builder are an example of how things shouldn’t work for someone that wants to add content, it’s just too time-consuming. These options have been used by common WordPress users and even “developers” to “design and code” a website through the backend. Just because it can also be used in that way. A professional shouldn’t really do things like that as these sites are sloppy and bring tons of problems.

A developer working with a CMS needs to have the power to manipulate any data with code. Specific input needs to come out as desired output. And that code needs to stay clean and be easily maintainable. It needs to be flexible and open for changes and easy improvements. A website is a living organism and it needs care (although a JAMstack site needs a lot less care than, for example, a WordPress site).

Today’s developer mentality is that we add things to our stacks or problems. We create a solution for a problem but then, later on, we have two problems to maintain, so we add another solution making it 3 altogether. An example for this in the WP world is cache. You need to add things (plugins or server cache setup) to make things faster instead of figuring out WHY things are slower and either remove or improve those parts. Writing and adding new functions to change core things seems insane.

Thankfully JAMStack has that great minimalistic mentality, especially with Metalsmith as a choice for you static site generator. You can add things you really need and all the input is manipulated with all the control you can have and the output is just pure poetry with magic. And Netlify CMS is the same, you just need to add things to it, not write or code things to remove functionality.

What should a writer need in a CMS

Writers don’t need anything really, just a blank canvas to write without any interruption and the CMS should take care of the rest behind the scenes. Now one thing I want to point out is that writers have a flow, or rather anyone writing anything has it. We zone in and want to write as fast as possible without stopping our thoughts. The quicker we can get the words and ideas from our head onto the screen or paper the better and longer we can stay in the zone without breaking focus or being disturbed.

A CMS should achieve the similar effect of how we were writing a school essay onto a piece of paper. Medium and Paper do this wonderfully but they aren’t a CMS product. They are totally different things and were also meant for different use cases. They don’t have sections or components which may be required for a CMS site. One is for blog posts and stories and the second one for just writing things down with a nice flow. You could say or look at it just like one big chunk of concrete wall text and that’s it, but CMS is a wall of bricks.

A CMS has a big problem here, it was never designed to be anything like those editors. It takes many different data inputs, which are then ordered and displayed hierarchically in a well designed and presented structure. It can be just bits of information but it can also be a blog post or a unique layout. And to make things even more complex, all these inputs can be hidden either behind some popups (wp page builders are a sin here) or even tabs, accordions etc. Breaking the whole page into little pieces.

Whoever tried changing something with these CMS setups knows that it was really hard to find that specific information and change it. It would take them even more time if they were making a change to someone else’s content. Same goes for a designer or developer tasked with changing some content (yes, that does happen in small teams/companies).

WordPress, on the other hand, does well for a CMS and data manipulation but falls short with the flow and writing experience for similar reasons as mentioned above. Distraction-free writing mode? Really?

Putting content into specific layouts or content blocks or putting content as a blog post or an article need to have a similar experience. Layouts are just preconfigured blocks.

Designers and CMS

Not using the “lorem ipsum” for any of the design projects, designers need to have real information and real data which they structure and laid out meaningfully so the consumption of information for the reader is as easy and enjoying as much as possible.

Print and magazines do this really well and websites should have a similar or even better experience. Context is important here and even if the information is really complex a well-designed layout will make it work.

A CMS shouldn’t be a limit for designers or rather the structured content, ever. A CMS needs to satisfy all the creative ideas, imagery and even animations that make the content interesting and alive. But one thing I would do here is to limit it to some specifics. Analyse the content and create blocks and layouts, not the other way around. Changing the content for the sake of making things nicer or “good looking” is missing the point. A designer needs to be able to portray that content in the best way possible while keeping things in harmony and using the style guide rules.

Netlify CMS shouldn’t really give a designer or writer any options to change things or tweak colors, fonts etc. These things should be done upfront with a design system. If a new content requires new blocks or ways of portraying it, they need to be designed, developed and made to work in the CMS.

The basic HTML elements like heading, blockquotes, bold, italic etc. need to be designed based on a style guide. The CMS needs to have these options integrated as defaults.

Most of the design part will probably be separated by Netlify CMS and it should be taken care of in the front-end layer of the site. But there still needs to be a connection for manipulating (not designing) things in the CMS.

Where am I going with this?

For creating meaningful solutions you need to think and look at things from a wide angle. With any project, we need to analyse things and do some research.

From the above, you can already see a path or a solution which would work for Netlify CMS really well.

So the goal is to create a CMS Editor with uninterrupted writing experience and that as simple and lightweight as possible but flexible and extendable to take on anything. 

Now that’s a nice challenge.

How to make writing to a CMS feel like writing a story on a piece of paper

Let’s try and put things together now. If we look and analyse how we write things in different editors, we can see that we use a mouse or a trackpad to click things. This is a big interruption of the writing flow that can be improved. We also want to write in Netlify CMS and not in Google Docs, Paper, Evernote or any other service. Someone needs to copy/paste things later and well… things aren’t as fluid as they should be.

How can we simplify this process? Well, Markdown does a great job at this and solves a big chunk of the problem already. It’s a great language to write things without interruption. Yes, it needs a bit of a learning curve but it will help write content massively entertaining in the long run. Writers may need to learn it but I think it will help them with the writing flow and quality of their work.

Also, note that we write things in one or more passes. We write, and then we edit so each pass can be a separate process really. For a writer, the 1st pass is the most important as things need to be written down before we forget about them, no interruptions, just pour things to the screen/paper. But what happens if we want at some point to add an image?

There are two things to do here, I would suggest not thinking about adding images in the 1st pass or writing, but if we do, we need to add a quick note/draft caption at a specific end of a paragraph so we remember to add it on the 2nd pass. We don’t want to search for an image at this point as it will break our flow and to find an image we may need quite a bit of time. The longer the flow of writing is broken, the harder it will be to get back into the “zone”. Also, later on, we start jumping through the article and fill in paragraphs here and there, which is the result of the flow being broken. It’s like writing one article at two different places.

The second pass begins when we have finished writing the article. We re-read it and tweak things here and there, fix typos and this is the part where we can focus on finding the images or other media embeds for the article. We visually add the context of the article to improve the experience making it more enjoyable and memorable.

The 3rd pass is really the repeat of the second pass. Things either changed, or we got new information. The 3rd pass can also be called editing and we can do it many times.

This process or workflow should provide a much better writing experience and produce higher quality content as a result. Yes, it may be a small learning curve, but we want to progress and improve right? If we continue to do the same things how will we improve anything?

The end of part 1

I will stop here and take a break as there’s been a lot of input already and I didn’t even write half of it. It was my process to first figure things out before creating something new and unique that solves or improves the product. There are many details I left out on purpose (as too much theory or rather philosophy can be boring, right?), but will be going through some of them in part 2.

In that part, I’ll focus on visually designing a system and user experience for the editor that will try and solve things but the main goal will be to design it in a way that writing or editing it, will feel really natural.

Some things to add to the brief:

  • should have the ability to add sections while writing
  • should have default and customisable content blocks/sections
  • should have pre-made templates/layouts for specific content collection pages (example, job posting)
  • should be easily usable by any of the 3 groups
  • should give an experience of uninterrupted writing, the writer should stay in the zone from the beginning to the end of the article