The app still has bugs. Even though your devs are concerned about them, in the bigger picture, you’ve just realized you’ve got more important problems: no one knows you’re app is coming.
Welcome to prerelease. I don’t have much advice to give here: this is new territory for me. I know lots of theory, but I haven’t really applied it to any of my previous apps, or someone else did it. But, this time, I’m going to go through with it. This is learning in action!
There’s a term with which you should be familiar if you deal with software development in any capacity: bike-shedding. The term bike-shedding represents a metaphor to illustrate the Law of Triviality. Essentially, imagine a board meeting discussing construction of a nuclear power plant; most of the time will be spent arguing the materials of the bike shed rather than the more important, but complex, construction of the plant itself.
Software development is rife with bike shedding.
Imagine developers in a room: they will agonize over spaces in a file or where the curly brace goes. Yet their app is drowning in over-engineered “frameworks” that no one understands.
Wait, it gets worse: if there is anyone non-technical in the room, the only thing the group can all reason about is user facing stuff: images, icons, colours, animations. This stuff matters, yes, but quite a bit less than anyone thinks.
So, who wants to do some bike-shedding on Kapowski’s App Icon?
What’s this app for again?
Oh, right. Make it easy, and habit forming, to take photos and measurements to track progress during physique transformation.
It’s not a complicated premise. I assume most people are aware of before and after photos.
Ew. That last sentence made my programmer spider sense tingle. Let me be more precise: those interested in physique transformation (fat loss, muscle gain) have presumably browsed websites related to exercise and fat loss. One cannot go to those sites and not see a before and after photo comparison.
My hope is that some of those who are so motivated search the app store for the best app in the store that does that: Kapowski!
Let’s go through what they’ll be greeted with when the open the app for the first time.
Remember how I said normals can’t visualize user interfaces without a picture of the user interface in front of them? To be completely clear, I classify normals as anyone who is not an app/front end web developer. Without at least a poorly executed hand-drawn sketch of a screen in an app, everyone else is lost.
I’ve also found that as that hand-drawn sketch gets better, goes digital and gets closer and closer to what everyone thinks will be the final look for the app, normals have a tough time distinguishing between that mockup and the final app. Ditto for “prototyping apps” like Invision.
The screen is the app to them. That screen is also the network and the server, or servers on the other end of those network calls.
Making the actual app look like that mockup, whereever it came from, is the app developer’s job.
You are on some company’s website, interested in their product. It’s packed with features you need. The screenshots look fabulous: So many gradients! You make the decision to download the trial. You click download on the menu, navigate to the download page. There’s a form with 10 text boxes to fill out. You close the browser tab.
This is often the case for enterprise software: they want to vet you right away to see if you’re a good candidate to go after. It could mean martini lunches and golf trips for the sales guys, while the developers work extra hard back at the office getting that TPS report cover letter generator feature working. Sigh, you can probably tell which group I was in.
The water below is a sheet of glass. The sun is just peaking up over the trees, but it is already hot out; hot enough to consider jumping in the lake this early in the morning. From where you stand, there is a 3m drop to the water. It’s easier to get in by the dock, but the water is a deep enough here to safely jump in from this height. There’s a thrill jumping from this height, a little trepidation too, for the first jump of the day.
You jump feet first. Within a second, you’re in the water; the serene surface broken by froth of your entry, ripples in the surface emanating from where you entered the water. You did it: the first jump of the day.
Great. But why doesn’t anyone think about the poor water?
Imagine you are a lake. It’s a pleasantly warm day so far, but even if it gets really hot, you’re a lake; it’s ok. There’s no breeze. All of a sudden you’re surface is wrecked with a big splash by some doofus in board shorts and a bad haircut. Right in your good water! You love that water. Now it’s all over the place. What a mess.
The very first time you open an app, you’re the water. What would make that less traumatic?
I’ve started integrating Apple frameworks into Kapowski.
Rather, I’ve started being a pathological user and realizing my integration is woefully inadequate. What’s a pathological user, you ask? A dickhead, basically.
Do you get a lot of push notifications? You probably got, like, eight just reading this sentence.
Every app seems to want to push something to you.
It’s been almost a month since the last update. Even though I haven’t been writing as often as I’d like about the work, the work is happening.
There is a point in a project when there are no more questions to ask. Everything major has been dealt with at least, but perhaps solved entirely. The rest of the work is following those decisions to their end, filling in the necessary details to embed those decisions in the code.
We are at that point with Kapowski.
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.