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.
I don’t want to write the words feature set for what we’re going to talk about today. But the words keep jumping into my mouth, or, um, into my fingers, since I’m typing and all.
Feature set is the term I use, but it’s a bad term, focussing on the wrong aspect of the app. People don’t care about features, they care about what apps do for them. Feature set obscures utility. Going too far the other way, being vague about dreams, or something is probably worse.
What we need to start the discussion of what Kapowski does is the 10-words-or-less description, the pithy phrase that sums up the app in conversation.
In the ‘Battle of the Bastards’ episode, we see Jon Snow and his army against Ramsay Bolton and his; it’s one of the best episodes of the season, maybe the whole series. Since the show, and the story, are unsympathetic to major characters, watching it for the first time you’re not really sure who will remain when the episode is over.
There was no CGI. Battle scenes were close and visceral, tense. I’m very rarely on the edge of my seat, literally or figuratively. But this episode…oh, man.
You might like it even better once you learn what you saw on screen wasn’t what was planned. And the situation will be familiar to any developer.
I’m writing an app for iOS 10. It will be on iPhones and iPads. I decided that first.
Then I picked a problem that an app can help solve.
This is not the way you should do it. It’s OK if I do it this way, I’m an expert; I skipped some steps.
Let’s talk about what you should probably do.
I don’t know what is says about me but the Explore tab in Instagram, for me, frequently shows me photos of fitness athletes of all shape, sizes and genders. Among those there are always before/after photos. I really like before/after photos, they inspire.
The night was…
Throw Momma from the Train, a middling movie from the 80s starring Billy Crystal and Danny DeVito, opens to a shot of a typewriter with that half-finished sentence. “The night was…humid.” In the film, Billy Crystal’s character has writer’s block. He can’t get passed the first sentence in his new novel. His wife had stolen his last, left him, published it under her own name; it was a bestseller for her. She has a guest appearance on Oprah, who, timeless and immortal, was relevant even back then.