It is always caching!

In October I added multiple account deletion options to the Costs to Expect API – you can delete the data for a specific App, reset the data for a specific App or delete your account entirely.

There could be a large amount of data to delete so I decided to handle the deletes behind the scenes with jobs. This worked well and during all my testing, there was never an issue and if an issue does occur, I’ve added a notification to catch it and let me know.

However, after release, I tested with a throwaway account, and it wasn’t working. As a user I could reset my state but when I signed in again all my data was still showing.

For a little while I was perplexed. The API wasn’t erroring, the data was being removed but Budget still showed the old state. The first hint happened when I tried to do something in Budget; I immediately got an error from the API, a budget item couldn’t be created because the resource didn’t exist.

Aha! I knew what the problem was. I said to myself, “Budget has data, the API doesn’t, there must be a cache issue somewhere.

Budget doesn’t retain a cache so it can only be the API. I rush (really, I did) to my IDE and low and behold, my jobs don’t clear the cache after deleting the requested data – oops!

How did this happen?

Well, that’s easy. During development, I turn off the cache on my local instance of the API as I don’t want the cache getting in the way of any new features I’m writing or debugging. I test before I make a new release, manually and automatically. Though clearly, I’m not always turning cache back on.

The Solution

The solution is easy – do a better job of testing but it isn’t quite as simple as that. I’m going to update my automatic tests to include testing with and without caching enabled. More importantly though, I’m going to expose the API cache status.

It isn’t unusual for the development or staging version of your Apps to highlight their status – a bar at the top, a different background, a visual notifier of some kind. I’m going to update Budget and all the other Costs to Expect Apps to include this notifier and show the state of the API, is caching enabled? Is it in debug mode? That way when I’m testing a data state feature, I’m more likely to spot that status and think about the extra steps.

Don’t create a pointless demo?

We wanted users to have a good initial experience with the Budget App so we added a demo. Yes, there was an issue or two along the way but in general, the demo turned out to be useful. When your App crosses the trivial boundary, you need to be able to show users what they can do; there is little worse than signing up to a new App and not being able to do anything because you don’t have any data.

However, the existence of a demo is not enough – it needs to be useful, it needs to include initial mock data but more importantly, hint at all or many of the features that exist in your App. As developers it is all too easy to create data that is ‘pretty’, we need to create mock real data that will more closely match a user’s real-life experience.

With a blogging App, it would make sense for the initial data to show all the available states a post can have, ‘published’, ‘draft’, ‘scheduled’ etc. – that way rather than seeing a list of completed posts, the user gets to see that posts exist and immediately discovers there is a scheduling system.

What is wrong with Budget?

The demo for Budget creates two projection accounts and ten expense items of several types, that way when a user loads the demo, they get to see how their budget is likely to display and they can play.

So far so good.

Nope, we aren’t exposing all the features; budget items can be marked as paid, disabled and their balances can be adjusted on an ad-hoc basis. These are small features but are part of the general workflow, by being missing from the demo data, we are hoping users find the relevant action buttons rather than letting them know they exist from the start.

Before the official release I am going to review the demo data for Budget and correct the issues I’ve talked about in this post. I’m also going to make a point of reviewing the demo data every few months to ensure we are covering any newly added features.

Four eyes must be better than two!

I’ve released three small Apps in the last year and 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 little more difficult.

The first two Apps were game scorers for Yahtzee and Yatzy. With these, my primary focus was the score sheets – 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 (out free open-source budging app), I realised this short coming and thought I had solved it. The initial user experience for Budget is guided and explains how to use the App – I even went as far as adding a demo.

Where is the issue? Well, the issue was with the demo. Once you create the demo you are locked in. I assumed you would “adopt” the demo and get on with using the App. There is an option to reset the App and return to the initial state, but it is hidden under account management. The solution? Next to the “adopt” button, I’ve added a “reset” button and this gives inexperienced users two options – adopt the 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 the mentioned Apps in this order specifically because I wanted the quality to increase with each new App.

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

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, the plan is four eyes are going to better at spotting these types of issues than two.

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

Have I switched to Tailwind?

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 to help me solve the problem, Bootstrap made it easy to create what I wanted and still have it look OK – typically more 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.

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.

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 and get into the nitty gritty of creating the meat of Budget Pro.