It can be a web app accessible via a regular browser window; a dedicated mobile app downloadable and installable from an apps store is not a requirement. Cross-platform use and synchronization is a must, however, so that Android, iOS (including iPadOS), Windows, macOS and Linux are all fully supported.
An example of an “easy part” of my current setup would be the chains section (only launched by me last week) of the intended future app, currently available in the smaller Google spreadsheet at chains.avenarius.sk. That smaller spreadsheet should be relatively easy to convert to an app, I think (hope).
But even though it appears to be straightforward, I could find no currently existing “don’t break the chain!” app offering this simple yet customizable functionality available in my Google sheet.
Typically, apps are simple, but the cost to pay for that is a lack of customizability. I call that “the faulty Apple software model”. Unfortunately, it appears to be prevalent around the world nowadays.
And no wonder: it makes life a lot more comfortable, less demanding on software developers. Human beings are naturally lazy, and that also applies to (myself and) software developers. If they can get away with performing less work than strictly required, they will choose that route every time. It’s natural, and I don’t blame them. They only need to persuade their users (and Steve Jobs was superb in managing to make his fans believe whatever he set his mind to – even if it was ultimately against their best interests): “You don’t need your software to be customizable, you schmucks!”
People loved Steve so much they enthusiastically accepted whenever he told them that.
“Software does not need to be advanced or customizable at all! Simplicity is the king!” is nowadays a religion among hordes of software developers around the world. It’s a religion built on a faulty premise, but it’s powerful and currently dominating.
The opposite extreme (let’s crudely call it “the Russian model”) is to make an app fully customizable, but at the cost of ease of use.
So the true challenge for a software developer (as I mentioned in another recent blog post) would be to make The Happy App fully customizable, yet at the same time so easy to use that a 10-year-old child could handle it.
All advanced functionality/customizability of The Happy App would need to be skillfully “hidden” behind an “Advanced” layer, so that a user who doesn’t need advanced functionality or customizability perhaps never even notices that an advanced layer is there at all.
And so, this advanced layer would be skillfully hidden in the app by default, but users who need such advanced functionality/customizability would be capable of activating it and bringing it to the forefront, so that it would always be readily available to them at the tap of a finger.
Another option for where to start building the app would be around the most important habit out of all 114 habits currently tracked in the large spreadsheet. And that would be line 103 in the September 2021 spreadsheet. That’s my “happiness calculator” based on the formula:
This formula shows the user, in exact percentage, how happy she or he is in the current week, month, quarter, and year, and how that compares to the previous week, month, quarter, and year.
For example, my December 2021 habits spreadsheet is telling me (in line 104 of this particular sheet) that I’ve been 88% happy so far this current week, 66% happy in the current month (December 2021) and season (winter 2021/22, defined as December to February), and 36% happy for the whole year 2021. (Even though “36% happy” seems like little, it would in fact be my new personal best for a completed year, if I manage to stay at least on this level of happiness for the final two weeks of the current year.)
I find this single habit (“happiness”) so crucial that I would call the entire app based on that single habit: I’d call it The Happy App.
I’d call the app that, even though it also tracks 113 additional daily “habits” along with happiness, and now also includes a special “don’t break the chain” section. But the “happiness habit” – or measuring your happiness in life – seems so crucial to me that, to my mind, it would be well justified to call the entire app based on that single habit.
Once numeric “happiness data” are available, illuminating and motivating graphics and charts can be automatically built using those data, such as the following chart displaying my “happiness levels” over the course of this year’s summer:
But this chart is generated by a free online chart tool wholly separate from Google Sheets, and currently, if I wish to see such insightful and motivating charts, I need to input the data in that online chart tool manually every day, which is a nuisance and is time-consuming. The Happy App, as I envision it, would include such charting functionality by default.
And, it would send tailor-made, insightful and motivating notifications to the user, alerting the user to his or her “current trends”: including such trends that the user would likely not notice on his/her own just by looking at the raw data in the datasheet or even at the colorful charts built on those data.
Here is one such potential notification:
The urgency and frequency of such notifications (both “congratulatory”/positive ones, and “warning”/negative ones) would likewise be customizable by the user.
That’s roughly my idea or an outline of “The Happy App”.