Interface Lessons from "A Dark Room"
Are you familiar with A Dark Room? My colleague Mike Wehner first introduced me to the app. He insisted I'd love it and he was right. It presents ridiculous screens, bad font choices, and is visually an enormous mess. And yet, despite this it works, with perhaps more appeal than if it had presented a gorgeous UI.
A Dark Room succeeds in practical design because nearly all the game play takes place in your head and not on the iOS screen. The developers have succeeded with a rough minimalism in a way that many applications with luscious graphics do not. Interactions are precise, guided, and simple. This minimalism creates a system that draws users through a focused and enjoyable experience.
From Web to iOS
A Dark Room started life as an open source web app created by Michael Townsend. Approached by iOS developer Amir Rajan, they ported the game to iOS retaining the overall look and feel of the original design but expanding the storyline and game play with thoughtful edits. Figure 1 shows the opening screen running respectively on tablet and 4-inch screens.
Figure 1 The "A Dark Room" interface running on a tablet (left) and a 4" iPod (right)
It's not hard to throw criticism at this interface. The app does not support Dynamic Type. The fonts are tiny, especially for older users, without an obvious way to increase them. (VoiceOver support is, however, built-in for those with more severe visual limitations.) The interactive elements are not always immediately identifiable. You play at this point by tapping the blue "light fire" line instead of tapping the more traditionally coded "reset game" button. Even as users begin to explore a wider world as the game progresses, direct touch is not a primary mode. The UI focus remains on tapping buttons to the very end.
That all said, A Dark Room is a huge iOS app success story, earning over one-quarter of a million dollars to date. So... why? What did the developers get right, and what does this tell us about an interface without direct manipulation or graphics on one of the most touch-based, graphics-based interfaces ever?
Designing for the Mind
The key to A Dark Room is, of course, imagination. Instead of creating visual tangible graphics for you to explore, it tells a story. This story is delivered in small increments, tangential from the primary game. The app is a control panel that opens you to each stage of the story but it isn't the story itself.
The game play itself is very much centered on level grinding. You gather items; you explore; you incrementally build your skills, supplies, and infrastructure. Because these elements are presented to you in text, the experience is transferred to your mind. That story moves forward as you progress toward each basic goal, whether building shelter, gathering wood, or exploring nearby locations.
In doing so, the actual iOS screens are free to collapse to minimalism. Their text-based design provides just those informative and interactive elements you need to advance. There's not a pixel wasted or an extraneous word to be found. This sparse minimalism is a design point found from the first screen to the last.
Designing for Pacing
A Dark Room's interactive style is succinct but it changes over time. Although there are never many items on screen, the number of on-screen elements grows slowly, so the user trains with them. Figure 2 shows early-game and mid-game battle scenes. In the first, the character has no weapons and can only punch. In the second, additional weapons have appeared as separate tap points. The user's greater experience enables the game to present more features.
Figure 2 During battle, you fight or heal. 1980-style letters fill in for the hero (@), the scavenger (S), and the lizard (L)
Despite this expansion, note how clean these screens remain. Descriptions lead, followed by status items, followed by tap-to-action buttons. Screens grow more complex but never overwhelm. This slow build trains users in core elements before growing their options. Even at the most complicated point toward the end of the game, with the most options displayed, game screens remain minimal.
Figure 3 shows a late-game pack-loading screen, where users prepare their supplies before heading out from base camp. The story transcript appears at the bottom. Each + and – button adds or removes items from the wagon. An embark option enables users to head out. A back button and two special-purpose buttons at the top-right provide internal game navigation and status checks. Even at this late game stage, the interface is seductively simple considering the amount of information shown on-screen at once.
Figure 3 Screen shot near the end of the game (blacked out items are game spoilers)
Designing for Engagement
A "secrets" button appears at the end of the game, offering recorded insights from the developers. Among these is one that describes how important it is to engage the user, especially at the beginning of the game (as in Figure 1) when there appears to be almost nothing the user can do to progress. Michael Townsend talks about A Dark Room being a game where idleness and time passing becomes a tangible part of the game, and how he designed around potentially distracted users to capture their attention before the first big reveal.
"That time [before the first surprise]," Townsend shares, "is important for an idle game, though, so I couldn't just cut to the chase. That very first expansion is what teaches the player that things will get bigger and that curiosity about where things will go next is a major aspect of the genre."
Another engagement point of A Dark Room is its replayability. After you finish the game once, the game suggests an alternate storyline to try. In addition, there are some subtleties and character options that offer themselves as you approach the game experimentally. Discovering these expands the experience and creates a richness that you don't initially expect. (Try playing weapon-free, for example.)
It's clear how much work and testing went into making A Dark Room engaging both when you play the game and when you listen to the design insights offered in the recordings.
Designing for Accessibility
In January 2014, developer Amir Rajan decided to expand the game to include iOS accessibility. In a post on his blog, he writes about his surprise when he realized one of his users was using iOS's built-in screen reader to play the game without sight. "I never expected a blind person would try playing the game," he wrote. "I was extremely surprised at how far he had gotten (he was pretty much to the end). After helping him out, I read up on iOS’s accessibility features. With very, very, little work, I released an update to the game with accessibility enhancements."
In his write-up, Rajan offers a fantastic overview of undocumented edge cases to take into consideration when adding accessibility to your apps. He points out the difference, for example, between changing a view's alpha level and setting its hidden property – the latter will hide a control from Voice Over but the former will not. He also mentions AppleVis as a great resource for finding visually impaired beta testers.
iOS was designed for rich, lush, touch-based interfaces. It's a delight to find a game that breaks the rules so successfully. Minimalism, A Dark Room shows, is not just a side effect of lazy programming but a valid destination in and of its own. When approached thoughtfully and thoroughly, a text-based interface can be as successful as a fully graphic one.