This article is the second in a series on The Making of A Simple Frame in which I offer a behind-the-scenes look at the creation of this website. In the first article, I discussed three big ideas that shaped the creation of A Simple Frame. In this article, I will explore the design process and some of the specific tools used to create the site.
Design Process (No Photoshop)
This is the first website I’ve designed without using Photoshop or Illustrator to make a mockup first. The design process started with rough ideas recorded in my sketchbook. I wrote notes and drew sketches as I thought of them over a period of months prior to starting work on the site. When the time came to sit down and begin the actual work, I had a nice collection of ideas to reference as a starting point.
My early notes and sketches all centered around making as simple a site as possible. Typography was also paramount in my mind. I knew I wanted the design to be almost solely composed of type. Type would provide the foundation and the main structure. As such, I began exploring typography right away.
To explore the typography of the site, I opted to work in the browser instead of Photoshop. There were several reasons for this. For one, Photoshop is a poor environment to set type. It’s just not suited to the task at hand. It’s time-consuming, difficult to edit styles, and offers less control than a program like InDesign that is built for setting type.
Additionally, I chose not to work in Photoshop because it is an abstraction. What you see in a Photoshop comp does not accurately reflect the final product – what you see in a browser. The letterforms don’t even look the same as they do in a browser.1 At the end of the day, it doesn’t matter how good your type looks in Photoshop. No one sees it. What matters is what people actually see is the browser – the live, coded typography.
Tools for Setting Type in the Browser
I explored typography within the browser in two different ways. The first way was using Typecast. Typecast is an online tool that lets you set type using an InDesign-like interface within a browser window. You can also edit the code directly if you wish. The typesetting tools are easy-to-use and extremely well executed, but what really makes the service special is its library of web fonts. Typecast partners with major webfont providers like Typekit and Fonts.com so that you can experiment with literally thousands of webfonts, all within the browser. It allows you to truly try out a webfont before purchasing a license. I experimented with a number of different fonts using Typecast as a first step in my design process.
The second way I explored typography within the browser was writing html and css in conjunction with webfont trials from Webtype. Webtype is a webfont provider from Font Bureau that provides high-quality webfonts. What’s great is that they offer 30-day trials of any fonts in their library. This allowed me to do more in-depth experiments on my own server writing simple html and css pages. Instead of creating multiple Photoshop comps, I created multiple live webpages as my design explorations. This was a great way to work, as it ensured that what I was building and seeing was going to be the actual, final product.
Arriving at the Final Design
Although I never created a mockup in Photoshop, I did reference a print document that I had typeset for a previous project as inspiration. After completing some initial freeform explorations, I typeset a sample article page and worked through multiple iterations until I had a solid base from which to build out the rest of the design. From there, I added other page elements and templates, switching back and forth between paper sketches and in-browser page designs.
In the end, eschewing Photoshop in favor of the browser proved to be a good experiment for my design process. There are two key takeaways I hope to implement more in the future. One, starting with typography is essential. After all, type is the main element of most webpages. Two, working in the browser as early and often as possible is very advantageous. Whether it be with a tool like Typecast or simply coding rough pages, working in the browser allows you to remove abstraction and work with the true medium of the web during the design process.
Choosing a CMS: How I Fell in Love with Kirby
When I first began thinking about designing a new site, I started keeping my eyes out for possible cms options. My first thought was to use WordPress and start with a very minimal theme like Starkers as a base. I wanted to start with as little as possible and build it up to only what I needed. WordPress is powerful and flexible, but it’s definitely not minimal. The more I thought about it, WordPress began to seem like overkill. Ideally, I wanted a platform that was minimal, speedy, friendly (to a non-developer type), and enjoyable to use. The question was whether or not such a platform existed.
Next, I ran across static site generator Jekyll. Here’s the official description:
Jekyll is a simple, blog-aware, static site generator. It takes a template directory containing raw text files in various formats, runs it through Markdown (or Textile) and Liquid converters, and spits out a complete, ready-to-publish static website suitable for serving with your favorite web server.
In other words, Jekyll can transform a folder on your computer that is specially formatted into all the files needed to serve a static website. Whereas WordPress and other dynamic sites process everything on the server using a database and php, Jekyll processing everything on your computer beforehand and requires no database. The result is a static site that is efficient and speedy.
I really liked the idea of Jekyll, especially its simplicity and efficiency. However, it looked to be geared more toward developers than designers. Jekyll-Bootstrap describes why someone might like to use it:
… if you like to keep things simple and you prefer the command-line over an admin panel UI then give Jekyll a try.
I like keeping things simple, but I definitely don’t prefer using the command-line. The more I dug into Jekyll, the more hesitant I became about trying it. Even so, I was still thinking I would use Jekyll – that is, until I met Kirby.
What is Kirby? The official tagline sums it up best:
Kirby is a file-based cms: Easy to setup, easy to use, flexible as hell.
Essentially, Kirby works by taking files on your server set up in a specific way, and processes them using php to build your site, without the need for a database. I think of it as a happy middle ground between WordPress and Jekyll.
What does it mean to be “file-based”? Practically speaking, this means that each page is represented by a folder, and each folder contains all the content for the page. For example, an article page folder on this site contains a text file with the article title, text and metadata as well as any images included in the article.
As the tagline states, one of Kirby’s virtues is its flexibility. It’s very easy to set up different page templates that make use of custom fields. Custom fields for different types of text-based content are created simply by defining them in a page text file by writing the name of a field followed by a colon. Fields are separated by lines of four dashes. You can then use the Kirby api to easily include the data from these fields in your templates. It’s a powerful and flexible system. Most importantly, however, it’s very intuitive and easy to use.
Here are several more things I like about Kirby:
- You can write your content using Markdown.
- It is free to try.
- It costs only $39 for a single site license.
- It’s developed by a single, design-minded developer – Bastian Allgeier. This makes the product very focused and elegant.
- The documentation is good, and it’s simple enough to wrap your mind around pretty quickly.
I’ve become a big fan of Kirby after using it for this site. I could write much more about it, but that’s beyond the scope of this article. For now, do yourself a favor and check it out if you haven’t already.
During the creation of A Simple Frame, I tried out a number of different apps to work with before arriving at my current lineup. The three main types of tools I use are a code editor, an ftp client, and a text editor.
As I began doing my in-browser design explorations, I tried out several code editors. The first was Sublime Text. It’s a powerful editor and seems to be the tool of choice for most serious coders today. It has a lot of features and is very customizable. The features I found to be most helpful were its code completion and multiple selection features. Its the fastest and most intuitive tool I’ve used for the work of writing html, css and php.
That said, I decided it wasn’t the best tool for me. For the kind of editing I was doing, I was only scratching the surface of Sublime Text’s full feature set. This isn’t necessarily a bad thing, but it proved to be more complex of an editor than I need. The price point also reflects this, being priced at $70. Finally, though it is very customizable, customization was necessary to make it look the best. At the end of the day, I didn’t want to spend my time tweaking, theming and customizing a tool I wasn’t going to use everyday. In the future, I will most likely revisit Sublime Text, especially if I find myself doing more coding.
The second editors I tried was Coda 2. The concept of Coda is to consolidate the coding process into one window. Instead of having a bunch of different windows and applications to do different tasks, Coda handles everything. It’s an ftp client, editor and reference library all in one. Like Sublime Text, Coda is rich with features – a lot of which I wasn’t going to use. Also, the file-based nature of Kirby made it more intuitive in my mind to use different applications to do different tasks. In other words, Coda’s all-in-one philosophy didn’t fit the workflow I had in my mind for Kirby. I love the design and attention to detail in Coda. In the end however, I also decided it wasn’t the right tool for me.
Perhaps surprisingly, my current code editor of choice is the unassuming Textastic, a “simple and fast text editor for the Mac.” I discovered it after downloading Textastic for iPhone so I could make edits to the site on the go. Its best feature is its simplicity. Unlike the other editors I just described, it lacks advanced features. It has syntax highlighting and code completion but not much else. Because of this, the UI and options menu are reduced down to only what is necessary. I find this minimal approach enjoyable and refreshing. It’s a tool that does what I need it to do quickly, nothing more, and gets out of the way so I can focus on my work.
My only complaints with Textastic are that the code completion is not as slick as Sublime Text and several keyboard shortcuts standard in other editors are either missing or different. If I was writing code every day, I don’t think this would be my editor of choice. For occasional editing, however, it can’t be beat for its speed, simplicity, and value (it costs $6). For my current needs, it’s my go-to editor.
As Kirby is a file-based cms, I wanted to find an ftp application that would fit in naturally with a file-based workflow. I first tried out Transmit, after discovering the Transmit Disk feature, which allows you to mount ftp directories as remote disks directly in Finder. In trying this feature, however, I found it to be a bit sluggish. Like the first code editors I tried, Transmit also packs a lot of features that I wouldn’t be using.
I really liked the idea of Transmit Disk, however, and began looking to see if other ftp clients offered a similar feature. This brought to mind Interarchy, an ftp application I had acquired in a previously-purchased software bundle and forgotten about. After finding my license code, I gave it a shot and was pleasantly surprised. The interface is very simple, and closely resembles a Finder window – perfect for the file-based Kirby workflow. Additionally, it has a Net Disks feature which allows you to mount ftp directories as remote disks directly in Finder in a similar way to Transmit.
As I just mentioned, Interarchy’s standard interface mimics that of Finder, making it ideal for editing file-based content. Even more than Net Disks, I found myself using the main interface. What makes it work especially well is the ability to tweak the settings so that double-clicking on a file will open it in an application of your choice according to file type, just like Finder. Interarchy acts as my “Finder” window and from it, I double-click files to open in their respective editing applications. This perfectly suited the I way I wanted to work with Kirby, making it my ftp client of choice.
If there’s a theme to my choices of software, it’s that I tend to value simplicity and a lack of unnecessary features. These qualities allow you to focus on the task at hand and not get distracted by the tool you’re using to accomplish the task. Also, these qualities promote positive feelings and enjoyment of use, as they are not cluttered by unnecessary interface elements. Perhaps the embodiment of these values is my text editor of choice. I’ve been a fan of it since it first launched, and I knew before I started it would be my main tool for writing. It’s called iA Writer.
The concept behind iA Writer is to take away all the features that you don’t need and leave only the essentials. In this case, the essential features are the ones the help you do one thing well and with more enjoyment: write. This means there are no controls to adjust the font or insert an image. All you can do is write, and it’s one of the most elegant and ejoyable applications I’ve ever used. It’s also a great fit with Kirby, as it utilizes Markdown for formatting. If you want to use a tool that encourages you to write, I couldn’t imagine a better one.
The creative process we follow and tools we use directly affect the shape and outcome of our work. It takes time and exploration, but finding the right ones can be richly rewarding – providing enjoyment while helping us create better work. I hope these thoughts aid in your own search for processes and tools to improve your work. If you have any favorites to share, please send them to me via Twitter.
In the next article in this series, I’ll write in depth about the visual design of A Simple Frame.
Letterforms don’t look the same in Photoshop as they do in a browser because each uses a different anti-aliasing rendering engine for the type. This is the same reason type looks different between different operating systems and browsers. On a Mac, letterforms will look heavier in the browser than they do in Photoshop. It should be noted that the newest version of Photoshop includes a “system anti-aliasing” option that will more closely match how type appears in a browser. ↩