Oscillator Drum Jams: The Interface
This is the fourth post in a series about my new app Oscillator Drum Jams. Start here in Part 1.
You can download Oscillator Drum Jams at oscillatordrums.com.
This will be a shallower post than the others in this series. I just want to point out a few things.
The original UI was backwards
When I started this project, I thought about it like a programmer: as a view of a collection of data. So I naturally created a hierarchical interface: pages contain exercises, and exercises have a bunch of stuff in them. I worked really hard on an “exercise card” that would slide up from the bottom of the screen and could be swiped up to show more detail or swiped down to be hidden.
After an embarrassing amount of time, I realized I was optimizing for the wrong thing. Really, I was optimizing for nothing. I finally asked myself what people would want to do while using this app. My speculative answers were, in order of frequency:
- Stop and start loops
- Adjust the tempo
- Go to another exercise within the same page
- Go to another page
With that insight—and no user research, so never hire me as a PM—I made some wireframes:
I shed a single tear for my “wasted” work and spent the next couple of weekends replacing all of my UI code.
Although the iPad wireframe was still a bit silly, we ended up in a pretty good place. The important thing is the play/pause button is nice and big. At some point I expect to rearrange all the controls on iPad, though, because the arrangement doesn't have any organizing principle to it.
(It does look much better than it could have due to the efforts of designer Hannah Lipking!)
AutoLayout is a pain
I did this whole project using nothing but NSLayoutConstraint for layout, and I regret it. Cartography or FlexLayout would have saved me a lot of time and bugs.