FYI

Scott and Piccalilli are not affiliated with any of the products mentioned in this article. They’re nice tools that we recommend trying out, but we gain nothing from any links or signups. We also haven’t consulted with any of the mentioned products in the process of putting this post together.

Design tooling is in a pretty weird place right now. On the one hand, we’ve evolved from the struggle bus days of trying to wrangle Adobe products into doing something useful, and design tools have never felt more robust and seamless than they do right now.

On the other hand, SaaS has turned the web into a clusterfuck of aspiring monopolies, subscription models, yearly price hikes and AI pivots that literally no one asked for. Design tooling has not avoided such a fate.

We have, ostensibly, one ‘serious’ option when it comes to professional design work: use Figma, and go fuck yourself. This article could easily be 2,000 words of anti-Figma diatribe, and while that would definitely make me feel better, it wouldn’t really be useful, and in a shocking turn of events, I am trying my best to write something useful.

With the incessant push for profit, growth and shareholder appeasement, picking tools from a small pot of SaaS options that we’ve somehow convinced ourselves are the only viable solutions on the market is an increasingly frustrating exercise.

This is even more stark when we look at the relatively slim pickings we have when it comes to our design tools. Figma’s aforementioned chokehold on the industry leaves us beholden to whatever decisions eventually trickle down from the boardroom obsession with money above all else. Recent releases of their abysmal AI tooling and their frankly irredeemable ‘Sites’ offering show us that these decisions don’t always benefit us.

When I was putting the plan together for the Mindful Design course (which feels like a decade ago at this point, wild that it’s been less than a year) I desperately wanted to avoid using Figma. Not only would I be implicitly advocating for any tool shown or used in the course, I’d also be asking people to use them themselves and, subsequently, pay for them.

This was honestly a weird position to be in. Up until that point I hadn’t really considered how much I was locked in to the Figma ecosystem. All my early stage design work was in FigJam, and the idea there was an alternative to Figma for large-scale prototypes and product design was something I never really reckoned with to any serious degree.

Nevertheless, the goal was simple: find a set of tools that were either open source, free, or affordable that also wouldn’t require compromising on quality, and allow for industry-standard output. I decided early on that if I couldn’t create something I would be happy putting in front of a client, then it was out of contention.

With that in mind, the first few months of planning the course revolved around breaking out of the Figma ecosystem and putting as many free and open source tools to the test as we could. Now, the fact this article exists shows that we succeeded on that front, but what I honestly didn’t expect was that the experience would be so good (and honestly quite liberating) that I’d actually be switching my whole design setup to free and open source tools.

Open source isn’t perfect

One last bit of exposition-dumping before we dive in to the wonderful world of not paying SaaS leeches a monthly fee to be rooted in an extractive ecosystem: open source is not a silver bullet. Open source tools aren’t charities, they’re not inherently democratised, and they often come with their own sets of problems and frustrations. As most developers can attest to, as liberating as open source tooling can be, it can just as easily lead to infuriatingly fragmented and inconsistent setups.

Open source also does not guarantee ethics. Many open source projects are funded and in many cases owned by for-profit companies, many of whom are actually fucking horrible and use their contributions to free and open source offerings to essentially FOSS-wash their reputation. Yes, I’m looking at you, Vercel and Meta.

This was yet another consideration when I was trying out tools: are they owned or maintained by complete pricks? If so, maybe don’t use them.

I’m saying this now, because I know for everyone with a rose-tinted view who sees Free and Open Source (FOSS) as purely altruistic philanthropy, there’s someone on the other side ready to be contrarian and ‘well actually’ about how, for example, React is open source, and is funded by the same people who ushered in a brand new flavour of mindfuck technocratic capitalism.

With all that in mind, let’s drag me away kicking and screaming from the political discourse and into that previously promised writing of something useful.

The design ‘stack’

Confession time: I’ve branded myself as a full-stack designer for a while now. I like the term full-stack developer and I like applying it to my role as ‘a designer who is a little bit shit at everything’. While your development ‘stack’ might include back-end and front-end frameworks (or good old HTML and CSS), the design ‘stack’ I believe includes everything from early stage research to final prototyping and hand-over, and arguably into more ‘front of the front-end’ things like design tokens and coded components.

When I talk about an open source design stack, then, I’m talking about using free and open source tools to assist with every stage of a design process. I’m going to break the rest of this article into the various stages of the design process, and the tools I like to use to be a little bit shit at everything there.

Planning and briefing

Every good project should start with a few words. I don’t really care if that’s a couple of sentences explaining an idea or a meticulous, multi-page spec document that covers all the bases. One of the worst things I think anyone can do is try and draw their idea out in rectangles before they can even explain that idea succinctly in words.

A good brief, good early stage documentation, and a place to write down any ideas that come to mind throughout your project are all essential. So, in a rather anticlimactic turn of events, the first thing we’re going to look for is something we can write words in.

