Let’s try this again. This time around, I’ll start with a clear and simple statement of what I want to achieve with the program, and how I want the user experience to feel. There’s a clear use case, and it will probably exclude a lot of people, and I don’t care. I’m not trying to built the One Great Tool; I’m trying to solve the problem I have. If other people want to use my solution, that’s cool, but I’m not going to worry about it.
MTBP: User Story
I’m sitting there, minding my own business, and I hear a cough. Then I hear another. Then another. People are hacking and wheezing and coughing all around me. I feel like I’m in a freakin’ plague ward. Am I being neurotic? Probably. How can I tell? Write down the coughs as I hear them, look at the time window of the event — is it a lecture, a performance, a doctor’s waiting room, an airport terminal, or what? — and do some simple arithmetic. Am I really hearing a lot of coughs, or am I just freaking out because I hate being in public? Math will tell me.
MTBP: Input
My phone goes to sleep almost instantly. I don’t always have my laptop with me. The bigger and glowier the rectangle, the more of an obnoxious distraction it is to interact with it in public, especially when it’s not my primary focus and I have to switch contexts to record some data. Okay, so smart watch. There should be a complication I can stick on my Apple Watch. Tap the complication and that will bring an application to the foreground (complications will display state as it changes, but to receive interactions you have to be in an app context). I want to minimize fiddliness, so the application just allows you to tap the button to record an event. Not going to get all complicated with different event types or durations or anything else; tap the button and the event counter should increment.
MTBP: Analysis
This is where data visualization people really geek out. I am not that person, although I have deep and abiding respect for that person. Define the start and end of a time window. Query for events that happened within that window. Get back a set of events. Do something.
The shape of this feels a lot like server log analysis. Servers spew out tons of log messages all the time, for lots of different reasons. Logging systems aggregate these messages, transform them, and persist them. Analytics packages grab these logs and find things. All of this already existing stuff shows patterns that work, and work at scale. Just because it’s right for Google or Netflix doesn’t mean it’s necessarily the right choice for your one little not-so-chatty single user application. But there are architectural lines that are worth considering.
Finally, go ahead and offer it for sale. Because why not? I mean, I’m solving my problem; if it solves someone else’s problem, that’s awesome, and I hope it does, but I don’t think my work is worthless. Pay the worker, even if that worker is me.