Cloud-native frontend app development

What I learned building a cloud-native frontend app for Asgardeo

Times change fast. Even more so if you are in the tech business. Fifteen years ago, JavaScript was only a child’s toy condemned to lend some semblance of programmability to web pages. Today, it is taking us to space. Fifteen years ago, WSO2 identity Server was a fledgling identity solution reposed in your on-prem servers. Today, we are launching to the cloud.

Asgardeo has been a great leap forward for me as well as my team. Making a leap means changing your thinking, questioning your perceptions, and radically overhauling the way you work. While it is not obviously easy, the paradigm shift is inevitable. After all, it is mandated by time. You struggle, stumble, feel like an imposter, persevere, persist and eventually you prevail.

Developing Asgardeo has been a humbling and educative experience for me. There were many learnings to take en route to the finish line. Here, I share some of what I learned from conception to realization.

Get ready to get bored

One of the major problems I faced while developing the Asgardeo Console app was getting so very used to the visual design of the frontend application to the point I became bored of it. In fact, I feel it is customary that at some point during the development of a frontend application that you start questioning your own design choices.

This is very natural and I am pretty sure most developers would be feeling this way. While the feeling is tough to digest, I found it gave me an opportunity to take a hard look at the initial designs and rejuvenate them. After all, subjecting your designs to skepticism can only make them better.

However, it is also important to remind yourself that it is in our nature to find things boring once we become familiar with them. Just because the application’s design does not excite me anymore does not mean a user would feel the same when they first get to use the application. This is why it is imperative that you conduct usability tests from time to time on your visual designs.

Even though you should not completely disregard this feeling, which is largely negative, you should also make sure you do not wallow in it. As a rule of thumb, whenever I found something not so appealing, I took a hard look at it. If there was anything I could change, I changed them. Otherwise, I moved on reminding myself it was only a natural feeling.

This taught me an important lesson-the need to be mindful. Being aware of our cognitive biases and being mindful of their ramifications in our design and development is important to provide our users with a great user experience and for peace of mind. Here, being mindful about the innate human nature of boredom allowed me to stick to my guns when I realized that there was little to improve on my designs.

The union between UX and frontend

By now, you would have already started wondering why a frontend engineer would bother about UX designs. Well, this was my second lesson.

It is easy to think of UX as a separate field in the industry that designs the products and hands them over to the developers. In actuality, that might not be the case. In fact, I do not like the concept of handing over the designs to the development team at all.

There are two reasons. Even though big businesses that work on several different products might afford to have a dedicated team of UX designers, mid-sized businesses that develop one or two products cannot afford to have too many UX designers. So, frontend engineers will have to invariably don the hat of UX designers.

While you might argue that an engineer should not be expected to do UX designing, I vehemently disagree. It is my belief that good engineering is always a product of good UX thinking. It is impossible to engineer a solution without understanding user pain points. Take ballpoint pens for instance. László Bíró engineered the ballpoint pen because he was sick and tired of having to refill fountain pens often. There you have it. Good UX thinking at the heart of great engineering.

The second reason is that designs evolve. I do not think you can ever settle on a design and call it the final design. There will always be new thinking, fresh perspectives, and, of course, several light-bulb moments.

So, as the design evolves, the development cannot just wait. There is no end to the UX process. So, the development process has to hitch a ride with the UX design process and go through several iterations. Designing, development, and testing all become a part of an iteration. This is an unending process. After all, being perfect is not a state; it is a process.

Progressive revelation

The truth is not revealed all at once. This philosophy is very much applicable to frontend engineering. At times, it is easy to become overwhelmed by many different design ideas and plans so much so you do not even know where to start. Often, you would be consumed by the design phase itself that there will not be any end in sight.

It is important to understand here that the human mind is a motherlode of ideas. The more you keep looking for new ideas, the more you will find. So, it is important that you choose something and start somewhere. You do not have to do everything at once. Just start with a viable idea and start implementing it. Then, you can revisit and revise designs iteratively.

I usually came up with the designs for a feature, discussed them with my team, revised them, and then started implementing them. At times, the designs were incomplete. There was that one problem to which I could not find a design solution. Initially, I fretted over it. But gradually I learned that things can be fixed on the fly.