Scott’s favourite: AFFiNE

AFFiNE (laborious casing aside) is basically a better, FOSS version of Notion. You can self-host or use their pretty generous free hosted version. Alternatively, if you don’t need cloud sync or collaboration, you can use it purely with local IndexedDB storage.

Their heavily-marketed AI assistant is a paid monthly extra and doesn’t come as part of the standard offering, which is fantastic, because you can fucking ignore it forever.

It’s an interesting spin on Notion’s collaborative, block-based document + centralised database structure in that they’ve just randomly slapped a whiteboarding tool into the app. Because why the fuck not? (Okay, it’s actually really good, and you can absolutely use it for all your brainstorming needs.)

I still really like Notion and I found it hard to break away at first, but given that I rarely need/want my data stored in a cloud DB, I was quickly enamoured with Affine's no-sign-in, no-cloud-storage offering.

Other tools in this space include Appflowy and Docmost.

Research and synthesis

If you don’t start your projects with at least a bit of observational research you absolutely should. If you do start your projects with research, do more. Thanks.

I split research into two broad themes, conducting and synthesis. For conducting research, the main goal is capturing raw data. For me, that’s almost always simply recordings of my observational research sessions.

Where the ‘magic’ of a research phase lies in in the synthesis phase. This is where we take all of our raw data and collate it in a way that actually makes sense, informs our problem space, and helps us make decisions. Think things like affinity maps, empathy maps, and Object Orientated User Experience (OOUX) boards.

Scott’s favourite for conducting: Jitsi Meet

My requirements for conducting research are pretty minimal: can I talk to another human and record that conversation? With that in mind, 99% of my remote research sessions have been Google Meet calls, because it’s kinda just the default, innit?

However, recently I’ve had success with Jitsi Meet, which is essentially Google Meet without the Google shenanigans. I don’t know what more to say here: you start a call, you invite someone else to that call, and you talk to them.

I don’t like recording calls to the cloud, so all my calls are recorded and saved locally via OBS.

Scott’s favourite for synthesis: tldraw

Okay, noticing a theme now, apparently normal casing is rare in open source tool naming. Aside from that, tldraw (often stylised as tl;draw which I kinda love) is a fantastic whiteboarding tool out the box.

Heading to tldraw.com will get you straight into a gorgeous whiteboarding experience, but the tldraw project is far more than that, essentially positioning itself as an 'infinite canvas SDK'. Essentially, the whiteboarding tool is the 'flagship demo' for the possibilities of the SDK, and we can use it for free. Lucky us.

I have to give a big shoutout here to Excalidraw as well. Another fantastic infinite-canvas whiteboarding tool, with my favourite approach to onboarding I think I’ve ever seen. Similar to Affine, everything is saved locally to browser storage, something I’m a huge, huge fan of.

Prototypes

As much as I love writing and whiteboarding tools, I think we can all acknowledge that the main character of the design process is your prototyping tool. I’m including digital wireframes in this, too, because the only true wireframes are done on A3 paper with the chunkiest fucking Sharpie you can find.

The supposedly flagship part of our process requires a tool capable of matching the lofty standards of [checks notes] being able to draw the correct rectangles.

Scott’s fav: HTML and CSS

I am once again begging you to learn how to code. For me, the best tool for designing things that will eventually live in the browser, is the browser itself. HTML and CSS are not hard to learn. People just massively over-complicate front-end tooling these days. If you can learn how to use Figma's acid trip of a variables panel, you can learn the basics of semantic HTML and how to style it with CSS.

Scott’s (other) fav: Penpot

Okay, probably the 'real' answer here, and the design tool that I am most excited by and most unabashedly fanboyish about. Penpot is an absolutely fantastic design tool. It’s basically Figma but good. It’s also designed and built by people who actually understand what designing and building for the web looks like.

Penpot not only matches Figma in almost every case that actually matters, it exceeds it in many of the most important areas of designing for the web. I could write a whole piece purely based on what Penpot gets right that Figma gets wrong, but a few highlights include (but are not limited to):

• Being able to add margins to elements in a layout (honestly, this alone makes my life infinitely easier)
• Tokens that actually match the design tokens format module spec
• Tokens that can be exported as JSON natively without shitting the bed or relying on jank plugins
• Being able to reference token aliases and perform mathematical operations in token definitions (hello, logarithmic type scales)
• A 1:1 representation of the CSS box model and faithful representations of CSS grid and flexbox
• Their glorious, fabulous, wonderful approach to Typography tokens

Penpot was honestly the biggest surprise for me when putting the course together and putting these tools through their paces. I was kinda convinced that I’d come crawling back to Figma as soon as the course was done, that Penpot would be a welcome distraction but ultimately fall short somewhere down the line. After all, they’re a small team, with an open source product, competing against Figma, who are ostensibly worth an absolute colossal fuck tonne of money.

