Let the record show, I was correct during the recording—and that’s the important part, right? Let’s review what Figma Variables are, then explore how to use them with your typography system.

A Brief Review of Variables in Figma

In Figma, Variables are placeholders for reusable values—just like JavaScript. These values include colors, numeric values, and more.

Once set, you can use them across different design elements in your Figma designs. Variables can also be shared with your team and used across multiple Figma files. This makes it easy to make sweeping changes to your design system with a few button clicks.

Using Variables to Control Typography in Figma

Previously, Figma’s variables were great for colors and spacing, ensuring consistency. However, we lacked the same flexibility with fonts. We had to use various styles and components for different themes or brands. Styles are still incredibly useful, but they lack the ability to change a single value used by multiple styles. This makes a task like switching a font incredibly tedious as you’d have to update every single style. In the course, we explored some approaches using various plugins in an attempt to automate this process, but the constraint was still there. This was a significant limitation and meant that we had to combine multiple approaches in order to maintain consistency throughout our design system.

Now that variables can be used with typography, you can now define variables for font settings. Figma now supports using variables for the following properties: 

• font family
• font weight & style
• font size
• line height
• letter spacing
• paragraph spacing & indentation

Each of these properties can be controlled using the same variable types that we saw when we walked through variables during the course, with numbers and strings being the most pertinent for defining typography properties. For example, you can use a string variable to define the font family.

With the values set, you can select a variable when selecting the font family in the left-side panel in the Figma canvas. Changing the variable will now change all text in your designs that reference this variable, allowing you to quickly make changes across your entire design by updating a single value.

Here’s a quick video demonstrating setting a block of text to a variable, then changing that variable:

There are still a few limitations. For example, variables don’t support percentages for line heights. Variables also don’t autocomplete for spacing or line height. Hopefully, Figma will address these soon.

Using Variables with Modes

In the course, we used Variable Modes to switch between light and dark themes as well as different responsive breakpoints. This approach also works with our new typography variables allowing your variables to point to different variables depending on what mode you’re in.

Imagine managing font sizes for different viewports. Create a “Typography” collection in the variables editor. We’ll create two modes: Desktop and Mobile. Depending on which mode we’re using the variables will have one of two values as seen in the screenshot below.

With these changes, we can switch to a smaller set of font sizes when designing for mobile. If we need to change the font size across all of our mobile views, we can simply update the appropriate variable. 

One thing that  makes variable modes powerful is that any layer set to Auto will inherit the any mode set on the parent. This means that if you switch the mode of the frame containing multiple text elements from Desktop to Mobile, all of your typography will automatically update to the values defined in the Mobile mode.

Being able to support different font sizes and spacing across viewports is the most compelling application of typography variables for me, personally. But, they could also be useful if you had to support multiple brands or themes in your design system. 

For example, you could have a different mode for each brand theme you support. You could also define different font families for your Android application as opposed to your iOS application. You could even define different font sizes for your marketing website as opposed to your application’s user interface.

What About Styles?

Prior to supporting variables within typography in Figma, we used Styles—and these are still useful. A variable can represent one value. Styles, however, can store a composite of values (e.g. font family, size, and line height). This gives us the ability to use variables as primitives, define the font, size, and spacing for our typography and then save that combination as a style.

It’s less about whether to use styles or variables and more about how to use styles and variables. What’s really cool about this is that you can use a single variable as part of a number of different types. Updating that variable will then immediately update every style that relies on that variable.

In Conclusion

Introducing variable support for typography in Figma is definitely a welcome change that we’re already beginning to leverage in our internal design system at Temporal. Variables now unifies colors, spacing, and typography using a single approach. Combining variables with styles is powerful, as well. Variables allow for individual changes, while styles provide preset options. This mix helps us build and update design systems with a lot less hassle.

That said, some features are missing, such as percentage line heights and spacing suggestions. But, I suspect those features will be coming soon and I’ll have to update this yet again.

In the meantime, I encourage you to take the typography in one of your existing designs and update using typography variables. I suspect you’ll be pleasantly surprised with how easy they are to work with.

