Tech Story Time : Evolution of the Azure Portal UX

It‘s a dark, rainy night in Seattle. In a candlelit room a rocking chair rocked. “Gather around children. Today is a tale about the Perfect UX” said the old geezer sitting on his rocking chair starry eyed with age and wisdom, addressing his grandchildren, “But grandpa what is ‘Perfect UX’ ?”- said the bright kid sitting on the floor with his hand wrapped around his knees. The grandpa chuckled with despicable horror, “The Perfect UX is the mythical beast…. the UX designers sweat and toil to gets close to it… but no matter how close they get, they can NEVER grasp it in their hands…for it is made of …” he looked ominously over every child’s eye open in anticipation, “Ever Changing Customer Requests !!!!”, Gasps all around.

UX — User eXperience

The old man is right, decades from now when we are telling the same story to our grand kids (you know I would) we would have gone through so many UX iterations and overhauls we would need to search youtube for a video to remind us how things used to look like, provided someone cared to make one. UX here being User Experience. It is the experience you have for your smartphone or the experience you are having driving a car, all of which changes over time evolving to meet the customer’s need. For this post I am focusing on a very particular UX, the UX of a management portal for a cloud service provider, Microsoft Azure Cloud Service Platform.

I am deliberately picking the UX Evolution of Azure Management Experience as I am Software Developer working at Microsoft doing UX development on the latest Azure Management Experience, The idea is to convey my experience and gotchas gathered through the years to serve you on your UX development adventures in the future.

User experience designed for a customer base changes everyday through tinkering and polishing to get to the “right” state. One fine day the change has to be so drastic the users need to be moved into a new UX philosophy. The best moves happen when the flavor and familiarity are maintained without compromising on functionality.

A habit I developed when I started coding in my teens is to understand the reason and purpose for something to be made. To really understand the reason, I would dig through a lot of history and try to put myself in the shoes of the creator at that point in time. I would probe into the choices the creator had at his disposable to reach the decisions that shaped the thing that we experience today.

I will take you through history of the UX of Azure Management Portal putting ourselves in the shoes of two personas,
The Customer/End User of the UX
the Company/Developer of the UX.
We will try to reason out the triggers for the shifts in the UX Philosophy . So when we face them in the future for other projects we are aware of them to make the right call.

To iterate, Customer pillar focuses on the customer’s view of the experience, Development pillar focuses on the developer’s view of the experience.


First Portal : ASP .Net Portal

Azure was just starting out, we had 3 services, Cloud Services, VM and Sql Azure. We wanted customers to have an experience were we manage the hardware and they worry about the app development. The cloud was born, but to manage this cloud we had to let the customer have a portal from Microsoft to access the resources they are buying to run their work loads. The portal aimed to give the customer a place to create resources using the first version of Market Place. The Portal was a simple Asp.Net web application. I was not there during this time, and this was very brief as it was followed up by many demands and the next portal was made to replace this one. I was only able to find 1 screenshot of this portal !, Explains how old and elusive this portal was.


Second Portal : SilverLight Management Portal

M icrosoft was taking on every framework on sight during this time, One of the main competitor on the net was Adobe with Flash, to compete with Adobe Microsoft created its own brand, SilverLight, SilverLight was a interesting tech to build a management portal as the management portal experience mostly revolved around jumping between pages and doing operations, Building on SilverLight gave the portal UX team to keep the customer engaged by not reloading the browser and having a clean transition experience between his tasks, A Single Page Experience was born, Your app loads once and allows navigation without full page refresh. At the time it was a pretty cool experience.

Customer Side, people loved the portal, well at the start, it was quick (once it loaded) and had very consistent UX for managing all the resources a customer can have, like database,hosted services etc. But after a few years of using the portal, the customers started seeing the HTML5 web apps started popping up on the web, they loved the way the HTML5 web apps were clean and beautiful without the need for them to load SilverLight at startup. The biggest woe for the portal was the customers had to install SilverLight, this might seem trivial but for an IT guy letting someone install something on a machine was scary and some key customers start complaining that silver light is becoming a pain to deal with due to the initial install that was required and the need for constant updates. Eventually people started asking for a fancy HTML5 based portal to manage their resources just so they don’t have to install SilverLight. I would like to point out that some feature asks at that time started gaining momentum, like the ability to link resources, meaning if I have a website and a database I should know they are together so I can manage them together. The ability to allow Role Based Access Control (RBAC) for the resources, giving the ability to give permissions to your IT Pro to do operations on your cloud resources.