After my first few forays into Penpot I kinda thought that was the case. “Look at me. Right again,” is what I would have said if I didn’t roll my sleeves up, get rid of the Figma-brain, forgive the admittedly less-than-stunning UI design, and give it an honest stab at working for me.

After a couple of weeks in Penpot, I found myself actively dreading opening Figma to do my 'real' work. Back to constantly being reminded of their shitty AI tools. Back to autolayout being an absolute disaster. Back to their keyboard shortcuts being changed around what feels like every two weeks.

Penpot is a breath of fresh air. There's enough there now to actively replace all but the most locked-in Figma projects, and they’re improving things in meaningful ways, not actively destroying the things that made the product good in the first place, which seems to be Figma's approach over the last 18 months.

All of my design work outside of The One Big Client That Is So Locked In To The Figma Ecosystem It Would Cost A Hundred Grand To Unfuck is now done either directly in code, or in Penpot. I’ve even been able to cancel my Figma subscription. What a day that was.

All of that is to say, if you're a web, product or UI designer and find yourself increasingly jaded with what Figma has become, you owe it to yourself to give Penpot a whirl.

The other bits

I’m pretty chill when it comes to my process and tools. Give me a big stack of paper, something to write words into, somewhere I can lash sticky notes around, and something I can draw rectangles in and I’m happy.

I also don’t do much in the way of visual or brand design these days, to the delight of my much-more-talented friends who have had to find increasingly creative ways to tell me to fuck off with my 'first pass at a logo for this project' DMs.

Unfortunately, for visual design and brand design in particular, there really aren’t that many options. No one seems to be doing anything interesting in the space, so much so that GIMP is still the most-recommended tool when it comes to traditional visual design (a la Photoshop). I love GIMP, but come on, it’s pure, unadulterated “I see your stepdad’s been on the Linux forums again” vibes.

Editor's note: I'll allow it.

For vector work, we’re eating even less well. Inkscape does a passable impression of if the good parts of Illustrator all somehow fell out the app, but it’s dated and horrible in its own way. If all you need to do is tweak an SVG then it’s fine, but a quick poll of my contacts showed responses that ranged from ‘meh’ to ‘are you back on your meds yet?’

Visual and brand designers: I’m sorry. Really.

Breaking away from SaaS

Hopefully that’s been a decent run-down of the tools we have at our disposal that aren’t paywalled by the money-guzzling vampires that prop up the SaaS landscape. While open source tooling isn’t the silver bullet that many folks naively believe it to be, it’s a damn sight better for us, the consumer, than the brainchild of technofeudalism and hypercapitalism.

The market right now is one of monopolies. Where any big player that is remotely threatened by a startup can buy or acqui-hire their way to devouring any competition. So much so that there’s a non-zero number of startups being formed with the express intention of nipping at the heels of Figma, Vercel and the like in the hopes of being swept up for an undisclosed fee. Which is embarrassing but okay lads go wild.

When the market is this many layers of fucked, we’re lucky that we have alternatives. By using, supporting and contributing to nice products built by nice people, we can go some way to making open source a viable and sustainable model in whatever future in which we find ourselves.

We also need to move away from seeing open source tools as 'hobby' projects. Penpot are showing that it’s possible to monetize open source design tooling without turning into absolute shitheels, and folks like Ghost and GitBook are uniquely positioned to be market leaders backed by open source offerings.

The future can be bright for open source tooling, we just need to break away from the exploitative and extractive machinations of venture-capital-backed SaaS monstrosities.

Like a lot of black and white thinking, I’m not so sure the truth is so cut and dry, so I’m going to make a case for the off-screen menu being a better experience in the right context.

Moving beyond task-oriented thinking

A lot of User Experience (UX) research looks at interface design through a task-oriented lens. Testers may be asked to “find the newsletter subscribe form and sign up” or “look for information relating to this company’s returns policy”. UX insights like these work really well in a task-oriented context. When your users are in task mode it’s easy to see why it makes sense to keep navigation front and centre — the easier you can make it to find your way around, the faster and smoother the path to task completion. But while information gathering and task completion is one of the primary modes of engagement online, not everyone who visits a website has a specific task in mind.

A lot of the time we’re in exploration mode rather than task mode when we’re online — quite literally “browsing” the web. Maybe we’re getting an idea of a brand, poking around for inspiration, or checking out a link someone sent us. In this mode, we’re much more likely to dig around out of curiosity, or because something catches our eye. In this context, providing visible navigation might actually detract from the experience, aiding decision fatigue, and adding subtle layers of distraction from the content of the page.

Keeping the focus on the content