I’m going to go through each feature with what goes through my brain. It is clearly noted “[these features] need not be applied indiscriminately” which I agree and want to underscore. These are mostly just nice ideas when appropriate.

Sidenotes

Danila mentions examples like this.

Love it. Very classy. My thinking is:

1. Start as semantic HTML footnotes. Put the footnotes at the bottom of the article, use numbered jump links down to them, then link back.
2. Progressively enhance to a popover, probably as a drawer.
3. If on a large enough screen, enhance to Nuclear Anchored Sidenotes. CSS’ upcoming anchor positioning API is going to be a godsend for this.

Easily Linkable Headings

The idea here is instead of something like this:

<h2>
  <a href="#particular-header">
    #
    <span class="visually-hidden">Jump Link to Particular Header</a>
  </a>
  Particular Header
</h2>

You just make the header itself a link like:

<a href="#particular-header">
  <h2 id="particular-header">Particular Header</h2>
</a>

Huh! I just never thought to do it that way because it feels like… I dunno they aren’t really links so it feels weird linking the whole thing. But the more I think about it the more I don’t hate it. Danila is doing it and even tosses in a little yellow fade technique for good measure I see.

To me, it’s more about an authoring experience that doesn’t make you think about it at all. All headers should be linkable, automatically. I’ve long been a fan of this itty bitty WordPress plugin that does it. Whatever you use to produce HTML from written content, automate it!

Table of Contents

I actually moved “Easily Linkable Headlines” up a few spots so that it would come before this section. My thinking is that once you have all headers linked properly, producing a table of contents is “easy”. Loop over the headers, display. The more complicated (but optional) thing could could do is nesting the headers. Meaning h4’s are nested under the preceding h3, which is nested under the preceding h2, etc.

I would think any major CMS will have some automated way of producing these things. I hand-wrote the PHP on this site to create the ones you can see in our sidebar on all posts (that have headings).

Showing Page Progress

I actually disagree on this one. I think those horizontal bars that fill up as you scroll down the page are cheezy, unnecessary, and unhelpful. They do make for a pretty good demo on using Scroll-Driven Animations though!

But we just talked about Table of Contents and Danila mentions a Table of Contents that highlights where you are, and that is actually pretty rad. Agreed on that one! Maybe I can implement that to our Table of Contents one day.

Grouping Series of Posts

It’s actually silly to write a series of posts and then not clearly link them together. Definitely do that! As many ways as you kind. That’s just good wayfinding for users. Nobody is going to be mad at you for helping you find your way around.

I built this kind of widget here on Boost for that:

As I mentioned, this is a WordPress site, so I used Advanced Custom Fields (very broadly useful) and the Post Object Field Type applied to a custom Block, so I can plop one of these little “Article Series” blocks where ever I want. Then I make the block a “Pattern”, so that I can re-use the exact same version of the Block all over the series. Update one, they all update, which makes it easy as you’re publishing over time. I realize that’s pretty WordPress-specific, but it’s worth building out something for this if you publish series!

Dialogs

Heck yeah! +1 to interesting post formats. We all use all sorts of messaging services, so having that available to use as a design element with posts is a great idea. We’ve done limited versions of it sort of replicating a Discord conversation a few times, but it doesn’t yet have that back-and-forth conversational feel, it’s just a list of posts.

I’d probably make a “left” custom design and a “right” custom design so I could just pick and choose them however makes the conversation look best. Oh and it would be a great use-case for text-wrap: balance so that the actual “text bubbles” would feel rather sized to their content nicely.

Generally: art direct those articles! Make them interesting!

Code Blocks with Origin

The idea here is showing off the name of the file that you’re showing off a code block of.

I mean, sure. Why not. I could see that being an interesting bit of metadata you might want to have available sometimes. I’ve just written one zillion code blocks in posts in my life and have rarely wanted it. I usually don’t care what you name your file, it’s just a concept. In Danila’s case, it was based on user feedback about a pretty complex series of posts about a very technical subject, so point taken.

Here’s my list for both authors and users of code blocks:

1. Syntax highlighting, server side. Subset of languages I care about.
2. I don’t want to have to escape special characters myself.
3. Nice design. Distinct but not distracting.
4. A copy and paste button.
5. Line numbers that I can turn on or off.
6. Ability to highlight any lines.

