Designing and Developing a Cribbage Board App for Apple's iPhone
Recently I executed an idea I've been kicking around in the back of my head for years, designing a cribbage board app for the iPhone.
The idea to create a cribbage board app was conceived in the Houston airport on a long, long layover several years ago. The airport gift shop sold playing cards. We decided to see if there was a cribbage board app in the iTunes App Store, and there were, a couple in fact, but we were frustrated with all of them. They took a long time to peg. A cribbage game is usually pretty fast paced. We spent a lot of time trying to work out the mechanics of keeping track of our points.
What I wanted to try designing was something that mimicked the mechanics of pegging on a physical board. A cribbage board is usually marked off in increments of five in order to make rapid counting easy. You have two pegs that leapfrog each other as you count points. The back peg leaps past the front peg and counts off however many points you are taking.
In a 24-hour period, between a Friday afternoon and Saturday morning I designed and created an app. My goal wasn't to see what I could do in 24 hours. This wasn't a RailsRumble-style attempt. That was the amount of time it took me to create and release a beta version. The app is incredibly simple. Even so I don't mean to undermine the amount of time that went into it either. My ability to create it in that time period is due to a decade of design and development experience and three decades of experience with the game of cribbage, a game introduced to me by my family and played with ferocity late into the night in a century-old house in Minnesota.
Typically, cribbage is played like tennis, the winner is the best of 3 or 5 games. An investigation of my sketches indicates an initial desire to keep track of the matches as well as a desire to allow the players to choose how many games were necessary to declare a winner. I decided to omit the ability to track matches on the basis of observation that in a 2-player game these were likely to be left unused, which simplified both the UI and the programming significantly.
One of my initial pen sketches of the user interface with notations regarding functionality.
In that 24-hour time period I spent approximately a quarter of the time designing the user interface. I sketched things out initially in a notebook and then refined them in Sketch, thinking out the user interface and mechanics of movement as much as I could in those static environments. I then spent about an hour playing with the different controls available in Xcode and eliminating a slider as a possibility for the peg. While initially it seemed like a good way to advance the peg forward, it was neither as springy as I wanted it to feel nor could you advance as quickly to a certain point as I wanted.
The user interface elements, designed in the Sketch application.
That was Friday afternoon. I then slept on it and woke up thinking about making the controls as buttons. I spent another quarter of the time programming the app, the majority of which was spent laying out the user interface and aligning the controls. The actual programming is pretty minimal. It's mostly plumbing controls to receiver functions and back to outlets with some very basic addition and subtraction in the middle.
The remaining time was spent taking screencaps for all the various sizes of device that the application is available on, making the necessary icons, and working through an archiving bug that kept popping up until I figured out that I had skipped a step in the deployment procedure. I spent the time uploading the archive to the app store to throw together and deploy a single page promotional and support site to meet those distribution requirements.
The initial storyboard, as previewed on a 4-inch, 3.5-inch and 5.5-inch iPhone.
The biggest learning experience I had was how to create separate layout files for different screen sizes. While Xcode provides a tool to make layout adjustments without needing separate storyboards for things like moving from portrait to landscape orientation and from iPhone to iPad, it doesn't allow you to granularly adjust layouts between different sized iPhones in the same orientation. The difference between a 3.5-inch high display and a 5.5-inch high display is significant and I could not find a satisfactory ratio of empty space to controls and information, so I wound up compressing things for the 3.5-inch display on its own storyboard.