July 20, 2022
Some time ago, due to a lack of a mobile flat rate, I started to not only pay for the landline connection included in my DSL line, but actually use it as such. Because it was a VoIP connection and I didn’t have any suitable hardware at hand, I decided on a software solution in the form of a Raspberry Pi with an Asterisk server and an app to use my smartphone as a telephone. So far, so simple (more or less anyway).
The only catch to this solution was that I could only see missed calls if my smartphone was connected to the system during the call (which implies that I’m at home and might just answer the phone). I had the entire call history available in an SQL table, but I had to manually check it via an SSH connection onto the Pi and that didn’t seem very pleasant in the long run. So I had the idea of displaying the data in a web interface. The choice of technology was based more on what seemed helpful for the customer project at the time than on the actual requirements of the application. That way, the choice was Angular with Material in the frontend and Spring Boot in the backend.
1. Iteration - Room for Improvement
When a developer wants to display data that’s stored in a relational database and does not have a clear idea of the UI, one quickly tends to display the data in tabular form as well. That is also exactly what I did here first. In this first version of the application, in contrast to the direct view into the database, at least time and date values are formatted in a meaningful way. In addition, the direction of the call and whether it was answered is shown in the form of a coloured icon. Nevertheless, it’s basically the same table - just colored.
2. Iteration - Rough clean-up
What bothered me most in the first version was that both numbers involved were displayed for each call. Since one of them was always the same (my own, to be precise), the information gain from that additional data was limited. And because the numbers were shown as source and destination, the relevant number was in a different column depending on the direction of the call.
Displaying only the foreign number immediately brings a gain. Information that is of the same type from the user’s point of view is now always in the same column - no longer in a zig-zag pattern. In addition, the icon set has been changed. Where previously login/logout icons were used to serve another purpose, now the real call icons from Material Design are being used. A first step towards a more familiar view.
The fact that the shadow of the table was removed during this change falls more in the area of UI-Design than UX. What should the table be separated from here by a frame or shadow? And to make it unmistakably clear what the user is looking at, a heading has been added.
3. Iteration - As you know it
Even after the second iteration, the app still had a slightly technical feel. That might be OK if it was an application for call center staff. They probably need a lot of information at a glance and would be happy with such a view. I however am not such a power user, but rather look into the application once every few days for a few minutes at most. And in terms of looks, so far it has had little in common with other call lists that I use. But is there a reason for that? Wouldn’t it be easier if this app looked similar to other ones? Lets’s try.
This iteration now bears a strong resemblance to the call lists I am used to. Specifically with the phone app and the VoIP app on my smartphone, but probably also with those of other manufacturers. For example, if I have previously looked at the VoIP app on my smartphone, this view makes it easier for me to quickly see whether there are calls in this list that have not reached me. The table structure has completely disappeared and suddenly the page also works well on a smartphone. Headings for the old table columns are not even necessary because the familiar layout is quite self-explanatory.
4. Iteration - Covering new requirements
While the app now felt quite usable, I began asking myself how I’m actually using the landline. For example, with whom and for how long I’m on the phone. Of course, I didn’t assume that the speaking time would come anywhere near the amount of work I spent on the app or the initial configuration of the system. But the journey was also part of the goal and I did expect to learn something along the way.
This iteration now fulfills those requirements that arose in the first place through the usage of the app. Having such a short and direct communication path to the user – and thus the possibility to react to new requirements quasi in real time – is rarely found in real-life projects.
5. Iteration - Sharpening the original idea
What hadn’t changed after the addition of the new features was that I still had to go through the call list myself to see if there was a new missed call in there. And after the application relieved me of the task of counting who I was talking to, how often and for how long, this became a bit dull and boring. About that time, I came up with the crazy idea to simply display the information whether there are new missed calls. If new use cases are covered by additional features, why not do it for the original use case that was the reason for building the application in the first place.
Because it is the main use case, the new missed calls counter (for the last 7 days) is displayed prominently above the other elements. This has significantly reduced the usage time of the application, but increased user satisfaction by about the same extent.
If I hadn’t already taken the system out of operation by now, the next iteration might have initially hidden the lower elements and only shown them after clicking a button, then you wouldn’t be immediately confronted with so much information.
Conclusion
At the end of this journey, I have built an app that is strikingly simple: If you want to know whether you have missed calls, you build an application that shows you which calls you have missed – quite obvious, isn’t it?
The way to get there was very illustrative for the learning effect, but certainly not the one that leads the fastest to the goal. A better approach would have been to think about the exact requirements before starting the implementation. In a more extensive project, it would quickly take weeks or longer to rebuild everything several times. This would not be very satisfactory for either the developers or the stakeholders.
What I learned in the end may sound obvious, but it tends to be forgotten. If you need to build a graphical user interface as a developer you should dare to pause for a moment and not immediately build the first solution that pops into your head. Rather, think about who will use the application and what do they want to achieve.
And anyone for interested in how I built this application that you’ve seen (or those who also belongs to the obscure fringe group of people who operate a domestic landline with an enterprise-grade software telephone system and would like a nice UI to go with it), you can find the code on Github.
You can also read this article in german.