Often, a solution to a design problem can be found when you try to solve a design problem in another feature. At other times, you will find it during a new round of discussions. That is why it is important to somewhere. Build something viable and keep adding things to it.

The implementation will also be improved incrementally. So, something that might seem so unflattering at the beginning will take shape with time and become a fully-fledged feature inevitably. The feature becomes complete only progressively!

UX evolves

As I mentioned earlier, designs evolve. So, do not become too attached to a feature that you have developed. In the frontend, nothing is permanent. This includes the application as well!

Yes, we started with one developer portal application. Then, that developer portal was cleaved into an admin portal and a developer portal. Then, we thought it should be one application and combined these two applications together and named it the Console app. One became two and the two became one again. Welcome to the world of frontend development!

This can be frustrating for some but this is the reality. Do not expect things to ossify. There will be new ideas. New researches will exhume new insights. So, it is imperative that you are always ready for a change. The general wisdom “if it ain’t broke, don’t fix it” does not apply to frontend.

Familiarity hampers empathy

When you become familiar with a user flow, you will eventually restrict yourself to a predictable pattern of user interactions. In addition, you will also become oblivious to the user pain points.

For example, in one of the forms in our application, we had a textbox to allow users to enter a URL. We then had a text button to allow users to add that URL to the list of allowed origins. The URL is useless without adding it to the list of allowed origins. However, we had got used to clicking on the button by muscle memory as soon as we entered the URL that we failed to realize that we could automatically add the URL to the list of allowed origins.

We realized this glitch when we tested this flow with a new user. So, this was an important lesson to me. When you develop and test applications, you will eventually start breezing through the flows. And this curse of knowledge will make it difficult to empathize with a new user. The only solution, in my view, is to test your application’s usability from time to time.

Cruise control vs. Power user

Our on-prem product was extremely customizable because we wanted the product to cater to a diverse set of users. In other words, we did not have a particular end-user.

When developing an application for the cloud, we need to know the end-user. This means that you need to abstract out a lot of the features to provide a simple and hassle-free user experience to the users. Our philosophy changed from building a heavily customizable product to building a heavily customized product.

For example, we preconfigured a lot of the settings based on user personas in the cloud application whereas we allowed users to configure them in the on-prem product. This allowed us to provide a great user experience to our end users.

However, it was not perfect. There were times when we wanted a user to have the option to adjust a setting while also ensuring that it was abstracted away from the main user flow. We accomplished this in two ways.

First, we created a simpler creation flow and allowed additional configurations in the edit view. So, if a user wants to create an application quick and fast, they can just canter through the application creation flow. If another user wants granular control over certain settings, then they can do so in the edit view.

Second, we hid advanced settings from the screen by default. This allowed for a simpler and straightforward UI. Power users can access the advanced settings by unhiding the settings.

More tests, fewer regrets

When developing the on-prem product, I had the luxury of being lax on testing. This is because we did not have to do continuous development and integration with the on-prem product. The generally available version of the product would only be released at the end of the development lifecycle.

However, in the cloud, your code changes are continuously pushed to the cloud. This means, there is no more room for buggy or half-baked code. So, I had to test my implementation manually and run automated end-to-end tests to verify that my changes were in order and that it didn’t break anything else in the application.

This was a bit getting used to owing to the process I was already used to. But by breaking builds and crashing applications in the cloud, I eventually coerced myself to ensure that the code I was pushing to the cloud was stable. That was a big learning curve.

Asgardeo has been a fascinating journey for me and it will continue to remain so. Just like the product itself, I realize I have also gone through several changes. My thinking has changed, my workflow has evolved and the development process has taken a new turn.

And the most exciting part is yet to come. My greatest excitement is in knowing how real users feel about the actual product and iterating on the designs based on their feedback. It will be a whole lot of fun to start revamping the features that you built from scratch knowing that that would improve the user experience.

In a way, you could say the biggest challenge is also yet to come. Developing a cloud application from scratch is only a tiny part of the application’s life. I know I will eventually end up spending more time maintaining and improving it than I did developing it.

Come what may, this experience has been so fulfilling that it has only made me look forward to the future. Here is to more designs, discussions, iterations, usability tests, code changes, and the consequent improvements to the product!

Originally published at https://www.thearmchaircritic.org on November 4, 2021.