I do like the idea of allowing for clickable links within code blocks. This is a good one for the list because I think it would be extra tricky to pull off and quite a nice touch. You either have to give up on having the code auto-escaped (so the HTML within could stay actual HTML) or do something really clever, like not escaping HTML within comments?? or something??

.el {
  /* Try the <a href="https://scroll-driven-animations.style/tools/view-timeline/ranges/">View Timeline Visualizer</a> */
  animation: reveal linear both;
  animation-timeline: view(block);
  animation-range: cover 0% cover 100%;
}

Markers for External Links

I get the idea. The little box-with-arrow icon sorta like [⤴].

I can’t get behind it though. I’d say it’s just personal preference (I don’t really care if a link is “internal” or “external”), but I’ve also never seen data on if users find it helpful or heard any particularly strong or compelling opinions about it over my years. I do like it when links that are weird/surprising are indicated though, like:

1. Email links (e.g. mailto:)
2. Links to PDFs
3. Links to Media files (e.g. .mp3)

Those have way different behavior than just “go to new website” so a heads up is nice. And since they are all <a> links (probably), CSS can help:

a[href$=".pdf"]::after {
  content: " (PDF)";
}
a[href^="mailto"]::after {
  content: " (Email)";
}
/* etc. */

Danila’s idea of different markers for different destinations, while I’m personally not that into it, can be pulled off in CSS with a little indie web service.

Link Preview

I’d have a real light touch with this! It’s kind of unexpected behavior if you do something like make it a hover effect for a link.

Remember when posted about Standalone Web Components, I linked up David Darnes’ <link-peak> component which could help with this.

RSS Feeds

Yes! Old man shakes fist at internet!

If you write and publish your work on your own site for free, give me that sweet sweet RSS feed. Do it just for me. I’ll subscribe to it. I carefully curate my feeds and I love it. It’s simple technology designed to connect us.

Danila almost mentions linking up other people’s sites. Sure! Go for it! Have fun with it! You could call it a “blogroll”, that’s kind of the classic term for it. Or go even older-school with a “webring”, those are coming back a smidge. If you want to show the latest posts from other sites, that ups the difficultly and has performance implications, but it’s doable and you could have fun with that.

Design details that feel like magic.

I think it’s the focus on websites. 😍

Like, at all.

You haven’t needed it. You’re a web designer and you’re focused largely on UI and UX. Your skills with design tools, HTML, CSS, and team communication have served you well.

But you know what JavaScript is. It’s another part of the native web. It’s powerful. It can make websites do stuff beyond what HTML and CSS can do alone. You don’t even care to deeply learn JavaScript, you just want to get a ton of bang for the buck and learn things that will help you do your existing job better.

Let’s look at some things you could learn in a day that will give you that bang for the buck.

1) Learn to Select Things

In JavaScript, you often want what’s called a reference to an element. That is, a variable that represents the element in the DOM you’re trying to do something with.

Believe it or not, you’re at a real advantage here. Since you already know some CSS, those selectors are exactly what JavaScript can use to get it’s hands on those elements.

Say you had HTML like:

<header id="site-header">
  <h1 class="logo">My Website</h1>
</header>

If you wanted a reference to that <header> element, do it like this:

const header = document.querySelector("#site-header");

The "string" inside that querySelector() function is essentially the same as the CSS selector #site-header.

If you wanted the logo, you could do:

const logo = document.querySelector(".logo");

You might be thinking to yourself: but CSS classes might apply to lots of elements, how does it know which one to get? The querySelector function will select the first one it finds as it starts looking from the top of the HTML. If you intentionally want to look for and get a reference to a whole set of elements, look at querySelectorAll();

2) Learn to Update Classes (i.e. Toggle Stuff)

#1 is a big concept, but it doesn’t actually do anything, it just helps you get those element references. Now let’s enact a real change. Let’s add a class to that header element we’ve got.

header.classList.add("dark");

That does exactly what it looks like. It adds a class to that <header> element, so now the HTML (the “DOM”, really) will be like this:

