The "Blades" experience [0] where instead of navigating between pages it just kept opening things to the side and expanding horizontally?
Yeah, that had some fun ideas but was way more confusing than it needed to be. But also that was quite a few years back now. The Portal ditched that experience relatively quickly. Just long enough to leave a lot of awful first impressions, but not long enough for it to be much more than a distant memory at this point, several redesigns later.
[0] The name "Blades" for that came from the early years of the Xbox 360, maybe not the best UX to emulate for a complex control panel/portal.
Azure to me has always suffered from a belief that “UI innovations can solve UX complexity if you just try hard enough.”
Like, AWS, and GCP to a lesser extent, has a principled approach where simple click-ops goals are simple. You can access the richer metadata/IAM object model at any time, but the wizards you see are dumb enough to make easy things easy.
With Azure, those blades allow tremendously complex “you need to build an X Container and a Container Bucket to be able to add an X” flows to coexist on the same page. While this exposes the true complexity, and looks cool/works well for power users, it is exceedingly unintuitive. Inline documentation doesn’t solve this problem.
I sometimes wonder if this is by design: like QuickBooks, there’s an entire economy of consultants who need to be Certified and thus will promote your product for their own benefit! Making the interface friendly to them and daunting to mere mortals is a feature, not a bug.
But in Azure’s case it’s hard to tell how much this is intentional.
I still feel lost just trying to view my application logs.
I don't want to pay for or lock myself into, "Azure Insights".
I just want to see the logging, that I know if I can remember the right buttons to click, are available.
The worst place to try is "Monitoring > Logs", this is where you get faced up front with a query designer. I've never worked out how to do a simple "list by time" on that query designer, but it doesn't matter, because if you suffer through that UX, you find out that's not actually where the logs are anyway.
You have to go down a different path. Don't be distracted by "Log Stream", that's not it either, it sounds useful but it's not. By default it doesn't log anything. If you do configure it to log, then it still doesn't actually log everything.
What you have to actually do, and I've had to open the portal to check this, is click "Diagnose and Solve Problems" and then look for "Diagnostic tools" and then a small link to "Application Event Logs".
Finally you get to your logs, although it's still a bad way to try to view logs, it's at least marginally better than the real windows event viewer, an application that feels like it hasn't been updated since NT4. ( Although some might suggest that's a good thing. )
A lot of Azure Insights is a value add on top of OTel. You can use "just" OTel feeding Azure Insights (and that's what the modern Aspire-influenced defaults mostly do) and possibly avoid that feeling of vendor lockin. That perspective might also give you ideas of other "modern" vendors to audition such as Grafana if you wanted to see what other people are doing with OTel rather than Event Logs and file system logs.
I love that OTel exists, but I've always been confused why OTel even existed. If I were running a cloud provider, I'd put a "skunkworks" team on all things observability and log management a decade ago, and make their product free to use. It's not critical-path on infrastructure, so it's not a correlated risk other than the investment in manpower, but it dramatically changes how user-friendly your web interface is, and how likely people are to use it daily vs. managing things over command line or with third-party interfaces.
By bringing those eyeballs onto your cloud console, you're creating infinitely more opportunities for branded interaction and discovery of your other cloud products - you could even quantify these eyeballs as you would ad inventory! There should have been an arms race for each cloud provider to have the best log-tailing and log-searching and log-aggregation system imaginable. OTel could have been killed before it began, because Honeycomb and its other originators would have been acquired years ago and made specific locked-in value-adds for each cloud.
But nobody had this foresight, and thus comments like yours are absolutely correct. OTel is a blessing and I love the tools coming out. But from a cloud provider's perspective, it's a massive missed opportunity that continues to be missed.
> By bringing those eyeballs onto your cloud console, you're creating infinitely more opportunities for branded interaction and discovery of your other cloud products - you could even quantify these eyeballs as you would ad inventory! There should have been an arms race for each cloud provider to have the best log-tailing and log-searching and log-aggregation system imaginable. OTel could have been killed before it began, because Honeycomb and its other originators would have been acquired years ago and made specific locked-in value-adds for each cloud.
I think that's what Application Insights has always been, Azure's free-to-start, suggest-out-of-the-box Honeycomb. App Insights had a long slow road away from Microsoft-specific log and metrics ingesters that weren't OTel, but it is hard to argue that standard ingestors are a bad idea. App Insights still downplays that it can be "just a Honeycomb" using only OTel sources and still encourages "secret sauce" ingestors in addition to OTel ones. App Insights is a small moat (around a data lake; to mix metaphors). That said, it's also a standards-supporting tool now as well.
It's not been as clear of an arms race because AWS and GCP didn't invest in it in a similar way and it mostly impacted what are often called "dark matter" teams (Microsoft shops doing "boring" stuff that rarely makes HN headlines), but I have worked in teams that absolutely favored Azure over AWS/GCP with one of the reasons being Application Insights was an easy install and powerful first-party supported tool rather than an extra third party vendor relationship like Grafana/Honeycomb/Dynatrace/etc.
Not sure what to imagine with this given I didn't use Azure at the time. Is this like the Windows XP style task menu?
Think Niri [0], but worse, embedded in a web browser tab, and without keyboard navigation.
Here's a somewhat ancient Stack Overflow screenshot I found: https://i.sstatic.net/yCseI.png
(I think that's from near the transition because it has full "windowing" controls of minimize/maximize/close buttons. I recall a period with only close buttons.)
All that blue space you could keep filling with more "blades" as you clicked on things until the entire page started scrolling horizontally to switch between "blades". Almost everything you could click opened in a new blade rather than in place in the existing blade. (Like having "Open in New Window" as your browser default.)
It was trying to merge the needs of a configurable Dashboard and a "multi-window experience". You could save collections of blades (a bit like Niri workspaces) as named Dashboards. Overall it was somewhere between overkill and underthought.
(Also someone reminded me that many "blades" still somewhat exist in the modern Portal, because, of course, Microsoft backwards compatibility. Some of the pages are just "maximized Blades" and you can accidentally unmaximize them and start horizontally scrolling into new blades.)
[0] https://github.com/YaLTeR/niri
azure likes to open new sections on the same tab / page as opposed to reloading or opening a new page / tab (overlays? modals? I'm lost on graphic terms)
depending on the resource you're accessing, you can get 5+ sections each with their own ui/ux on the same page/tab and it can be confusing to understand where you're at in your resources
if you're having trouble visualizing it, imagine an url where each new level is a different application with its own ui/ux and purpose all on the same webpage
Imagine OG Xbox menus, or the PS3/PSP menus.