Four eyes better than two!

I’ve released three small Apps in the last year. When you are responsible for everything from design and development to content and UX, it becomes easy to miss things. Development is the easy part – the rest is a lot more difficult and if you increase the number of eyes, you spot the problems sooner.

The Apps

The first two Apps were game scorers for Yahtzee and Yatzy. With these Apps, my primary focus was the score sheets, the rest of the App was very much secondary. I thought the score sheets worked well but later I realised I messed up the initial user experience. How did I mess up the initial user experience? Easy – my goal was to allow you to start a game and get to the score sheets, everything else was a side task and poorly designed.

When writing Budget (our free open-source budging app), I realised I had messed up the onboarding and thought I had solved it, well improved at least. The initial user experience for Budget is guided and the Apps explains how it works. I even went as far as adding a demo.

The issue

Where is the issue? Well, there was a major issue with the demo. Once you create the demo you are locked into it. I incorrectly assumed all users would “adopt” the demo and get on with using the App. I never considered people would do as the text suggests and simple play with the demo to see how my App works.

There is an option to reset the App and return to the initial state, but it is hidden under account management. A user was unlikely to find this option and more likely, drop the App.

A solution

The solution? Next to the “adopt” button, I’ve added a “reset” button. This provides inexperienced users two options – adopt the generated budget once they are familiar with how the App works or reset and start again.

I recently started developing Budget Pro and I will not make these same mistakes.

I decided to develop all the Apps in the above order specifically because I wanted the quality to increase with each new App.

Budget Pro is our first commercial offering for the Costs to Expect service, it needs to be the best example of what the service offers.

Four eyes are better than two

I said “I” all the way through this post and for much of the development this was true. Recently, my wife (Twitter) has joined me in this endeavour. In addition to being an excellent editor and content writer she is helping with quality. The plan is that four eyes are going to better at spotting these types of issues than two.

Four eyes must be better than two! I’m not just getting an extra set of eyes to help me – there is a brain as well.

Tailwind, Have I switched?

A man getting blown away in a storm, her is trying to hold onto a windsock

I’ve never been much of a designer. I know what I like, and I can recreate any design a designer passes my way. However, producing anything original is incredibly hard.

I switched to Bootstrap many years ago. I switched because I needed a way to solve this problem, Bootstrap made it easy to create what I wanted. Additionally, it would also look OK – typically much better than ok.

Bootstrap sites typically look the same and before I go on, I don’t necessarily consider that a “bad thing”. The problem arises when you don’t want everything to look the same. Customisation is possible with Bootstrap, particularly version 5. However, it gets complicated quickly.

I’ve released three Apps in the last year. Two game scorers for Yahtzee and Yatzy and Budget, a free open-source budgeting App. The Apps all look ‘similar’, this isn’t necessary a problem because they all belong to the Costs to Expect service so it should be obvious that they belong to the same brand. However, I wanted something different for Budget Pro, an evolution of Budget.

Why not Bootstrap?

Budget Pro belongs to the same family as all the Apps I released this year but being the paid version, I wanted to differentiate it from Budget and give it a sharpened look. Due to its features, it will also have a more complex UI than Budget. As I was thinking about how to ‘improve’ the Budget design I decided to give Tailwind a go as everything I’ve seen of it has impressed me, particularly Tailwind UI.

Why Tailwind?

Two things pushed me over the edge. Firstly. Tailwind UI, having an extensive library of components to build with and from made it easy to get started and start building up ideas. Secondly, the standalone cli; I don’t want or need any additional dependencies and prefer vanilla JavaScript over any front-end toolchains.

I’m only a little way into my journey with Tailwind but so far, I’m loving it. Yes, you end up with lots of classes in the HTML. However, you know what each of them do based on the name and I create components to reduce duplication anyway.

We’ll see if the honeymoon continues as I move away from landing and content pages. It is when you get into the nitty gritty of creating the meat of Budget Pro things might go south.

I ‘ll make sure to post a Tailwind update when I am further into the development of Budget Pro.