<header id="site-header" class="dark">
  <h1 class="logo">My Website</h1>
</header>

As an HTML and CSS person, I imagine you can feel the power here. You can change any styling you want when you’ve got a class name you can select and use.

In fact, think about how you can change classes all the way up on the <html> element. A class there means, through the power of CSS, you can change the style for anything on the page. As a neat bonus, you don’t even have to querySelector for the <html> element. JavaScript automatically has a reference to it available.

document.documentElement.classList.add("paying-user");

That classList API allows you to add, remove, replace, and toggle classes, as well as check to see if an element contains a certain class, so you’ve got a lot of control there.

element.classList.add("javascript-enabled");
element.classList.remove("loading");
element.classList.replace("cat-lover", "dog-lover");
element.classList.toggle("open");
element.classList.toggle("raining", weather === "rain");

3) Learn to Listen for Events (e.g. Scroll, Click, and Change)

Selecting elements and changing classes is powerful, but it’s very likely you’re going to want to do that when something happens. The when in JavaScript is often an event. It’s another API that allows us to “listen” for events. Events are happening all the time! It’s our job to respond to them when they happen.

The click event is the ultimate classic. You’ll want to attach click events to elements that can receive focus. A <button>, for example, is perfect. You can attach a click “handler” to a <div>, but it’s a bad choice as a <div> isn’t focusable. Many users use their keyboard only to navigate the web and may rely on screen readers to interact with it, and would be unable to “click” a <div> with a click hander.

Imagine our header has a button in it:

<header id="site-header">
  <h1 class="logo">My Website</h1>
  <button>Switcheroo</button>
</header>

First we get a reference to that button, then add our click handling function:

const button = document.querySelector("button");

button.addEventListener("click", () => {
  /* Code in here will run when the button is clicked */
  console.log("Button was clicked!");
});

Hopefully that code above is clear. We selected the button, and we added an event listener for the event type click. Don’t worry much about the rest of the syntax for now, but just know that code within those { } “curly braces” will run when that button is clicked.

I slipped a little bonus in there for you: console.log(). This little beautiful function allows you to send messages to the browser DevTools. If I have those DevTools open (Cmd/Control – Option – J) I can see the message output there, which is a nice “sanity check” that things are working.

Inside our new { } in that “click handler function”, we could do the job we already know how to do: update a class.

I know that end result feels rather basic, but I hope it demystifies JavaScript a bit for you. In a sense, we’re just doing these three things:

1. Select
2. Listen
3. Update

4) Change HTML

Changing the class of an element is changing the HTML of that element. But we’re not limited to that! We can quite literally change anything about it. Let’s assume element is a reference to an element like we learned in #1. We could:

element.innerHTML = "<div>I'm now the entire guts of the element!!!</div>";

element.remove(); // Totally gone

element.dataset.version = "1.0.0"; // <element data-version="1.0.0">

element.style.backgroundColor = "red"; // <element style="background-color: red;">

element.insertAdjacentHTML("afterbegin", '<i>Hello</i>'); // <element><i>Hello</i> ... 

Those are just some of the many powerful things you can do to HTML once you grab ahold and get a reference to an element.

5) Grab the values out of Form Elements

We already know how to select elements, and it’s no different for form elements. Say we have a form element like:

<label>
  Size
  <input type="range" id="size" ... >
</label>

Let’s:

1. Select it
2. Watch it for changes
3. Do something when it does

// 1
const sizeSlider = document.querySelector("#size");

// 2
sizeSlider.addEventListener("input", (e) => {

  // 3
  wrapper.style.border = ` ${e.target.value}px solid black`;
});

Now that you can grab stuff from naturally interactive elements on the page, that should open some doors!

As an exercise, consider a password field like this:

<form id="form">
  <label>
    Password
    <input type="password" id="password">
  </label>
</form>

You can watch when the form is submitted, then check the password.

const form = document.querySelector("#form");
const passwordInput = document.querySelector("#password");

form.addEventListener("submit", (e) => {
  e.preventDefault();

  if (passwordInput.value === "") {
    // User submitted empty password
  } else if (passwordInput.value === "password") {
    // User submitted correct password
  } else {
    // User submitted incorrect password
  }
});

