A Kickstarted Reissue of Principia Mathematica

A small Spanish publisher, Kroeneck Wallis, has a Kickstarter for a new version of Isaac Newton’s Principia Maethematica. As you can see from their Instagram account, the finished product is going to be beautiful. The publishers are making some interesting design choices, including producing a separate book for each of three chapters of the original, using a visible binding that leaves the spine bare, the use of just two colors (petrol blue and coral orange) and a low contrast serif font.


As of this writing, the Kickstarter is already a third complete, with over three weeks left. There are a number of support options, starting with a single copy at just €45.

(Via Jason Kottke)

The Reading Revolution

The Web is in the middle of a reading and design revolution. And I’m not talking about the demise of the erstwhile <blink> tag. We’re seeing the rediscovery of the web as powerful document and knowledge transfer platform just as the Renaissance saw the rediscovery of Classical knowledge and wisdom. Independent of the rise of the online video and music people are also reading on the web, now more than ever. And there is no shortage of words, paragraphs, ideas and stories to read. Flexible web typography, the popularity of clean, elegant designs and the increasingly sophisticated rendering engines in modern browsers are helping to sustain and fuel our reading needs.

At the heart of this resurgence of reading are technologies that fundamentally change the experience of reading on the web. First on the list is Instapaper. The brainchild of Marco Arment (formerly of Tumblr) Instapaper is a web service and iOS application that is designed to one thing: make it possible and easy to save text content from the web and then present that text in a beautifully designed package. Instapaper strips out all forms of advertisement, images and anything else that distracts from the experience of just reading. To use Instapaper you sign up for an account and install the “Read Later” bookmarklet. When you find an article you want to save you just click on the “Read Later” button in your bookmarks bar and the entire text gets parsed and saved for later. There is no form to fill out and no need to set any options. You can get along really well with just the defaults.


Instapaper on the iPad
Instapaper on the iPad


Where Instapaper really shines is if you pair it with the iPhone or iPad app. These apps sync automatically to your account and download the full text of your saved articles. The articles are then presented in a no-distractions format on a clean background with beautiful fonts. Reading Instapaper articles on an iPad is one of the best reading experiences I’ve ever had, second only to the Kindle. Words and screenshots do not do the experience justice, you have to see it for yourself. If you read a lot of long-form web content it might be worth getting an iPad just for Instapaper.

But what if you want a better experience right now while you’re reading in your browser? Filling that niche is Readability — a bookmarklet backed by a web service that strips away all the fluff from a webpage and presents just the text (with any important inline images) for your reading pleasure. Like Instapaper the reading experience is carefully tuned with a good selection of beautiful fonts set on clean, neutral backgrounds. You can also get along just fine with the defaults but have some options for customizing your experience if you want (mainly font size/type and background color).

Personally, I think Readability is a more important innovation than Instapaper. While Instapaper works best with a reading device like an iPad, Readability works on mostly anything that’s text-heavy on the web. Not only does it get bad design and unwanted ads out of the way, it’s also great for sites that are have font that is just a little too small, or columns that are just a little too narrow for comfortable reading on a wide screen. Personally I find myself reaching for Readability on anything that I find even slightly difficult to read. After all, it’s right there in my browser and takes barely a few seconds to beautify a page.

Readability on the web
Readability on the web

Alongside the aesthetic fixes, Readability also has a business model for sustaining ad-free reading on the web. 70% of the monthly $5 (or more if you like) fee gets sent to the content providers. For the individual reader, $5 a month is a tiny price to pay for a great reading experience. Multiply that by hundreds of thousands (millions?) and you get a business model that doesn’t depend exclusively on selling consumer information.

Both Instapaper and Readability (and similar apps like Reeder and Tweetmag) build on a set of basic principles to offer great, compelling products. They acknowledge that people like, and will pay for, thoughtfully designed and beautiful tools. Instead of trying to offer services for “free” and turning their users into products they tighten the loop between producers and consumers both in terms of product and financing. In the process they do what I would consider a public good: making the acquisition and production of knowledge a pleasurable, worthwhile experience.

We’re living in the years of the resurgence of the web as a communication and knowledge platform, rather than just an ad delivery vehicle. While video, music, animations and visualizations are making the web a more dynamic and vibrant environment, tools like Instapaper and Readability are ensuring the existence and growth of a web “designed for reading, not a web where reading happens despite the design“. And I for one like it that way.

Simplicity and clarity as design tools

For the past week or so I’ve been customizing my WordPress install by adding a number of plugins. I plan on writing an article soon about what plugins I’m using, but first I’d like to talk about something that I’ve noticed about WordPress plugins. Installing plugins is easy. There’s plugin directory in every WordPress installation, generally under wp-content and you just drop a plugin folder in this directory and WordPress will detect it. If you’re using a recent version of WordPress, you can actually search the plugin repository and install a plugin from inside WordPress itself. This is really useful feature and makes using plugins much easier. However, the one gripe I have is that the settings to control the plugin get spread all over the WordPress interface.