Developer Side, I was not there to experience this phase as a developer, but through investigation it was clear that development experience started out well with developers excited to use SilverLight the new shiny framework that had prospects of being a serious flash compete. This was the time SPAs were a unicorn with a rainbow painted on their side. The updates would have started becoming hard as years went by as more and more Azure teams (yes entire teams starting new features like Website, Traffic Manager etc) started sprouting inside Microsoft. Meaning there would have been a bottleneck at the portal development team level to light up features quickly as each team would have multiple requests. It took quality time to develop good Async safe UX in SilverLight.

Eventually, the customer pain point of installing SilverLight became hard to overcome as most of these environments the customer was working on machines that prevented them from installing anything on the machine due to security demands imposed on them by the company and the mounting maintainability costs of SilverLight coupled with development time, people working on the portal started looking towards the knight in shining armor, HTML5 !.

Third Portal : HTML5 — Manage.azure.com !

The Song of HTML5 sang on all radio stations, every developer under the sun wanted to get on the HTML5 roller coaster and built a new website. At Microsoft we were all excited as well, as a company Microsoft loves to use anything and everything at its disposal to create products that delight customer, here we got an opportunity to delight ourselves as well !. A lot of thought went into the development of the new portal, backend API layer, partner provisions, gallery etc.

We call this beloved portal “The Management Portal”. Because of the manage in the URL, Manage.azure.com

When the initial design of the HTML5 Portal was made, it was beautiful, it was a Semi-SPA built purely on HTML5 and Javascript. I call it Semi as there are page loads that happen when you switch directories or filter. But once you have those done, it becomes a full on SPA experience.

The RDFE layer was used by the portal teams to build each service. When the services started using RDFE to build the APIs that portal can consume, Azure had made a layer that can also be targeted by Powershell. The Layer was a traditional API layer but each extension had a bunch of operations to do, and the operations were not following a set principle making it hard for customers to intuitively understand the resources and their associated operations.
manage.azure.com Portal showing left pane with Azure features and right pane showing the list of resources under a feature which can drilled down.

Customer Side, the management portal was an instant celebrity of the cloud service world, it was a clean & simple way to manage all your cloud resources, linking was made possible leading to customer using the link to resource feature to build maps of resources to avoid accidental deletions and more. Customer loved the simplicity of the portal, it was clean, pleasant on the eye with light colors, intuitive to navigate and find things. People loved the tabs, the tabs and the dashboard were the main difference from the SilverLight portal and they added a lot of depth without complicating the UX. But as time past people found it hard to do RBAC on the resources. And when the cloud fever hit, we were showing hundreds of resources, it become hard to manage hundreds of VMs and the need for business style dashboards started to pop up. AWS was pushing the concept of resource group that was very popular with customers in the cloud world to group resources. Overall if you ask any customer, this portal was a clean fast experience that focused on simplicity. But it lacked provisions for Dashboards, RBAC, Grouping resources and fitting them inside the portal was a challenge. And the sheer number of services that exploded from 30 to 70 made the portal hard to adapt for all cases as many of the new services required a lot of space for new and improved UX to be successful.

Developer Side, I know little of this Era as I joined the UX team at the end of this phase, people who worked on the SilverLight portal started working on the HTML version as well. They focused on getting a very clean API via the RDFE layer and the code was written in pure javascript (as typescript was not invented yet !). The portal was a pleasure to code on as there was freedom to build custom controls on the tabs to express features. But the problem of one team working on the entire UX for Azure was putting a heavy burden on the developers as they had to work with now 50 odd teams to build their UX. But still they did it, the lesions learnt from SilverLight portal helped here and the common API layer of RDFE made feature building more streamlined. Even today the management portal code is considered a very well-made Javascript framework to maintain and support. The development experience also had the downsides of work with large quantities of javascipt. Javascript when used to build huge sites starts showing some cracks and demands high level of care during hotfixes and imposes deeper end to end testing. The requirement for RBAC and Dashboards started forming the need to build something better, and with the advent of typescript developers started looking forward to building typesafe portal code that would be withstand the scale at which the portal is operating. But the most important problem that had to solved was to remove the bottleneck of one UX team working for the entire Microsoft Azure Org.

Overall the Management Portal is still a beloved portal people used often even with the new portal being released. It is a comfortable experience customer still enjoy. RBAC was not properly materialized on the RDFE layer but as a lot of customers started using Azure as teams and companies moved to it, a more granular way of giving access to resources and their operations were needed, unfortunately the old portal was not able to handle this request as the change was too great to fit its framework as a lot of things needed to change from the ground up. And the mounting number of services also prompted the need for a development framework that service teams can use and build portal code rather than get a developer from the portal team to help them build a feature inside the pure HTML and JavaScript code base.