What UI/UX things might you want to do when doing this kind of interactive work? Perhaps you could “shake” the form on incorrect passwords. Maybe you could insert some HTML telling them the password was incorrect and they have X tries left. Maybe you could change colors. As a designer, you’ll likely know exactly what you want to do, and now the page is interactive enough to properly prototype it.

Bonus: Design mode

This is a little bonus one:

document.designMode = "on";

This is probably most appropriate as a snippet to put in the DevTools console as a one-off, as having it always on would be weird. When this “mode” is on, every element on the page is editable. The text content of it, anyway.

More:

• If you want parts of a page to be editable (that aren’t already form elements), you can always put contentEditable on them.
• Just poking around and changing stuff like styles and content in DevTools is essentially doing the same things (behind the scenes) as we’ve learned so far: manipulating the page with JavaScript.
• If you’re really into editing websites as they are in the browser as a design tool, check out more elaborate tools like VisBug.

Extra Credit: HTML Web Components

A Web Component (can be) an element in HTML you just… make up. The point of them is that they do something useful and you re-use them all over your site as needed. The name in them just has to have at least one dash:

<add-rainbows>
  <div>
    HTML in here that doesn't *need* rainbows, but would like them.
  </div>
</add-rainbows>

These are a native part of the web platform and can be used no matter what other technology you use to build the site, making them universally useful. If you learn this, which I feel are just as useful for purely UI reasons as they are for anything else, you can bring the idea of components to your HTML work just as you likely already do in your design work. Designers building re-usable components is a world I’d like to see.

Here’s a silly example where the only job this Web Component has is to inject a <style> tag into itself that styles itself.

Think: “A small, re-usable bit of styling and/or functionality that wraps a bit of otherwise perfectly usable HTML”. Jeremy Keith listed some examples recently:

• Jason’s aria-collapsable for toggling the display of one element when you click on another.
• David’s play-button for adding a play button to an audio or video element.
• Chris’s ajax-form for sending a form via Ajax instead of a full page refresh.
• Jim’s user-avatar for adding a tooltip to an image.
• Zach’s table-saw for making tables responsive.

Discussion

Are you in this position yourself? Was this helpful? Or are there other things in JavaScript that you’d prefer to learn? Have you gone through this yourself already? What kind of things were the very first things you learned in JavaScript that were helpful?

Criticism of form over function is a tale as old as time. People line up to criticize Frank Lloyd Wright, as Regina Cole wrote:

His roofs were improperly supported, they say. His buildings leak. They waste energy, are maintenance nightmares, have no garages, inadequate closets and as for the kitchens…

Makes you wonder what the development parallel is. I think it’s adding Kubernetes to the stack of a startup that hasn’t established product market fit yet.

By “linear design process” I mean cookie-cutter case studies that always read the same. The designer learned about a problem, conducted user interviews, created user personas, proceeded to sketches, then mockups and wireframes, made everything beautiful through visual design, created a prototype, and tested it with five users. Everything was perfect so they also created a design system which is not a design system but a style guide. But they call it a “design system” because it’s trendy and a keyword for the recruiters. 

🌶️. I take the point: it feels fake and easy to see through. A real project is never this clean. The process is more like a squiggle.

Poking around big job posting sites, I do see it around used like this a bit (nice!) but it’s a more common term in the not-terribly-related field of mechanical engineering. I wouldn’t hate it to see it as “Web Design Engineer” when used officially.

Maggie Appleton has curated a bunch of writing, and just as interesting, a group of actual people who typify the role and examples of their work.

Design engineer captures something simple, important, and worth distinguishing: a person who sits squarely at the intersection of design and engineering, and works to bridge the gap between them.

I feel compelled to say that the kind of design engineering examples on display are what I see heaps of on CodePen every day.

You’re given a design with a note: the dividing line between these two containers should be interactive so the user can drag to resize the respective containers on either side.

Maybe you’re picking up on this around here, but I’m pretty big on asking all the right questions as an important part of your journey to “senior” in any role. With this small design note (or mockup), there are definitely going to be questions.

