[placeholder]
Part 1 of this tutorial introduced you to the content types that are most common in technical documentation. You also evaluated a real-life example as a reader, and you may have realized how headings are essential to a good reader experience. It’s because readers on the web do not read – they scan¹ . People actually read 25% slower on the web² and they only read 20% of the content on a page³. (This data is from 2008; I’m scared to know the percentage today.)
In the same way the term “books” includes fiction, nonfiction, and biographies as genres, the term “technical documentation” includes many different content types. But what sets technical documentation apart from books are reader traits. These traits are a result of what the reader does as they read technical documentation – they use the app.
Writing is a learned skill. No one person is a good or bad writer. 🙂 When a colleague asked me to mentor them on technical writing, I searched for a single technical writing article, guide, book, or tutorial that addressed three key things. Since I couldn’t find one, I decided to create a tutorial on technical writing.
Last month we shipped the biggest change to our core website editing experience in ten years: Fluid Engine. This blog post addresses how we arrived at the implementation, in addition to walking through a few technical and user experience issues that were core to the development of this feature.
Imagine you are editing your Squarespace website on your desktop browser and you want to add great photos that make your site stand out. At that moment, you realize those great photos are actually on your phone. Wouldn’t it be great if you could cut out all the intermediate steps and directly access your phone’s photo library right from the desktop browser into your Squarespace website?
Recently, we introduced Background Art as a new way for customers to add graphics to their websites. This feature leverages WebGL to generate abstract animated graphics client side. These graphics can be seamlessly added to a web page, offering an alternative to images and videos for section backgrounds.
More so than any other level of the management chain, front-line engineering managers are the most attuned to the day to day realities of shipping software. Giving them a collective voice to surface what works and what doesn’t is critical to understanding the efficacy of organizational policy and process.
“The Nuts and Bolts” is a reoccurring Q&A with Squarespace engineers. Questions are compiled by their peers to guarantee we get right to the good stuff.
How do you make a website look good when you can't know how that website will look? It turns out this is one of the fundamental questions we work with at Squarespace. Since one of our goals is to make it easy for our users to create beautiful websites, we need to walk a delicate balance between constraints and freedom. So, how do we navigate that balance?
Squarespace's site builder allows our millions of customers to build their unique sites. The content within a given site, like text and buttons, live within small sections called blocks. Earlier this year, the Core Layout team addressed the largest shortcoming of the block editing experience: the block editors didn’t match the modern Squarespace product design language that other features have been following for years.
As our suite of products has grown from a website builder and commerce tools to encompass much more, synchronizing frontend state across these products has become increasingly important. Complicating the matter, some products run in iframes, whereas others run in the main browser window. We’ve developed a scalable approach to synchronization that abstracts away these differences, which we call Universal State.
Mobile apps have complex state, view life cycle, callbacks, and other things that make testing hard. The web has been around a lot longer than mobile and enjoys the benefits of long-established tooling and practices for testing. Because the world of mobile testing is relatively new, it takes time and patience to determine which best practices will work for your team.
