This article is the fourteenth edition of the Advent of Patterns series. In this series, running from December 1st to December 24th 2024, I will document one design or programming pattern I have noticed recently. Read more about this series.
When I am working on written documents – from blog posts to documentation – I like to see a preview of what I have made before I publish it. This helps me build confidence that the document will be seen as expected when it is published.
Change previews can be implemented as:
- An asynchronous preview that you can run at any time, or;
- A live preview that refreshes every time you make a change.
Supporting previews implies that there is a distinct publishing and development step, such as is the case in writing and publishing content in CMS systems like WordPress or writing, testing, and deploying code in software development.
Below, I’ll talk through examples of both asynchronous and live previews.
Many blog softwares can generate a preview for a blog post. For example, if you write a post in WordPress or Ghost, you can press a preview button to see how the post will look when it is published. The preview will be rendered in the same way a user will see it, allowing you to evaluate if a post is formatted as you expected.
These previews are asynchronous in that you need to press a button to see the preview rather than seeing the changes live.
My blog software – which I am building myself – doesn’t have change previews yet. This means that there can sometimes be formatting errors on the final page that I didn’t catch. I am still thinking about ways to better preview blog posts.
Often, asynchronous previews have links that you can use to share a preview. For example, Ghost can create private links that you can share. I use such links at work when I am seeking final permission to publish a blog post. The preview link gives us both confidence that a post is ready to be published.
Change previews are commonly used in software engineering, too. As part of a development process, many organisations have staging environments that can show changes in an environment that is almost exactly like production but without production data. Staging environments are useful because you can preview changes before they go live. Some organisations will create links that show changes on specific branches, too.
In software engineering, ppreview links may be used by engineers to test changes, QA engineers to validate software against test cases, product owners, and other stakeholders who want to test a feature before it goes live.
Webflow, a website making tool, supports staging links too. When a colleague makes a design change in Webflow, the staging link can be shared so that the team can share feedback and run further testing.
Live previews are available in static site generators. This lets you see changes after you make them while you are developing in your local environment without having to manually run another build. Hot reloading reduces the friction between making a change and seeing a change.
The text editor I use to write blog posts, Typora, renders markdown in real time. This means that I can see the structure of my document as I type. This is important to me as I can more easily understand the structure of my document and reduces the amount I need to think about the markup I use. This is a live preview in the sense that I can see my markup rendered live, but it doesn’t show me how a post will look on my blog because I my blog is separate from the text editor.
Change previews let someone see the results of a change before it is published. They are used in blogging software, software engineering, and anywhere where there is a “publishing” phase. Change previews give the user confidence that their changes work as expected by showing an environment with their changes or document in which they can experiment. With this environment, errors can be caught before changes are published.