• Does the interaction have a resize affordance?
• How does it happen (e.g. on mouse in or mouse down)?
• When does it happen (e.g. immediately or on a delay)?
• Where does it happen? Directly on the line itself, or in a target area? How big is the target?
• Is there some kind of snapping involved?

Maybe you answer them yourself, but you’re thinking about them. In this case, in order to ask and answer these questions, you need someone who is saavy in design/UX and coding.

Perhaps one of the most cliché introductory things to build on the web (or otherwise), is a to-do app. But we’re going to do it again, as a website, and for good reason: it’s the perfect scope. A to-do app is fairly simple, adding and removing short bits of text forming a list. But it’s not too simple. It requires us to think about all sorts of things. While we’re ultimately going to care about coxre web development technologies like HTML & CSS, we’re going to choose to layer in JavaScript to help with user experience and data handling, and then see what other technology we might find helpful along the way, if any.

We’ll call our project TODO. Don’t sue me. It’s just for learning.

And we’re going to do this thing as a series, so this list of posts will be updated as they are completed.

Prior Art

Marc has already broached this subject on this very blog. Go check out the GitHub repo, where there is a lot of code to explore. Marc went deeper on the JavaScript aspect than we likely will. He tells me:

I added branches for TypeScript support, used lit-html for performant rendering, and an app-architecture branch for how to architect larger apps

There is also an extremely cool project called TodoMVC that was hot’n’heavy around 2012-2016. The purpose of it was comparing different approaches of a to-do app created using different JavaScript frameworks and vanilla approaches.

TodoMVC is useful for comparing syntax and solutions, is officially used in cross-browser benchmarks.

It was/is useful in helping people decide things like “Do I like the Angular approach or the React approach?”, for example. People could decide by looking at the actual code as well as seeing/feeling the output. We might fiddle with those ideas a little, but we’ll be focusing more on the thinking and experience of building and leaning toward vanilla code.

There are no wrong answers

We’re going to take an intentionally wordy trip through this project. We’re going to think about lots of different aspects of product development and web design and development. We’re going to do it in a certain order and land on certain choices.

If you were going to build a to-do app of your own, you might think about things differently. You might make different choices. You might do these things in a different order than I’m doing them. I think there is a rhyme and reason to the path I’ll write about, but that doesn’t make yours wrong. In fact, I think finding your own way is a great way to learn, and probably what you’d do anyway regardless of anything you read.

So unless what you build is broken or inaccessible, there is no wrong way.

Design: Thinking First

I like putting design first, design-driven development as it were, and here’s why. Design forces you to think about your app more holistically than you might otherwise.

When I started thinking about this idea, admittedly, I started poking around at JavaScript right away, putting some basic HTML together the JavaScript could work with. I was having fun reminding myself how powerful native web tech has become and how much we can do without reaching for anything else at all. But then things started to feel sloppy as I realized I was just randomly poking at things rather than have any actual plan. Sure, I could add new to-do items to a list, then remove them. But oh yeah I need to display the list from saved data. And then what else? Can you re-order them? Can you edit them? Can you delete multiple at once? That’s just scratching the surface. Design allows you to take a beat, stop thinking about implementations, and think of a plan first.

A Look Around

There is no shortage of to-do apps. It’s not like we wouldn’t be able to piece it together with our own thoughts of what should be in an app like this, but don’t let that confidence fool you! It’s always worth a look around to see how other apps are doing things, particularly successful ones because those in particular help establish the genre and set user expectations.

Here’s a quick walk through some to-do apps I happen to know about. Seriously, quick. These are very surface-level observations, nothing deep.

Things

Things is the to-do app that I’m most familiar with. It’s a native app, as opposed to the web like we’re doing, but that doesn’t stop us from looking at the UI and UX.

Notice they don’t go very heavy at all on UI for adding new items. A tiny + on the desktop app and a blue (+) on the mobile apps. The emphasis is more on knowing that Command-N will do the trick. I do enjoy the little feature that you can drag the mobile (+) where you want it before adding a new item. Notably, you add a new item before you add any text or information to the item. Metadata is pretty limited, preferring that you group things in various ways (areas, projects, headings), although there is things like tags if you want them. If any metadata is emphasized, it is due dates.