Here’s a screenshot of my WordPress Dashboard. Along the left side you can see buttons for various drop down menus:

My WordPress Dashboard
My WordPress Dashboard

I’m currently using 8 plugins, each of which have various settings and interfaces to change those settings. One of those plugins (StatPress) has it’s very own sidebar menu. Two of them are under the Plugin menu, one is under the Tools menu and the rest are under the Settings menu. That means that if I have to find the settings for a particular plugin, I potentially have to look in 3 different places to find them. For me this is a clear design and organization mistake. Things that do the same thing should be in the same place. I’ve picked WordPress as the example because it’s what’s been striking me most recently, but it’s not the only one. Office 2008 for the Mac allows users to change the default saving format to the old formats. This option is in the same place for Word and Powerpoint, but is different from Excel.

Simplicity favors regularity. User interfaces need to be both simple and regular. Google’s interface is probably the simplest you can get. WordPress’ interface in general is pretty regular and simple, but the organization of the plugins is not regular at all and so there’s an extra level of complexity added in which users really shouldn’t have to deal with. It’s not just user interfaces. Indenting your code properly is also recommended for the same reason. All code that gets executed as part of the same operation should have the same indent level. It’s a visual clue that’s much easier to follow if done right than keeping track of curly braces. One of the criticisms of Perl is how it uses contexts: variables and operations can mean different things depending on what’s surrounding them. That isn’t always a bad thing, but it does mean that you have to consciously keep track of the context your code is in.

Similarly the development of the RISC processor architecture was motivated in part by the fact that most processor instruction sets are highly irregular with lots of instructions that seem very similar but actually operate quite differently (or have some seemingly arbitrary limitations). The book Computer Organization and Design which was co-authored by one of the creators of the RISC architecture, states 4 design principles, one of which is that Simplicity Favors Regularity. I must say I have to agree

While designers should try to contain functionality within regular components, it’s also possible to go overboard. Typical electrical installations in buildings are controlled by rows of identical switches. Very regular, but also perfectly impossible to tell which switch does what. Things that do different things should look different. Clarity is key. In the Design of Everyday Things, the author talks about how employees in power plants distinguish switches on their consoles by attaching different handles to them. One of the reasons that Lisp looks scary to a lot of programmers is that it can easily look all the same, as opposed to C-like languages where a for-loop looks very different from a function call or object creation. To be more specific, the external design of an object (or interface) should suggest it’s possible function. Admittedly this is harder for on-screen software than it is for physical object.

But these two principles seem contradictory. How do we reconcile regularity with easy differentiation. Part of the answer is that there is an underlying concept which is pretty powerful: ambiguity is bad. On Reddit today I saw an article criticizing Xfce’s settings interface. The author couldn’t figure out how to increase his text size. There is some comparison with the Windows 3.1 interface, but the central reason is that the Xfce settings interface is ambiguous: should text size be under Window Manager Settings, Display or User Interface Settings, all of which seem equally probable to the casual user. It’s the exact same case for my WordPress plugins. I think plugin settings should be under Plugins, but it does make sense to put them under Settings or Tools.

Xfce settings manager

So the question then is: how does one avoid ambiguity and achieve clarity, especially when there really are a number of logical alternatives (like WordPress)? In some cases it’s possible to use clear labels to distinguish what operation will be performed. Taking another example out of design of everyday things: a flat bar across a door makes it clear that the door is to be pushed, not pulled. When it comes to designing software interfaces like WordPress or XFCE, it’s not quite so simple because there can be a lot of debate over which design is correct. After all, plugin settings can go under Plugins or Settings. I feel that the key here is to just make a choice and then make that decision known. In the case of WordPress, plugin settings could go in either Plugins or Settings, though I would personally prefer Plugins so that there is one place for all plugin-related activities. But equally importantly, plugins should not be given a choice as to where in the UI to go. The case for XFCE is made more complicated by the fact that the text size for the window title bars can be changed independently of the rest of the UI and hence text size control is spread over two places. I would still argue that the two should be pulled into a single interface, but this is a case where the interface is heavily influenced by the functionality. The thing to remember in this case is that even if something might seem clear and logical for the developer or engineer, it might not seem that way for a casual user. Users don’t want to spend any time actively learning where things are, they just want to use it and they want it to work. Beta testing products with users is a great tool and it’s also essential that design decisions be well documented in easy to read manuals.

In conclusion: ambiguity is the enemy. Fighting ambiguity requires a two-pronged approached. Interfaces must be simple and regular so that the user is not overwhelmed with choices. But at the same time, there must be sufficient cues to let the user know that different objects have different functions and how required functionality can be accessed. This can be done by using labels (different text and images) and by offering easily accessible documentation. However, good design requires many decisions and compromises and the best way to figure out which ones are best is by watching actual users and adjusting accordingly.