I’ve referred a couple times to deadlines and schedule pressure as constraints one should embrace to make a great app (or similar software project). It’s a good cheat at forcing priorities, especially useful for version 1, where everything is so loose and open.
Deadlines, though—everyone knows—can be used for nefarious purposes as well.
I started formalizing the Settings screen first. Settings screens are typically afterthought in user’s minds, as they should be. Get the app design right and users should barely be in there. But, it’s a tough design problem and the code for the settings tends to spread its tendrils deep within the whole app; settings affect behaviour of the app, so getting most of it out of the way first helps get the app out the door faster.
So let’s breakdown the settings screen!
No plan survives contact with the enemy.
The enemy in this case is just circumstance and little things. I popped my ear, it’s the summer; you know, stuff and things. I planned to write every week day, but that hasn’t worked for a few weeks.
But: Kapowski is coming along nicely. I’m learning Sketch, Swift, iOS 10 libraries; I’m taking notes, sinking deeper into the problem; it’s great. You can see what I’m working on!
It was an unremarkable flight until we began our descent. I had big plans for the flight, to get some work done on Kapowski, and the trip, getting even more work done on Kapowski. Well, that didn’t happen.
Here’s what happened: my right ear exploded in pain as the pilot began our descent into Vancouver a week ago. A day later, it started oozing pus and blood. Turns out I have a perforated eardrum and a really bad infection; every doctor points out how nasty my infection is. My ear has improved since, but it still hurts right now. Seen Shaun of the Dead? I’m Bill Nighy, half-zombie, in the car, turning off the radio in relief.
Needless to say, my hopes and plans for the week (and then some) were dashed. This is a setback. They happen all the time. Here’s what you do about them.
When I did MysticMatch, I took to drawing my screens before coding them. I was about halfway through developing it when I started doing that. I’ve done that since with all projects. They start as hand drawn sketches.
I start with the obvious: basically a list of components that need to be there, put in their obvious spots. Kapowski is before and after photos; so, on the screen, two photos, in portrait, side-by-side, before on the left. Duh, right? It’s obvious. I want to list the dates for each photo—do I? Dates? What about something like, “4 months ago”? Fine, inner monologue, some way to show when they’re taken. We won’t just be taking photos, though. We need to show a list of measurements taken at the same time… Hmm, I’ve got an idea.
Quick! To the notebook!
The feature probably doesn’t matter, but we were introducing what we called the Dashboard to our product. The product was for IT guys to remotely administer networks from their mobile device. At the time, it was BlackBerry devices that were front and centre, but the product worked on Windows Mobile too.
It was a different world back then, which wasn’t that long ago.
Web 2.0 was ascendent. Gradients were everywhere.
Thinking about the design, I’m finding it harder and harder to focus on the screens. My notebook is filling up with model objects. I picked a deliberately simple problem from a coding perspective, and yet I’m drawn to it. What are the special cases? How am I going to store the images and other data?
That’s because, in my mind, the UI is ready enough to get started. Is doing the formal visual design worth the trouble before coding starts?
At this stage, I’d say it’s actively harmful to settle on a visual design. No one can possibly know the right design for this app yet. Because no one has used the app before.
Yesterday’s post ended in a tailspin of questions about Kapowski’s potential users when they entered progress. Stream of conscious writing with no editing doesn’t make for a clear message. So, let’s go back to the home screen.
All mobile apps have a screen that’s central to the experience of using the app. This screen’s importance cannot be overstated. It’s often the first screen users see every time they open the app. This screen should make it obvious what one can do with the app and how they can do it. Think through the apps you use, most of them probably show a list of stuff: any social media app, any video streaming app, communication app; it’s all just lists, man, jeez.
What will that look like in Kapowski?
Last week was all about defining the app we were going to build. In our case, we know it is, glibly, a progress tracker. We will emphasize photos as the progress indicator, since that most closely fits with what people actually want when they say they lose weight: a better looking body.
The design phase, to me, is a more drawn out version of what we did last week. It’s more explicit, more detailed. We finish talking about what the app will do. We start talking about what each screen in the app will do. By the end of the phase, we should have a clear idea what each screen does and a good idea of how the app will work.
This is the second most frustrating phase: There are still more questions than answers. We have to make explicit what, up to now, are just vague notions about how this app will work. There are so many what ifs, you really start doubting if you’re any good at anything by the time you’re finished. But that’s how you know you’re doing it right.