I’m a big advocate of designing for sustained, focused attention, especially where storytelling or long-form reading plays a key role in what you’re designing. Distraction is kryptonite to modern humans. If you’ve clicked a link on social media to read an article or check out a landing page, the last thing you need is a list of other pages tempting you away before you start reading.

Presenting a nav is presenting a list of decisions. In the quest for great UX, we should never forget that the decision that may prove the most valuable for someone landing on a web page is to stay a while and actually read the thing. To my mind, we can spend a lot of time debating UI choices, but if you nail your information architecture and serve up great content, the biggest thing you can do to help your audience is to focus on designing a great reading/browsing experience. The fewer choices you present throughout the design, the less likely it is that decision fatigue is going to eat away at your content’s ability to hold your reader’s attention.

Watch the video.

Off-screen menus can be easy to access

With a fixed position trigger button, the off-screen menu can always be a click/tap away, no matter how deep you’ve scrolled. I find this approach works great for a lot of service-based brand websites, where brand storytelling and does the heavy lifting from a sales perspective. In that context, you want to maintain focus while on key landing pages, but users may want easy access to key pages to get a sense of a company’s services, products and previous work. Conversion focused landing pages are another example of where there’s a clear benefit to getting the menu out of the way to keep user’s focus on the in-page content, while allowing those not ready to commit yet to access other pages and have a poke around.

Making use of the extra real estate

Sometimes navigation doesn’t call for anything more than a simple list of links at the top of the page, but off-screen navigation can open up the opportunity to experiment with different visual weightings and groupings for these links — making the most of the extra space in the menu canvas.

The Becolourful website keeps the focus on the larger primary links, while giving links to secondary landing pages a different treatment, with a much lower visual weighting and clear separation through lower proximity and vertical orientation. This keeps the focus on the pages that play the most important role in building trust with prospective new clients.

Quarterre’s website takes a similar approach of using scale to add hierarchy to the navigation links, while also using the additional space in the menu canvas to include contact details, which serve to highlight that the studio has offices in London and Denmark.

Another plus point for the off-screen menu is the ability to design a list of links with a vertical orientation. This removes the risk of nav items wrapping to multiple lines, or having to reduce menu item font size if the ideal nav architecture takes up a lot of horizontal space. Instead, with a vertical list we can take advantage of automatic scroll overflow and give the whole menu a bit more breathing room. For sites where navigation is CMS controlled, it’s also nice to know that new pages won’t break the menu design!

Aesthetics and brand expression

There’s another way that the extra screen real estate can help the effectiveness of the website too, and that’s by providing a canvas for visual interest. People buy with their eyes. On a cognitive level, we process images 60,000 times faster than text. The visual choices we make in a design are a tool we can use to harness cognitive processing and enhance focus and concentration when executed well.

Watch the video.

The decorative type and bold colours in Sister Mary’s menu design serves not only to enhance the brand’s visual identity but provides visual stimuli that engage on a sensory level, making the experience more memorable. Visual stimuli also influence our ability to concentrate. It’s a careful balance, where adding a little visual interest can aid cognitive processing, command attention and really make an experience memorable. Adding too much can be distracting and add to our cognitive overload.

Perhaps the Sister Mary example treads a little over the wrong side of the line with its level of motion. On the one hand I could see the theoretical argument in favour of this level of motion — for a simple site with five pages, most people will probably interact with the off-screen menu very little in the course of a visit. The off-screen menu shows off their creative skillset and fits the brand, which feels crafted, heavyweight and creative. But with the motion toned down a little, I think they’d be in the sweet spot for their context.

Watch the video.

This off-screen menu from the Eislab website is a great example of using interaction design to showcase the brand personality and add some fun to the experience. The way they use scale to emphasise their product page is a really smart piece of design.

All too often discussions around user experience focus on usability, under the premise that usability trumps aesthetics when it comes to creating an effective interface. The brilliant UX Myths does a great job of debunking this bias. Attractive things are perceived as more functional, more trustworthy, and more desirable. It’s why cheap wine tastes better in a nice glass, and why the iPod dominated the MP3 player market, despite it not being the first, or arguably the best on the market. Check out Don Norman’s book Emotional Design for a deep dive on this subject.

Context is everything

Going back to the UX research, the most critical thing you can do is establish connections between the data and your context. For example, in this Nielsen study, the researchers noted that “If people use hidden navigation, they do so later in the task than if it were visible”, and that "people were significantly more likely to use the navigation (whether hidden or partially visible) on mobile than on desktop”. If we’re designing a site with a primarily mobile audience, and we’re using on-page storytelling to guide people through the experience, then the data supports the idea of using an off-screen menu to minimise distraction until navigation is needed.

The underlying message I’m putting forward here is that making design and UX decisions should always be based on your project context. There is no right or wrong when it comes to UX, only context and compromise. You know your context and you can consider the UX decisions you make as a series of judgement calls that balance different configurations of compromise within that context.