Forth Portal : Blades — Portal.azure.com

Live Tiles, they were everywhere, this was the time Windows 8 was released and tiles were the new things Microsoft was betting on, A UX paradigm where information is shown on a little rectangle that changes based on context, everyone wanted their UI to show tiles that change and show information.

Current Azure Management Portal Experience with Dashboards

When the new portal was announced people were excited to see the new tiles concept and the new blades concept that opened features to the right in the form windows that can be closed or minimized. It was a cool feature on the new portal that allowed customers to flow through the scenarios in the form of “Journeys”. The UX was very new, the idea was very new and the deviation from the old Management Portal was received with criticism, it was new to everyone and customer had a hurdle to learn the new model of blades. But the customers loved the dashboard feature and the RBAC features.

After seeing customer feedback during the portal’s initial days some of the concepts on the new portal were not intuitive, customer were having hard time with tiles and long journeys.

We saw that customer didn’t like tiles that much, so we started moving away from tiles, putting lesser and lesser tiles in the UX and let the customer place them in their own volition. The ability to course correct is vital in delivering the right UX. Only by focusing on the customer feedback you can point your ship towards the right UX.

The new portal blades also solved another problem, Scale !. The portal team moved away from building the UX for entire Azure and focused on the building the framework that every team in Azure used to build their UX. This shift removed the bottleneck on development, each team now has a dedicated UX team for example the App Service team has a dedicated UX team that builds their UX experience for Web App, Mobile App, App Service Environments and Api Apps. The Portal just hosts the UX on the shell of the framework.

By spreading the UX development load to feature teams the turn around time for features and hotfix dropped significantly, hotfixes that used to take a day now takes merely a couple of hours to reach the customer. Feature development happens at a rapid pace compared the management portal.

The Portal Visual UX is not the only enhanced, The API layer interactions also got a revamp, the portal runs on top of a new API layer called ARM, Azure Resource Manager is much more user-friendly than RDFE. To see how ARM works on your Azure resources you can take a tour of it here. https://resources.azure.com

RBAC requirements from users were tackled on the new portal and the framework of the portal takes care of most of the base level operations and makes the extensions (the UX code written by individual teams that plugs into the framework) care more on the features for their Azure Portfolio.

There are so many features I can talk about here, Resource group, automatic PowerShell generation, ARM Explorer, Third Party extensions, Improved Gallery, After my rant on the new portal which as it is evident I am super excited and proud of, I want to refocus on the UX learning,

The New Management Portal is built with Typescript making it much more manageable than full JavaScript portal. And with the Portal framework offering strict guidelines and prepackaged UI controls customer get a consistent experience even when 50 team develop separately. These two changes made the development and shipping experience much more streamlined.

I am sure there will be more customer asks and someday in the future we will be looking towards another UX model that satisfies the customer better, it is powerful and flexible, sure there will be issues but with the new paradigm of Azure teams owning the UX experience, the responsibility of satisfying the customer falls squarely on their shoulders, which in my view was a genius move by the portal team.

The Portal.azure.com, our “new portal” is a new advancement into making a portal that solves customer issues faster, allows multiple teams to work on it without hindering each other, creating a unique dashboard experience to allow users to manage their resources easily.I am sure that some customer would miss the simple management portal experience, but the trick is to maintain the flavor through iterations, we are in the processes of bringing the “simple” flavor of the old management portal to the new one.

If you have reached this section of the blog, Thanks for reading ! for your my avid reader I have to give you a bunch of follow up material,

A Great Blog about building Dashboards on the new portal

Conclusion ?

Hope my story around the Azure Portal UX Evolution was engaging and helpful, I didn’t go indepth on all the cool things on each of the portal and platform and did my best to stay to the message, If you are an azure user and have feedback for us ! Please share it with us at https://feedback.azure.com/forums/223579-azure-portal or vote for your features.

As I mentioned before and the only thing I like to drive home will be the below,

The key to building a perfect UX is through customer feedback, listening and course correcting to meet your customer’s need. UX is a subjective topic, as any subjective thing it requires more time and effort to get it universally liked, work with your customer to make your UX lovable !.

Enjoy and Happy Coding !

If you have any feedback for me please feel free to leave a comment, this is my first medium blog (or any blog for that matter). Help me polish up my first blog!, Thanks in advance !

Shout out to Byron, Leon and Michael who are actively working on the new portal hearing your feedback, if you have any feedback tweet them, they are very active on twitter. Thanks for helping me edit this blog Byron !

Byron : https://twitter.com/bktv99
Leon : https://twitter.com/lwelicki
Michael Flanakin : https://twitter.com/flanakin
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.