Objectified and becoming a better designer

Objectified is a documentary about design. It primarily covers industrial design, or the design of mass produced goods meant to be consumed by everyone, but it also discusses interaction design, or the design of how we interact with physical and digital objects and software.

Ironically, the documentary never explicitly defines design. Here’s what I gather it means: Design is about seeing a problem, or a need, and inventing a solution that fits that problem or need. It’s the process of creating a thing with a specific purpose in mind for that thing. We design physical things for physical problems, like chairs for sitting and knives for cutting, but we also design virtual things, like websites and interfaces for smartphone screens.

The key takeaway here is that all human-made objects in our world have a design story behind them. At some point, a designer made decisions about how that object would look, feel, and be used. To summarize Dieter Rams’s thoughts, design should be useful, understandable, aesthetic, sustainable, unobtrusive, and consistent. And perhaps most importantly, things should be designed as little as possible. Add nothing superfluous.

Something I’ve found myself thinking lately is the difference between design and pure engineering. As an iOS developer, I build apps, but I work from mockups that my designer partner, Tyler, created. It’s his job to be the visionary, and to craft an experience for our users, all in his head. It’s my job to materialize it. I put the gears into place, and make sure they move fast and don’t break easily.

Apps must both be usable and function well, and both roles, the designer and the engineer, are indispensable here. A few talented people, like Loren Brichter, are one-person design/engineering masters, capable of building beautiful and functional apps totally on their own. But if you take a random walk through any app store, I feel like the vast majority of apps are bad, because they’re built by one person who’s either good at design, or good at engineering, but not both. Engineers have the skill set that allows them to build apps easily, but not necessarily design them well.

I can level up as an engineer by building bigger apps and learning about good code design patterns and best practices, but I’ll level up as an app developer if I learn how to design better experiences and interfaces. The designer/artist/engineer is the triple threat of the production world. Let’s try to get better at all three.

His Son Won’t Do His Homework

I just read My Son Won’t Do His Homework.

The author’s 12 year old son is intelligent in many ways. He can learn music by ear, is a talented artist and illustrator, and highly skilled at video games. But he doesn’t have the math and science skills demanded by his classes at school, and won’t do his homework because he thinks that it’s pointless.

And the author agrees. He feels like schools are good at training kids to become good standardized test takers but don’t recognize actual value, or reward other skills that aren’t in the math/science domains. He knows his son is smart, but worries his son will have trouble getting into a good school, and finding a good job, because he refuses to fit into the cookie-cutter that modern schools create for kids.

I agree with some of his points, but not all of them. For example, I agree that it’s stupid to penalize students for handing their solutions in on the wrong type of paper when they get the answer right. But I don’t agree that schools are entirely useless. Schools teach you how to think analytically, even if the problems you’re studying aren’t relevant in the real world. They also teach you discipline and how to work. I do agree, though, that schooling “needs an update”, and that there are probably more optimal methods of teaching than the ancient lecture format that’s ubiquitous today.

Self Tracking

Thanks to one of my housemates I’ve gotten interested in self tracking lately. The basic idea is to gather data about yourself and learn from it to optimize your life. Simple example: I could log my mood throughout the day as well as the number of hours of sleep I get. Then I could correlate my average mood with hours of sleep, and I could find out the amount of time I should sleep to maximize mood. Obviously there are a lot of complex correlations you can make, depending on the amount of data you gather. There’s a whole community of people interested in this, called the Quantified Self movement.

I’ve tried self tracking before, but my past attempts all failed for a few reasons:

  • Tracking was cumbersome: I did most of my tracking in a spreadsheet on my laptop, but having to manually enter a lot of data was annoying and interfered with whatever I was doing. Plus whenever I was away from my computer I had to take notes on my phone, which took even longer and required transcription later. A simpler, more mobile solution would have been better.
  • Tracking was hard to remember: I tried to track my meals, but sometimes I would forget to write down what I had for breakfast. The same thing happened with tracking the hours that I went to bed and woke up.
  • No good reminder system: I wanted to track my happiness level throughout the day. At the time, I attempted to do this with alarms on my phone. This was a bad plan, since the alarms annoyed my girlfriend (I would spend a few seconds getting my phone out of my pocket to turn them off), and couldn’t be easily randomized (I wanted to sample happiness throughout the day as randomly as possible).