It may be that an off-screen menu is perfect for the project you’re working on right now. It may not be. That’s not really the point. What I’m really saying here is don’t be afraid of going against the common best practice if that feels right in your context. See how it performs, and iterate on it.

Daniel Schwarz wrote a great deep dive into the current proposal for these two CSS properties, but in this article I’d like to give you an even more solid understanding of the problem this new CSS capability is solving.

Aligning text on the web has historically involved a level of compromise. Much of this is down to how fonts render in the browser, and inconsistencies in how different fonts take up space within their text box.

This diagram shows the text box for Moderat Extrabold, the headline font we use for Piccalilli. The box is cropped pretty tight horizontally, but vertically there’s a lot of space above and below, which can make typesetting tricky, especially when combining fonts which may have different amounts of space above and below (which we’ll come to later).

What makes up all that extra space? There are a lot of factors involved, and the spacing can differ greatly from font to font. Let’s break it down.

A primer in font metrics

It’s good to have some context for the metrics that influence the spacing within a font. Here’s a visual breakdown of the vertical metrics within Moderat Extrabold.

The ascender and descender lines mark the boundaries of the font’s geometry. In general, ascenders and descenders will extend to these lines. Letters with curved or angled forms generally overshoot these lines ever so slightly, to achieve visual balance alongside their straight-edged counterparts.

As you can see below, in some fonts, certain ascenders will sit below the ascender line. Check out the lowercase “t” here in Moderat below, for example.

The cap height, as the name implies, marks the height of a font’s capital letterforms. It often sits below the ascender line, but in some fonts the cap height and ascender line can be at the same height.

The take away here is that the spacing dynamics within the characters of your text will differ depending on the font you’re using.

Font sizing

In digital type, font metrics are all relative to font size. Let’s imagine we give a paragraph element a font-size of 1em in our CSS. What aspect of this font is 1em tall? The short answer is we don’t know because the font size does not give us any reliable information on the size of the characters within a font or the metrics within it.

To help understand why, it’s helpful to know that when a type designer is creating a font, they’ll design each character within a box known as an em square, which acts as a grid container for the glyph. This is not the same unit we’re applying in CSS, as the browser calculates em values differently than traditional type design. If our paragraph with font-size: 1em renders at 16px, what’s happening internally within the font is that its em square container is being scaled to 16px tall. Inspect the element in the browser, and with a line-height of 1, the element’s bounding box will be 16px tall. But within that box, the positioning and sizing of the actual letterforms are totally up to the font designer, which is why they can vary so much from font to font.

Although the font size set by us designers tells the software at which size to render the em square, the type design within that em square can theoretically sit wherever the type designer wants it to. The horizontal and vertical positions of the marks that make up any given letterform are very much an arbitrary decision, so, like many things in type and typography, there are no hard-and-fast rules.

— Elliot Jay Stocks

This variability is a key consideration when swapping a font, or using multiple fonts in a project. Check out Elliot Jay Stocks’ write-up for Google for more on this.

Above is a comparison of Inter with Josefin Sans set at the same font size and a line-height of 1.0. The text box is marked in red, and the cap height, baseline and descender line in yellow. As you can see, whilst both text boxes are the same height, Josefin Sans’ baseline sits higher than Inter’s, and the spacing above and below the two fonts is markedly different. Notice that both fonts include ascenders and descenders that extend out of their text box too.

To show an example that takes this to extremes, here’s Zapfino. Check out those swashes which are miles out of the text box. What’s also interesting here is that the cap height sits a way outside of the text box too. Thinking back to the flexibility type designers can employ in designing their fonts within the em square, this example really demonstrates that sizing and spacing within a font can be a bit of a wild west at the extremes.

Leading

The final piece of the puzzle in understanding how text boxes are calculated in CSS is line-height, or “leading” in typographic terms. In traditional metal type, the spacing between lines of text was set via lead strips. These spacer strips were added between lines. The CSS approach to leading works a little differently, in that spacing is added both above and below each line of text. You can think of this as a kind of “half leading”.

With line-height set to 1.0, an element’s text box height will equal its font-size (multiplied by the number of lines of text if it wraps). In the case of our paragraph example, the text box will be 16px tall. Change the line-height to 1.5, and the text box grows to 24px tall, with 4px of leading added above and below. And if you set a fixed line height rather than a relative one, the browser just sets the text box to match the line-height and distributes any space evenly above and below.

Let's see how text-box-trim will help us

When you break it down, the extra space within an element’s text box is quite simple to understand. Just take the font size and add half the leading above and below. But as we’ve learned, it’s the extra space within the font itself, and the variability of the character sizing and positioning within different fonts that makes this much more tricky to work with in practice.

With text-box-trim we gain control over which boundary line text boxes are cropped to, and finally we can trim away this extra space to work with a font’s actual visual height.

