Simple UI Problem: States — Loading, Error, Empty and Content
Almost every projects that I worked on or belong to me, I faced with and tried to solve simple but ignored problem: UI States. In this article, I just want to mention and raise awareness about this problem from my perspective as a developer.
Before start writing: All words in this article are my thoughts and it is possible that most of developers can think like me. 😃 Let’s start…
Lots of application developments which have UI, start with just design of contents and their states like loading, empty, error are postponed. After start to the development, the state problem comes to light. At this moment, responsibility of the problem is taken by developer with using dialogs to show loading, toast messages to display error messages, etc. However, when development team is more than three developers and the application has lots of different screens, the problem may have different solutions and these differences can effect user’s behavior directly. It may cause to reduce user interaction during your application usage.
After the short description about state problem and its possible effects, now, I try to describe states that developers select different approaches to display on screen.
If state problem is postponed until end of the development, the solution of the problem will not be hard generally, but cost will be always more than expected.
Loading
Loading is the simplest state for UI and developed quickly. Generally, solution of loading is chosen as display a loading dialog. But, this approach is not the best option all the time. Because, when a screen is started with loading dialog, user’s actions are blocked.
To create loading scenario, general application design concept is a very important point. Because, if your application has tabs or navigation menu, it is better to select in-page loading than dialog one. On the other hand, when the user is on payment page, UI actions can be blocked. If there is no blocking, user may change content and he/she doesn’t know result of the payment. And the last important point according to me, how the loading is displayed when screen has data. The loading can be placed at any side of the screen(upper left/right corner, top, center, etc.) and the blocking issue appears again.
Because of the reasons mentioned above, to display loading, all requirements of the related screens need to be described clearly and pay attention application flow.
Error
Error State has nearly same approaches like loading. Blocking user interaction, to display dialog/toast, cancellable/non-cancellable dialog, etc. It is possible to display different error states when using the application, but it need to have display standard to prevent confusion on user side. When showing error state, if there is no standard approach, you can cause user leaving from happy path of application.
Empty
Unfortunately, empty state is a more ignored state, but it is also simple to show. It can be displayed after the first loading state. For example, when the screen is triggered and the related response is empty, then empty state can be displayed. If the screen has content, error state using is more efficient. Usually, empty state has title/message about empty content and button maybe and can be different according to clients.
Content
It is impossible that Content is ignored. Because of this, there is no comment about this state. 😊
That’s all! I tried to explain how developers face problem about UI states as a developer. 😊 And if I have any more available time, I want to draw a simple diagram and add it to this post. In Trendyol, to reduce cost of state problem’s solution, we decide to develop a library and I have developed it to handle application states for our Android app and published on GitHub. If you have any thoughts or comments about the post or library, I want to hear your words.