I’ve decided to take another stab at self-tracking, and I think I’ve solved all three of the above problems.

  • Simplify logging with a web app: Instead of a spreadsheet on my desktop, I’ve built a tiny web app which pre-fills data like the date and time and makes it easy to select frequent locations and people I’m with. When I want to download the data, I just format it as a CSV in a special results page. The app can be used from both my desktop and my phone, so all my data is in one place and is much faster to use than before.
  • Generate random calendar appointments: Calendar appointments are much better than alarms for simple reminders. Rather than ringing forever, calendar appointments pop-up on your phone (or desktop), optionally play a short sound, and then sit quietly until dismissed. Using a library for writing ICS (iCal) files, I generated dozens of random appointment reminders for tracking my happiness and imported them into a new Google calendar, which gets synced with my phone.

I’m three days into the experiment and it’s going well. The less effort I have to put into tracking and remembering to log data, the more likely I’ll be to continue it long term. Hopefully in a few months I’ll have some interesting data to talk about.

Analog Decoding

I recently stumbled across the personal website of Matt Sarnoff, a fellow CMU alumnus who’s done some cool side projects. My favorite one is a little thing called Millitext.

Millitext is a way to encode messages so that they can only be read by displaying the encoded letters on an LCD monitor and using a magnifying glass. It’s a “sub-pixel” encoding. Each pixel on your screen is actually three bands of red, green, and blue sub-pixels. Due to the limited resolution of the human eye, from a distance these bands blend together into normal colors. By sending a certain color to a single pixel on the screen, you can control which parts of the RGB bands are “lit” and which are not, allowing you to spell things on them. So this:

becomes this:

What I love about this is how decoding the digital pixels requires a very specific analog medium. Display the image on some other type of monitor, or print it out on paper, and it won’t work. Of course, this is true for all information. You need a specific decoder to make sense of it. But what’s interesting in this case is that the decoder happens to be almost a side effect of some particular piece of hardware.

It would be fun to see data encoded in analogous ways for our other senses as well. For example, you could construct an audio recording that only made sense when played in a particular cavern, where the echoes would be timed correctly to make your message audible. It would be a fun puzzle to be in that kind of space and have to move around to find the position where the audio made sense.

What I learned from building an online board game

I recently finished an online version of Homesteaders, a board game by Alex Rockwell. Building the app was a great learning experience for writing maintainable code and designing a web app.

Listed below are a few of the things I learned. A lot of it is obvious, sure, but I had seen this advice before and still ignored it. Consider me thoroughly humbled.

Plan ahead

When I started coding Homesteaders, I thought I had a “pretty good idea” of how the game worked. I also thought this meant had a pretty good idea of how to structure the code. This would have been a decent approach, had I been coding tic-tac-toe.  I was able to quickly hack together a skeleton of the full game, which progressed through player turns and game phases successfully, but as I started to implement the more complex components of the game (like auctions, selling goods, and purchasing buildings) I realized I had forgotten about dozens of special cases and quirks in turn structure that conflicted with my architecture. The result was a kluged mess of duplicate code and labyrinthine paths of execution that made debugging a painful experience.  What I should have done was write up a small design doc, or sketched one out on paper, that described all the major components of the game and enumerated all the special cases that would come back to haunt me later. This probably would have helped me come up with an architecture that handled Homesteaders’ unusual turn structure more elegantly. Not all games are as complex as Homesteaders, but at the very least make sure you know what the big picture is before you start to code.

Read the rules

This advice applies just as much to playing games in real life as it does to coding them. Board games, unlike video games, can be played wrong. If you misread the rules, you end up playing an entirely different game than the designers intended. If the error is small it can go unnoticed for a while, until you play with someone else who learned the rules from a different source than you.  I didn’t re-read the full rules to Homesteaders prior to building my online version, and ended up having to change a lot of code when a friend explained I had been playing with the turn order wrong all this time. It’s also embarassing when you demo a game for one of the original playtesters and you realize you got the rules wrong…