One of the ways we’re planning to use this feature to improve typesetting at Set Studio is within our favoured fluid spacing system. We use a spacing scale that’s based on multiples of a base unit, which we combine with utilities like flow to keep a sense of rhythm between all the elements on a page. But in practice, the extra space within text boxes has meant we’ve had to let go of the idea of creating true vertical rhythm for text elements within our spacing system.

We’re pragmatic and happy to live with this for the sake of creating designs that work with the medium of the browser. But when a little bit more support comes for text-box properties and we can trim away that unwanted extra space, we’ll be all over it, as a progressive enhancement.

.prose :is(h2, h3, h4, p, ul, ol, li, blockquote, figure) {
  text-box: cap alphabetic;
}

Here we’re trimming text elements within .prose content to the cap height and baseline. Our prose now nicely follows our fluid spacing rhythm!

Applying a trim like this could — depending on the font as we’ve discussed — cut a fairly severe amount of spacing from between your text elements, so it’s very likely you’ll want to increase the spacing when this is applied. Hence our slight trepidation about using text-box in production yet.

It’s worth bearing in mind that design tools like Figma treat text spacing in a very similar way to the browser, with leading above and below, so spacing decisions during design will have been made with this extra spacing in place.

To account for this, we can bump the flow space up a step within our spacing system. Because our CSS is affecting wider elements via the change to --flow-space, we’re going to fence the code in a @supports query now because we only want this to apply if text-box-trim is available to us.

@supports (text-box: cap alphabetic) {
	.prose :is(h2, h3, h4, p, ul, ol, li, blockquote, figure) {
	  --flow-space: var(--space-l);
	  
	  text-box: cap alphabetic
	}
}

Figma has a setting that lets you toggle ‘vertical trim’ for text elements, under the additional typography settings. If you’re planning to use text-box in your code, it’s a good idea to design with this setting on. And test designs in the browser with and without trimming the text box to make sure both the reading experience is solid in each case. Readability is more important than perfect vertical rhythm.

Another good example of where these new CSS properties will help us improve our designs, is making precise vertical alignment of text and imagery like this design from Marko Cvijetic on Dribbble much more easily achievable.

One of the most common use cases for a lot of us is visually centering text within elements like buttons or notifications. This is especially handy for fonts that have awkward spacing like Josefin Sans.

There are plenty of creative uses for text-box-trim too. In this design I placed headings with their baseline flush against sections below using negative margin, like this:

.footer-heading {
	margin-bottom: calc((var(--space-3xs) + 0.072em)* -1);
}

It’ll be nice to be able to achieve effects like this without resorting to magic numbers, thanks to text-box-trim.

I used a similar approach to add baseline borders to headings in another project, but couldn’t achieve perfect baseline alignment in Firefox. With text-box-trim this effect could be layered in as a progressive enhancement, with the lines only added where the browser supports it.

I’m excited to see what people make with these new CSS properties once they ship!

Latest support

See the latest browser support for text-box-trim, text-box-edge and text-box here. As with all newer CSS specifications, the syntax might change as it evolves, so I recommend keeping an eye on the discussions.

FYI

This is the third and final part of our series on redesigning Piccalilli. To get the most out of this article, we recommend you start from the top.

At this point, we’ve completed the design work and have also produced a backlog of production tasks, so I’m sorry to say, the build is actually quite boring to write about.

It’s boring because at this point, almost all eventualities should be accounted for, so the developers only have to concentrate on writing scalable, maintainable code.

HTML only build of the site

What’s the best way to write scalable, efficient and maintainable code? It’s not faffing around, arguing about frameworks, that’s for sure. It’s all about getting the baseline experience — the foundations — of the site as solid as possible and the best way to achieve that is concern ourselves, in terms of output, solely on HTML.

Sure, we’re running with React and JSX on this project. It’s because we know that Astro will not render a massive bundle of bloated client-side JavaScript by default. Working with React components means we can effectively and efficiently move platform if Astro doesn’t work out so good in the longer term, along with enabling working with Storybook easier. Regardless of the technology choices for components, we want to make sure the output HTML is in tip-top shape. A framework won’t write bad HTML, it’s people that fall short more often than not.

We add a very small amount of CSS to utilise the system font stack because raw HTML makes our eyes sad, but hopefully you can see, it’s super paired-back. It’s much easier to scan the structure of the page like this too.

We build the whole site as HTML, giving us an end deliverable of a HTML-only, fully functional webpage. There's no client-JS interactivity at this point, but ultimately, we want the minimum viable experience to be our solid foundation.

We also use this phase of production to get the structure of the pattern library in place. In our case, this is using Storybook. Our focus for components now is less how they look and more what the structure of their output is and also the structure of the data that is passed between them.

export interface Topic {
  label: string;
  link: string;
}

