Typeshift a web app for designing with variable fonts in the browser to make better typographic decisions on the web.

MDN
Typeshift’s design view

Concepting

A large number of design tools already exist, but very few of them actually account for the inherent responsiveness of the web – insteading outputting static comps. Type is ingrained in web design, taking front seat in a communication and usability role, and yet designers don’t have great access to quality typefaces and the controls required to take advantage of them – namely variable fonts, OpenType, and usable methods for tweaking typographic properties (size, width, line-height, etc).

Typeshift’s UI for multiple axis variable fonts

User Research

Typeshift was concieved to fill that gap and help people take advantage of newer font technology. I took some time planning, sketching out the overall structure then breaking UI down into components based off some initial guestimates at useful functionality. Simultaneously, I surveyed and asked people about the major gripes with typography they encountered in their web design workflows (both Type Designers and Web Designers). This helped me narrow down and prioritize the potential set of features. It took several tries to reach some effective questions, and the research process never stopped as the app developed.

Design and Experimentation

After some early sketches to try different layouts (it didn’t make sense to reinvent the wheel), I mocked up what the primary view of the app might look like. Typeshift’s design view is comprised of three main sections – the center area for entering text, the layer management sidebar on the left and style sidebar on the right.

MDN
An early mockup of Typeshift

It wasn’t beautiful, but the primary goal here was to define elements in context to the view and start to thinking about space and usability as soon as possible. As a design tool, 95% of all interactions would take place in this responsive view. Components switched places or were dropped all together as I learned more about what was useful to users.

My educated guess at a typical user workflow was comprised of three steps: opening Typeshift to try fonts, style them and see how they worked responsively, and then export code to use in production front-end. Parts of this hypthesis were clarified:

“(I could see Typeshift)…for when I'm stuck in a big complex development framework and just want to see what a few type-related CSS rules might look like with as little extra code as possible.”

“…not being able to move my elements around the page is a major constraint. I’d love to be able to swap the position of my text and header blocks, besides duplicating them. This makes testing and experimenting with a whole layout a very slow and tedious process, since I have to be deleting blocks all the time.”

Most of the design process was getting feedback around specific pieces of functionality and usability in a similar matter, then prioritizing what to design/build and when. Sometimes it was making improvements, revising existing components or backtracking on something that wasn’t working correctly.

Everything except the front-end

Typeshift was developed from an early front-end prototype. I started building out Typeshift while getting feedback on the initial design and concept. Building the application backend / model required learning and implementing MVC architecture, authentication and a database. Without any previous backend experience this was a slow process that involved a lot of time and research. Handling various database queries, routing and coming up with a good model for storing and updating style properties were the most challenging things to pick up. Online resources and a developer friend were really helpful here.

I chose React (a universal app with serverside rendering) to manage the frequent updates to the view layer as users changed the controls. I avoided Redux and instead rolled my own model and controller because the data was fairly simple and centralized JSON with a one way data flow.

// Parameters: The name of what's being modified, 
// the index of element being modified 
// and the event to get the value from the input
handleChange: function(refName, nodeIndex, event) {
    …
    // Tell the model to update settings that don’t have units associated with them
    else if ((refName === "fontSizeUnit") || (refName === "lineHeightUnit") || 
      (refName === "letterSpacingUnit") || (refName === "colWidthUnit")) {
      if (event.target.nextElementSibling == null) {
        modelUpdateElement(nodeIndex, refName, event.target.parentNode.childNodes[0].value, event.target.value);
      }
      else {
        modelUpdateElement(nodeIndex, refName, parseInt(event.target.value), parseInt(event.target.nextElementSibling.value));
      }
    }
    …
}

The above snippet accepts the element being modified, the style property being modified and then makes an update.

Interaton, Iteraton, Iteration

As features built up and changed, there was a constant assessment of when to make larger and smaller changes as Typekit moved from private Alpha into open Beta. A single running list split into different groups helped me prioritize different features including drag and drop, shortcuts, direct type manipulation, a packaged native app, duplication, Webpack, Typekit integration, friend invites, savable projects, mobile syncing, a live code panel, variable font support, etc.

Typeshift was built to think about type flexibly from the ground up, from adjusting the letterforms that make up variable fonts, responsive units used to the set type, and the user controls to quickly try a number of variations.

Typeshift’s variable font UI, color picker, and direct line height / width manipulation

As always, there are always things to add, reduce, and improve. Overall it’s been an amazing learning experience designing and building something from the ground up, putting it out into the world and watching it evolve.

Design with fonts on the web? Try Typeshift now!