Test Test Test

And then test some more. The first few full games of Homesteaders I played with other people had game-breaking or annoying bugs that could have been avoided if I had simply played out a few full games by myself, start to finish. Don’t waste your players’ time. Planning can help avoid bugs, but it’s not a substitute for thorough testing. Don’t be lazy!

Interface feedback is essential

Your interface should be so simple and so easy to use that someone who’s never heard of the game can play it and understand what’s going on. Everything should have a label, and buttons should be responsive when highlighted and pressed. I’ll admit I got lazy here, since the current Homesteaders interface needs a ton of work, but it’s vastly better than the original.

Zune Woes

I love Windows Phone but both the mobile version of Zune and the desktop app have some serious issues.

  • You can’t jump to a position in a song while on the phone. Instead you have to fast forward or rewind to the part you want.
  • When you fill up your device, you have to clear space on it by “unchecking sync groups”. It is unclear what this means and what the consequences are.
  • If you search for anything, it waits to show you online results before the results in your library. My library results should appear instantly, and I almost never want to search online – I’m usually looking for a particular song in my library.
  • Items that you search for cannot be played or added to a playlist from the search results screen. You have to select the individual search result first. So, if I want to add multiple search results to a playlist, I have to click each of them individually and add them.
  • There’s no real rating system. I’d like more variation than just “heart” or “broken heart” with my songs.

One gripe I used to have was the shuffle and repeat options were undiscoverable on the phone, but that has been fixed with the Mango update. Hopefully Microsoft’s paying attention. How can they expect to convert customers to Windows Phone if its software is a pain to use?

Writing a Cryptogram Solver

As a weekend project I wrote a cryptogram solver. You give it a cryptogram and it figures out some possible translations of that cryptogram, ordered by probability. You can also use it to make your own cryptograms.

This is a project I’ve wanted to do for a while and was also a good programming puzzle in itself. If you like puzzles or solving cryptograms I highly recommend writing one of these and coming up with your own algorithm. The one I came up with turns out to be close to the same one used by Decrypto: Starting from the largest word in the ciphertext, find all possible translations for that word in order of frequency. For each translation, recursively translate the rest of the cryptogram with the added constraints (i.e. added mappings from cipher letters to plaintext letters found from the new word). There are a few other hacks thrown in to fine tune performance. For example, it tries solving the full cryptogram, and then removes each word one at a time and tries to solve without having seen that word. This is useful if your text has long proper nouns that also happen to decode to real dictionary words.

It turns out this method is pretty fast if you have a good dictionary sorted by word length and word frequency. The dictionaries I found online included too many words that no reasonable human being would ever use and weren’t sorted by frequency, so I made my own dictionary by examining the text from a bunch of books on Project Gutenberg. Because I only used five books there were some problems with this approach (e.g. “EYRE” and “FINN” show up as high probability four letter words) but the solver works pretty well in spite of this.

As a side note, in the process of testing the solver Julia and I discovered some interesting things you can do with a cryptogram solver. Feed a solver a palindrome and it will give you all other palindromes of that length with those word breaks, and if you feed it the letters “abcdef…” etc. and you’ll get all isograms of that length.

You can check out the source code on GitHub here, or download the Windows installer and use the tool from here. I wrote this primarily for me so it hasn’t undergone lots of testing. Let me know if you discover any bugs or have ideas for improvements.

Window Manipulation with the Microsoft Touch Mouse

Julia and I won first place in the Most Useful category at the UIST 2011 Student Innovation Competition! Our application used the Microsoft Touch Mouse to move windows around by doing a three finger click anywhere on the window (I don’t understand why Microsoft hasn’t added this already in Windows 8 ) and also lets you resize windows with a two finger gesture on the mouse.

Sliding Block Puzzle in HTML and JavaScript

I’m starting to learn web development with HTML and JavaScript. To get started and to teach myself how to do basic interactions and animations, I built the 15-puzzle as a web page. You can try it out here.

Every time you play the script selects a picture and board size at random. All games are guaranteed to be winnable :)

To see how it works just view the source for the page. The code is pretty basic, so no promises that I did anything in the best possible way. I’m still learning after all.