export interface TopicsListProps {
  heading?: string;
  topics: Topic[];
}

const TopicsList: React.FC<TopicsListProps> = ({ heading = 'Topics', topics }) => {
  return (
    <nav aria-label="Topics">
      <h2>{heading}</h2>
      <ul>
        {topics.map((topic, index) => (
          <li key={index}>
            <a href={topic.link}>{topic.label}</a>
          </li>
        ))}
      </ul>
    </nav>
  );
};

export default TopicsList;

It’s really useful to be focused on a small number of things at any time. Separation of concerns really helps with that and with the HTML-only build in place, we can move on to CSS.

Integration of CSS

We built the front-end already with the prototypes, so in terms of applying the correct design tokens and overall look and feel, we’ve already solved that problem.

Our focus now with CSS is putting all of our effort on long term maintainability. We know how to build the front-end of the site, but we’re at this point, thinking about future iterations of the design and what’s coming up in the shorter term.

A good example of this is the theming system we’ve implemented, which you can read about here. We’re not, y’know, going to design loads of themes for the site that can be toggled, but instead, once the components are in place — structurally — the theme is what applies the look and feel. An immediate need for that theming system is dark mode.

With that in mind, all of the components look a bit like this:

.badge {
  display: var(--badge-display, inline-flex);
  border: var(--badge-border, var(--stroke));
  padding: var(--badge-padding, calc(var(--space-2xs) * 0.5) var(--space-2xs));
  font-size: var(--badge-font-size, var(--size-step--3));
  font-family: var(--badge-font-family, var(--font-display));
  color: var(--badge-color, var(--text-dark));
  text-decoration: var(--badge-default-decoration, none);
  text-transform: var(--badge-text-transform, uppercase);
}

.badge:is(a):hover {
  background-color: var(--badge-hover-bg, var(--color-dark));
  color: var(--badge-hover-color, var(--color-light));
  border-color: var(--badge-hover-border-color, var(--color-dark));
}

You might think that is overkill, but it allows two things. First, setting up a different colour scheme is as simple as this:

:root {
  --badge-color: var(--text-light);
  --badge-hover-bg: var(--color-light);
  --badge-hover-color: var(--color-dark);
  --badge-hover-border-color: var(--color-light);
}

Second, by making nearly everything configurable based on a solid HTML structure means that if we want to redesign or refresh the UI in the longer term, technically, we should be able to define a new theme configuration and be done with it. It makes future iteration prototypes much quicker too.

The most realistic use-case for this theming is that every course we publish will have a specifically branded landing page that doesn’t necessarily match the overarching Piccalilli look and feel. We can theme those landing pages with the theme system, including large layout differences quite easily. It also means there is scope for articles to have art direction in the long term, too.

Wrapping up

We’re building this thing to be as low effort as possible to maintain so we can focus all of our energy on producing excellent content instead. The way it’s coming together, I think we might have done just that.

I hope you’ve enjoyed this series on redesigning the Piccalilli site. I’ve certainly enjoyed writing it. The next thing you see about this stuff is the actual live site very soon. We can’t wait for you to see it.

If you like the way we at Set Studio have approached this stuff, get in touch. We’d love to hear how we can help.

FYI

This is the second part of our series on redesigning Piccalilli. To get the most out of this article, we recommend you read the first part.

After getting through our first sprint we have now completed our second and last sprint of the prototype design phase of our full redesign of Piccalilli.

We’ve done the first sprint, so it’s time to move on to the next one. This is where we get into a lot more detail with the design and expand on what we’ve already got, mostly in the browser.

We had good page concepts but we need a home page

Designing a homepage after other stuff? It’ll never catch on. Sure in a lot of projects, starting with the homepage spiders the rest of the design process really well, but in this context, the reading experience is the core of our design, so it makes sense to focus our early — and generally higher — energy levels on that.

With us nailing that (trust me, wait until you see it), we can confidently tackle the beast and the milestone at the most risk of stakeholder inference: the home page.

After deciding on the priority of content in the first design sprint, along with already getting a design system — of sorts — in place, we can get into — and back out of — Figma pretty damn quickly.

There’s two concepts here. One is a future homepage (left) and a version of the homepage that we’re going to ship in this initial iteration of the redesign. We’re not shooting for perfection at this point, more, we want to get ideas on to a page composition to see how it flows at a macro level.

The only discernible difference between the two concepts is that the future homepage will have a more expressive hero unit, which we will commission a trusted illustrator to work on, along with a primary action to see our courses. The first of which launches later in the year.

As you can see, a lot of the existing affordances, well, navigation is the same as the current homepage. That’s what homepages are at the end of the day: navigation pages.

What we have added though is the latest three articles, a tab panel for the popular content so you can see what’s currently popular and what articles have been the most popular over time. The hope is that if someone who has never read a Piccalilli article will be able to get a good vibe of the content that has resonated with readers. Later down the page, we’ve added a sign up section to encourage folks to either get new articles in their inbox or subscribe with the favourite RSS reader.

