Article summary
In a previous post, I discussed investigating how the app my team is building handles loading and error states. Because of our project’s emphasis on quick feature development, the timing of addressing loading and error states isn’t always a focus. In the second part of this series, we’ll explore the strategic implications of implementing these states — whether to tackle them early or defer decisions until later stages.
Addressing Error and Loading States Early
Pros
Taking a proactive stance towards loading and error states offers several advantages. As I mentioned in my last post, having scaffolding for the data state handling was helpful for quicker implementation. I wondered if we should have just taken the extra step to use that data state to show loaders or errors in our original implementation. Establishing a solid pattern early on could have fostered consistency and facilitated low-effort adoption in subsequent feature development. We might have saved the time it took to go back and handle the data state in every area of our app.
Cons
On the other hand, I noticed several ways we were handling errors across the app. As I discussed in my previous post, I found multiple implementations of error states. Some areas had full-page errors, while others included a toast with a message like “Error fetching data.” We ended up using these two implementations in different scenarios. So, if we had used the implementation everywhere, it would’ve involved another pass through the code anyway to remove those toasts where applicable. We might have over-engineered the solution before we had all the information we needed to solve the problem.
Waiting Until Later
Pros
Conversely, delaying the implementation of loading and error states affords more time for feature development upfront and allows for a better understanding of project requirements. Especially at the beginning of our project, it was important for us to show significant progress in feature development. Spending extra time to focus on loading and error states would not have had as much of an impact on the quality of the product in our earlier demos.
Cons
However, there is a risk of overlooking crucial areas, necessitating a potentially significant effort to retrofit solutions at a later stage. This can also depend on the scope of the app. If you have a couple of different places you need to retrieve or modify data, implementing solutions later on might not be as much of a lift. But as the amount of data and number of screens grows, so does the effort required to do a full sweep implementation. It also increases the chances that areas of the app could fall through the cracks.
As we weigh the pros and cons of early versus delayed implementation, the importance of striking a balance becomes apparent. By considering project dynamics, resource constraints, and the evolving needs of our application, we can chart a course that maximizes efficiency and aligns team practices while ensuring a seamless user experience.