Todoist

Todoist actually is web-based, so that’s nice to see (hey, you get multi-platform for free!).

More metadata is exposed here. Tasks have a description which you automatically some of is interesting. Plus tags, plus due dates, plus collapsible groups.

Notice that adding a new task is also relatively chill. Unlike Things, pressing the + Add task button doesn’t automatically create a new task, but instead expands into a fleshed out task adder:

The task name is the only required thing, which makes sense. It would be obnoxious if anything else was. It feels like a reasonable choice to allow you to add all this metadata immediately, but certainly not the only path. They could do it such that you add the task first, then optionally add more to it if desired as an optional next step if you wanted.

TeuxDeux

TeuxDeux is big on having you put to-do items on individual days, although you can customize it if you want to. Having this kind of initially opinionated structure will have a huge influence on how people think about your app.

Notice there is almost no UI for adding new items. The way it works is that the next item in each column is automatically a live input, waiting for you get into it and add text. The extremely narrow item widths will also encourage you to get to the point darn quickly. You can see the markdown come through with the editing toolbar (Things also does Markdown, but only in the body of the description, which is hidden until opening an individual item.)

TodoMVC

This is the standard design as part of that TodoMVC project I mentioned (example). This is fun, as it’s quite intentionally minimal.

Note there is no submit/add button for new items, which weirds me out a little bit on the web. I’d say this then entirely relies on the submit even from the <form>, but in this case there is no <form> (?!), which then not only requires JavaScript but more JavaScript as they can’t just use that native event. It’s likely our app will require JavaScript as well, at least at first, as adding a backend language might be a trip too far for this series (but we’ll see, if y’all love it, lemme know).

Here we’re seeing implied categories based on completion (and a way to delete the cleared items as well). Plus a count. Plus the ability to double-click to edit. That editablity feels like a significant thing to think about. Does that double-click feel right or should you just be able to click in there? Native operating systems have a click-and-linger approach to name editing sometimes. You could certainly offer an “Edit” button (Pencil icon?) as well, but anything you add to every item is going is a risk of visual clutter. Reveal it on focus? Maybe there will be enough items to warrant a sub-menu? We’ll have to see.

Initial Features

There is no way we’re going to be as robust as some of these apps who have been working on their feature set for years and years. Let’s call it like this:

1. Let’s emphasize the simple text input. Let’s see how easy we can make it to add a new item to one big single list.
2. Let’s also emphasize the Add/+ button. Not only does it lean into HTML and accessibility correctness, but we can also make it part of our branding. Maybe we can borrow the Things approach of draggability someday.
3. Just one big list for now, but let’s think extensibility when we store our data. It shouldn’t be a stretch to add multiple lists, tags, descriptions, or anything else.
4. Add and Complete are the primary actions. For now, let’s borrow TodoMVC’s approach of double-click to edit unless we find something we like better while building.
5. Let’s try and make drag-to-reorder happen.

Very basic.

Of course, we’d love to add user accounts, Markdown support, due dates, tagging, an API, bulk actions, recurring items, and who knows?? AI helpers? Integrations? If you absolutely knew that these features needed to be there for day one, then they should be part of the design process from day one. For us, not so much, so we’ll keep things simple and trim and build that first.

It’s fun to think about though! Heck, a to-do app, as simple as it seems at first, might be just as complicated or more than an app in just about any other genre.

Design

Knowing what a trim feature set we have, I’ll Figma something up real quick. Half an hour later, here we are.

This artifact is a little useful. We can reference colors. We can be relatively sure we’ve represented what we wanted there for day one. But mostly, this forced us to actually think about all that before our greedy little fingers started coding.

We’ll code better if we more clearly know where we’re going.

Working design-first also frees up your mind, I find, to think more creatively. Personally, I’m happy to drag things around weird places. Pick weird colors. Make things humungous or tiny. Explore totally different icons. All sorts of stuff like that that I just know I’m much less apt to do once I’m actually coding. For lack of a better metaphore, a left brain / right brain thing. As you get to know how you work best and most creatively, you’ll have your own tricks.

See ya next time!