Watch the video.

Looking pretty snazzy huh? That’s the prototype by the way because of course, we smashed that out with junk CSS, just like we did with the rest of the prototypes in the first sprint.

Iterating based on how things feel in the browser

In the first design sprint, the aritcle page template looked as follows:

In this version we had the information about the author in a left-hand column and the prose of the article in the right-hand column. In a more macro view in Figma, this worked really quite well because the overall grid system felt balanced. The problem with websites is you never see the whole page in your viewport. In fact, we have no idea what viewport we’re going to be met with.

When we got the post page layout in the browser, it became pretty clear that the reading experience wasn’t up the the standard we were aiming for.

Having the content pushed out to the right looks really awkward when there’s nothing else in the sidebar. We definitely don’t want to be distracting readers with docked elements either!

It’s at this point where you have to step back and really work out what the problem is and start to play with ideas. The idea that stuck for us was both, putting the sidebar on the right-hand side and also, increasing the font size of the prose. Again, the typography felt balanced in Figma, but once we got it into the browser, we were less confident of that.

Watch the video.

The updated prototype made us much happier. Sure we’re working with pretty junk content here — it’s just an excerpt from an existing article. We’re going to get into the details of the prose design implementation during production because there are thousands of content combinations in the website’s content, so we’ll be much more efficient working with real content than faked content at that point.

The main thing is that iteration transformed the reading experience which is what we needed to get done at this point.

Finding issues and iterate on them

The benefit of junk CSS is we can find fragilities that we need to account for in production code. We can also find potential accessibility issues and oh boy, we found one of those 😅

Let’s zoom in on the full-blooded version of the website header for sec:

Watch the video.

The header looks good, but it’s pretty complex in its nature. There’s a lot of layout going on and yep, we opted for CSS Grid to give us the level of control we needed — especially responsively.

The problem we found — and as the video shows — was because of the ordering of content at a HTML level conflicting with the visual layout, we accidentally broke visual tab ordering which is an absolute no for us.

In this situation, it makes sense to completely rip the header apart, find what it is about our initial design that is causing problems then prototype a solution. That’s exactly what we did.

The problem at hand was we were grouping buttons on smaller viewports and visually separating them on larger viewports. We had to ditch that idea and maintain the grouping on all viewports instead which in hindsight was a better idea anyway. That’s the thing with approaching design in an iterative manner: you find these issues and are already in the right mindset to deal with them efficiently and effectively.

Analysing how the design will work in the real world and tightening things up

The last issue we faced to wrap up this sprint was elements that break out of the post layout’s column system. For example we have a component called a Preview Frame. This is an <iframe> that shows a real web page. It also has an affordance for you to resize the frame to see the page’s responsive adjustments. We use them a lot in topics like ‌Reality Check.

Looks pretty good already, right? Sure does! But one of the downsides of writing junk code for prototypes is you tend to follow the happier path, as it were. In important part of these design sprints is to go back through the prototypes and make sure everything is going to work with the real life website.

The way we’d built the post layout didn’t quite match what the real production environment would get us. Essentially, we’d closed one sidebar layout, rendered the preview frame and then opened another sidebar layout with the content that followed. Again, this feels totally doable, but we don’t want to be introducing complex platform code in Astro to handle that situation. Complexity brings fragility with it, which we don’t want.

See the Pen The super rough layout test we put together by Andy Bell (@piccalilli) on CodePen.

We needed to account for the break out element — our Preview Frame — to be a part of the content that resides in the left hand column. A really efficient way of working that out is to get away from the prototype and spin up an even simpler prototype like the CodePen above. Sure that thing looks like absolute garbage, but what it did do is help us calculate the simplest possible to the solution at hand.

We opted to keep using the Every Layout Sidebar, but enhanced its usage in the post layout with container units, z-index and container queries to both apply the border to the correct side, based on whether the sidebar had stacked or not, and also use the container units now available to us to size and stack the breakout elements efficiently. I’ll write up about that some more in another post.

We would have had to deal with this problem in production without our approach to design which would have caused a massive, rather stressful disruption. Designing actual web pages rather than pictures of them is hella useful.

Getting ready for production and wrapping up this sprint

With the prototypes wrapped up, the design sprint is now complete. We’ve got all the assets ready like premium fonts and also got our design documentation tightened up.

It’s all about planning at this point. We break the implementation of the design into two distinct parts. One part is a HTML-only build and the other is UI development. I’ll cover this in the next part of this article series

For us, it’s all about building a backlog of tasks in Notion and distributing them. With the backlog ready, we are now ready to build a real website!

If you like what you see already about this process and are looking for an agency partner, get in touch. We’d love to speak to you.