We use Azure DevOps extensively at my work and, after having used GitHub, Gitlab, self hosted solutions, Jenkins, TeamCity... DevOps ranks dead last.

It's the entire experience. The UI is terribly clunky everywhere. The worst for me are pull requests. Incredibly tough to work with people on a pull request. I can't even point you to "a" particular problem - for us it's broken everywhere. From the weird file comparison with overlays to the missing support for (us) important file formats like ipython notebooks. The way notifications bubble up in a facebook like format on a pull request. The emails that have 20000 lines and never the exact information I need. The amount of clicks to go from comparing two files to open the current version. Other people mentioned the lacking caching support for builds, so I am not going to go into more detail here. Another missing piece for me: Where are my statistics. I'd love to see commit, PR, response, comment etc statistics per team member / teams / groups.

Using Azure DevOps board is a nightmare of its own...

btw: most of these issues are part of the whole "azure" experience. The Azure portal suffers from the exact same interface issues of horizontally stacking fields. One wrong click and your last edits have disappeared into the ether

Same here. Azure has a killer feature in India that neither AWS or Google have - multiple data centres. Because of Indian data residency guidelines, that becomes critical for business continuity planning.

But the Azure UI is so bad that people are willing to forego stuff like that just to avoid being on Azure.

The Azure product teams have asked for feedback from startup multiple times with consistent answers on UI - I'm no longer willing to believe that this isn't the consequence of some global UI mandate to make things look "windows-y"

AWS has a full region based in Mumbai (ap-south-1) with multiple availability zones, each of which consists of multiple data centers.

umm.. yes we are all aware of this.

Its a single geographic region. Its not allowed according to financial or healthcare data regulations in India.

P.S. i personally am working with the "Big 4" consulting guys to get a white paper to work with this. But big missed opportunity for Azure. All because of bad UI.

This. Please please let there be a thorough accessibility makeover, and soon.

I have managed to forget the search terms I entered, but the first thing I have stumbled on, is this :

https://www.w3.org/TR/WCAG20-TECHS/SL15.html

Keyboard shortcuts across Silverlight applications.

I have no idea what became of Silverlight. But I liked it very much more when I understood Silverlight was the future.

(how anyone understood the tech road maps at the time Silverlight was introduced, I can't imagine)

I personally see the problem is that search engines are disinterested in the furtherance of any kind of consistency capable of reducing the utility of a layer of discovery that they can provide. If you explained to your senator, that whoever dominates the browser market, effectively controls how all the information contained in the www is displayed and arranged by publishers, and the standards bodies intent to introduce semantic markup and accessibility across the www potentially can eliminate the need for search engines for a variety of constituencies and professional workers, no less cutting spam most certainly in the process, maybe they'd see the inherent conflict to be as undesirable as I see it to be.

I keep thinking I need to at least spend a while considering how possibly a browser might technically introduce undo / redo for arbitrary websites. This is what I would be trying to accomplish, if I held the necessary influence with the Edge team. Even the ability to be informed whatever it is that I just did to the page, would be enormously valuable to me and everyone I know. I'm going to risk thinking that since Microsoft are contributing to the chrome codebase, and the default supposition is surely that Microsoft wouldn't want any advancement of any features that have desktop equivalence, maybe a diplomatic possibility exists for introducing the semantics and accessibility consistency we desperately need, by a little sacrifice. I would love to be able to hit a key combination inside a Azure page, that thanks to the aforementioned accessibility standards, had a (possibly expanded) command line consistent equivalent and, permitting a little browser specific markup, could, with a single further stroke, break the interaction out of the browser and into powershell. It seems to be the aim for Microsoft to be the universal developer interface for all. This is entirely consistent with the same idea. The number of developers is only likely to be increasingly close to the whole user base of PCs, as voice and other interfaces develop. Get VSC for VB6 on Android and the job's done, in one short generation ...

I just manage cdn and domains with this interface, it is super annoying, slow and complicated, already. I don't want to know how it is with more complex stuff...

The API is probably your only chance..

One additional point... it would be GREAT if I could have a chat channel in MS Teams with just notifications of @user/group where I am a part of that user/group in VSTS. I get so many emails, I really can't/don't keep up with it. Generally, email for this type of thing sucks, and the email doesn't show the meat of what you need to see.

A dashboard interface for messages/notifications in VSTS would be helpful.

Aside, switching to a GraphQL type interface with something that updates your UI consistently would be nice. Some screens update fine, others just get lost/disconnected and you don't even know where you are at.

Overall, I haven't experienced the agent issues in TFA, but I've had plenty of other issues and continue to use the beast that I know. I do think the issue tracking is decent and the integration is as nice as other products I've tried imho. Sometimes simpler is easier though.

Windows Development MVP here.

I feel like I must shoulder some of the responsibility here for not being louder about these issues. But must say, I'm disappointed to hear you're "surprised" about the UX issues. I've been telling your folks the UX is dreadful (e.g. as far back as pre-launch) and kept hearing back "we know, we're fixing it". I'll start formalizing the feedback and push it through the pipes, stay tuned. I'm also local (Bellevue), would love to come in and try to pipeline our relatively simple oss .net/wpf/uwp app. I suspect it'll be an eye opener for the both of us.

Some examples:

* You can't build a pipeline with a git repo. that contains submodules

* Found it impossible to edit the PATH for some custom tooling

* The New Pipeline experience just doesn't make a lot of sense, new users clicking around will eventually end up at the wrong Docs.

Here's my experience with Microsoft.

I believe their feedback mechanisms are placebo, pacifiers for loud people. Microsoft pesters you to give feedback and works hard to ignore them. And then goes ahead with what they initially planned. At the end, they'll announce - "We had delivered what you wanted. Based on feedback..."

And then you start wondering if you're in the minority and other people are simply crazy until you see multiple complaints about the same things.

Their music app, Windows phone, Windows 10, Skype and Edge are where I experienced this. In all cases, user experience kept getting worse with each "IMPROVEMENT."

The only time Microsoft listens is when people ignore official feedback channels and there are massive outcries on many fronts. Even then, Microsoft often retreats only temporary.

Yes. Incidentally Connect used to be a placebo for us enterprise lot. This has been going on for a long time.

And I get told regularly by people who only use the Microsoft ecosystem that’s it is me who is the problem as well!? These people are just assuming the status quo is being punched in the dick all day.

And even worse when dealing with PlayReady. In the time i have been working with it, they have been switching between at least 4-5 different "Connect"-like portals for feedback and support. Each time dumping all the content from the previous that was no longer accessible.

I've never seen an answer on the weird social.microsoft site that had anything resembling a remotely usable technical response.

These large cut and paste answers with completely irrelevant instructions and a lot of begging for points. Totally useless and infuriating if you've spent a lot of time writing a good report.

Microsoft could further save money by building an answer bot.

It'll cost less, answer faster and wouldn't be any worse than the current outsourced indian community support staff.

I assumed that they already had, but that it wasn’t very good

Don't give them ideas...

Also the responses you get on Azure support tickets is 10 worse than the ones from Amazon support.

Yes amazon support is pretty amazing. They’ve walked me through fixing a VPC I screwed up. No complaints here.

I'm not in Redmond, but do send an email. I'm my HN name @microsoft.com. We should be able to sort out some of these issues for you. I'd like to hear more about the docs problem. But:

You should be able to recurse submodules in a pipeline. In the visual designer, select "Checkout Submodules" in the pipeline's get sources step. If you use YAML, set "submodules: true" or "submodules: recursive" in the checkout keyword.

You should also be able to specify environment variables (including PATH) with the env keyword. But do reach out and we can get to the bottom of this.

Hey, just one bit of feedback, I tried getting my github linked project to build late last year, but always failed to checkout sub modules.

The build log showed permission issues, and I did try workarounds suggested like changing the sub module URL and adding ssh keys as part of the checkout step, but in the end, my 8 hours allocated to “get vsts building” ended with this problem and I have not continued. The performance of builds was also poor.

It’s unfortunately burnt me enough that I’m just making an ec2 instance with teamcity.

I'm sorry that the product wasn't easier to use, and that it wasted so much of your time. For anyone else running into this, we do have docs up about how to access authenticated submodules: https://docs.microsoft.com/en-us/azure/devops/pipelines/repo... (that shows how to do it against another Azure Repos instance, but a variation will work for any Git provider with a PAT-style bearer token)

It is likely that this is a variant of the issue with secure files. Secure files require a song and dance around changing the default branch or committing directly to a default branch to trigger a build after setup of the secure file. Coming from CI systems like Travis and Circle, this is an extremely confusing approach that I hope they consider changing.

Yes, we rolled out some improvements to how we authorize secure files (and other resources such as variable groups, agent pools, service connections) that you use in a YAML file. First, we introduced a toggle on each of these resources to mark them as "authorized in all pipelines". For new resources that you create, this will be on by default. Second, when you queue a build in the new YAML editor under Pipelines hub, then you get the option to correct the resource authorization issue. More work needs to be done here so that we can give you the right experience while maintaining the security of protected resources, and all of that is planned over the next month or two. Thanks.

That sounds like a great improvement to the process!

To your path issue... most of my own pipelines do an `npm run STEP` and I use JS scripts mostly... this covers me in window, linux and macos for the most part with Node. ymmv here though. That's just my $.02 and it's been relatively easier doing it that way.

I kind of wish $bash (git for window's bash version) was available as a shell option as that might make things easier as well.

Another issue is searching is painful... "TFS" vs "VSTS" vs "Azure DevOps" and half the time, the results are dated.

The old UI was better, and forcing people to this weird pretty UI doesn't make sense.

Several products aimed at tech people seem to make this mistake. We are power users, we don't want stuff hidden away. Stop having UX that's designed as if we were trying to browse twitter.

This is spot on, I've been using tfso or devops, brand of the month. I hate the New UI, its really clear that the people are focus on making something that doesn't need to be pretty, pretty at the expense of functionality.

For example, when you go to do a release and you of course want to do release notes, previously you could copy and paste the related issues output into any document.

Now its been CSSified to be big, bubbly, and utterly useless to do anything but look at, and there is no print or export feature.

Looking right at you, JIRA.

If you wouldn't hide certain things within JIRA you would go completely bonkers. JIRA allows you to fully customize the interface regardless.

I also liked the old UI far better. I have trouble finding things and navigating to where I want to go in the new UI. In the old UI it was easier to get an overview and to see where I have to click.

The new UI was useful when it was opt-in and we were migrating from on-prem TFS to what was then called VSTS. It made it easy to tell which system you were using.

I'm more used to the old UI but some features are not easily discoverable. I wrote some posts on how to build branches and pull requests as it's not obvious: https://unop.uk/build-and-release-all-pull-request-merge-res...

> We've been investing heavily in our user experience and our CI/CD experience

I'm on the "new" UI and I'm not seeing it. You've just re-skinned the same buggy and broken cruft that was there before.

It reminds me of the Visual Studio 2019 blog posts about new icons, themes, and fonts as their big new features while ignoring the massive performance problems people have been asking about for years.

DevOps with or without the new branding/UI is the same poorly designed product that doesn't know what it wants to be and is super un-polished. It would be better if you made it really good for one specific user scenario rather than poor for dozens.

I don't think that's a lie. They have certainly invested heavily in changing the experience --- but unfortunately, and like many other products seem to be these days, just not in the way that you want.

(It's not just you. The "why did they spend all that effort to change things that didn't need to be changed" question has come up for me countless times upon seeing redesigns of other products.)

Generally the whole area gets a continuous stream of small and big features. You can click through the release notes [1] and see the changes they've made. Over the past twelve or so months they've jettisoned XAML-based builds and added YAML builds.

As someone who's used it through VSO/VSTS/ADO days it's got foibles but yes, it's improving continuously.

[1] https://docs.microsoft.com/en-us/azure/devops/release-notes/

I kind of wish they'd promote whoever is the UX lead for MS teams to cover other products... it's by far my favorite windows app, second to VS Code.

Honestly, while your criticisms are mostly fair, your approach is really unprofessional here. Yes, Microsoft is a massive company, but human beings are making this and I’ll guarantee you none of them are happy with where the product is. Please consider showing some compassion.

I’d also add that I use 2017 and 2019 daily, and build by build, I see massive improvements for performance.

I don't see anything at all unprofessional about that reply. It's critical, but it is not unprofessional imo.

The whole pipeline debacle is confusing. I recently did a demo at a Microsoft DevDays showing Microsoft hosted Ubuntu 16.04 agents in my build and then a self-hosted vsts-agent container (provided by Microsoft which still has the old name, why?) and part of the point was to show how slow not having caching is, even for a simple Python build pipeline. On top of that Microsoft has some odd pricing in that they limit your self hosted pipeline concurrency to 1 unless you pay them. That seems like a bad decision because most people would probably go through the effort of spinning some VMs natively in Azure which would increase overall OpEx. But instead, like the OP of the article, people will self-host on prem or in another/cheaper cloud. Microsoft gives no incentives to use native build agents (they are unreliable and slow) and almost force users to go self hosted but also charge for concurrency.

I've also had very odd issues where agent pools will have an idle worker but the pipeline will sit saying there are no agents, waiting. Eventually it goes, but... It's just a bad impression when you're showing it and it's not consistent.

Also, the UI. Tis horrible. Take a nod from AWS guys and get rid of the widgety attempt at entertaining some exec who doesn't use Azure. AWS interfaces load consistently for the most part and do a much better job in being not annoying, comparatively.

Another bad user experience is if you write a pipeline, by hand, without the GUI and try to run your pipeline - well, good luck. Authorization for certain components of your pipeline will fail, even if they follow the pipeline documentation to the T. Why? Because the pipeline web GUI workflow does linking of authorization between components on first run and if you only kick your build off using, say a code check-in, the pipeline will just fail. And it will give you a non-descript authorization error until you pull all your hair out and randomly do a commit from the Repository GUI of which it will pop up a message asking you to authorize the thing that had been failing for the last hour. Either document this better or give users a descript error of the actual problem. This, again, is oft where I find Azure lacking.

I am from the engineering team in Azure Pipelines. We agree that the resource authorization experience needs improvement. We have been working on it. We would like to make sure that you can only include the reference to a resource (secure file, service connection, variable group, agent pool, etc) in your YAML file if you have permissions to access that resource. And, it becomes particularly hard to auto-validate this if you are pushing your YAML change directly to GitHub or another repository since we do not understand the identity of that user. If we are not sure, then the build fails with a resource auth error. You can do two things to rectify this - (a) with a recent change we rolled out, you can allow all pipelines to use a resource. This is a toggle that you will see on the resource (b) You can get someone with permissions to open the pipeline in the Pipelines hub of Azure Pipelines, and queue a build. You will get an option to correct the resource auth problem. We also made a recent change so that new resources that you create default to "usable in all pipelines". We are taking steps to improve this experience without compromising on the security of these resources for those that need that capability. More is planned in this area over the next couple of months. Thanks for understanding. I will also update the docs on this topic with all the updates that have been rolled out this week.

Thank you for the great explanation on changes you've made and will continue to make in this area! What is the best way to inform persons such as yourself about UX issues? Appreciate the thoughtful response.

I work on the UX side and you can email me at firstname.lastname @ microsoft.com (it's my username and in my profile).

Azure Devops is something I want to love.

The UI keeps changing, but doesn't fix underlying bugs that have been around for ages.

Multiple issues where the builds don't actually update in the browser when they go through the steps (f5 only fixes), the builds show out of order in the UI, and many many other wonky things.

Also releases aren't YAML yet. Builds are, and are a good feature.

Azure Devops is almost perfect, and with a bit of TLC would be excellent.

@thejosh I'm a PM on Azure Pipelines and I'm interested to hear the builds UI ordering and other wonkiness feedback if you want to share. You can email me at my firstname.lastname at microsoft.com and we can do whatever works from there.

YAML build definitions are not supported for GitHub Enterprise, which is mystifying to me seeing as how they are supported for GitHub. This is a critical missing feature for us and will leave us having to manually create huge JSON blobs for submission to the API.

@nathanaldensr, I'm an engineer on Azure DevOps. We rolled out support for YAML build with GitHub Enterprise this month.

The user experience leaves so much to be desired. The tools are not well integrated, the UI is really slow, there’s no dashboard view of active pull requests, builds, releases, etc for my favorite repos. Build/Deploy times are insanely slow for .NET Core micro service projects. We have a project with 4000 unit tests (not integration tests) and it takes over 7 minutes to do a full build + code coverage. The same operations locally take a fraction of the time.

I dunno if you guys have gotten feedback on this, but the difference between build artifacts, artifact feeds, and the output of some pipelines' tasks in terms of artifacts is really confusing.

I know it's probably getting translated to yaml from the old way which was a bunch of forms with build options, but we had some trouble with this. At the time, yaml releases were also still in development/preview mode.

One thing I'm going to miss is being able to discover things through the build wizard. Now it's just a blank yaml file and I feel that hurts the initial impression. I'd really like an option to build yaml files using the old way, but still get the yaml output for version control, that way I have all of the options and their potential values immediately available and I don't have to memorize and type everything.

There's a bunch I like about Azure DevOps though. Hopefully I haven't missed something really obvious.

Azure Pipelines PM here. Definitely hear you on the current YAML experience. We're working on updates to the editor now to allow you to quickly browse and insert task snippets. It's going to be a big improvement.

Funny I got an email from an Azure PM after I stopped using the free tier asking if I ran into problems. I explained my issue and what I gave up on, and.... never heard a response. I thought that was kind of weird, why even ask?

They ask the question, but any response is prohibited unless they cycle it through a pr department. It's about public narrative, and how it changes sentiment. So unless that response pays them, it's better to avoid saying anything than saying the wrong thing and pissing someone off, especially the wrong influencer.

(Former Azure DevOps PM here) That's not quite true - did you hear that from someone? When I was there, I had pretty much full freedom to talk with customers, as long as they hadn't opted out of contact. Never had to talk to PR or have emails looked at.

Sorry that you didn't hear back though :(

What does "opted out of contact" mean? I wonder if I am missing some communications because I unchecked some "don't send me spam" checkbox now!

I think there are likely a few places - i.e. the unsubscribe link (@Larrik), a button in the sign-up flow, and probably also somewhere in settings.

You should reach out to some PM's on Twitter! I know many are fairly active, and I'm sure would love suggestions or feedback.

That usually means the "unsubscribe" link at the bottom of your email. Clicking that is usually quite permanent.

There's a lot of comments about our UI and I thought I'd post a quick followup here instead of replying to each one individually. We are definitely reading these comments. UI itself is polarizing, and changing a UI moreso, but there's a lot of critical feedback here that we're going to investigate, try to understand and improve.

Really appreciate you engaging here - in addition I think there would be a lot of value in taking a closer look at the feedback that you're already getting on user voice, especially for issues that you think you've closed.

Great example here: https://visualstudio.uservoice.com/forums/330519-team-servic...

It looks like you did something that users didn't actually ask for in 2017, closed this, and then have been ignoring 1.5 years worth of comments being told what users actually want. From our end it's simple - the embedded burndown chart on the scrum board should be able to show story points, not just hours (like with any other scrum board tool). I shudder to think how many engineering hours went into solving the wrong thing here...

I've migrated my Boost builds from Travis and Appveyor to your CI offering recently. It wasn't super smooth, but I got it to work quite fast and I like it a lot.

So sure, I'm missing caching that I've had on Travis. But honestly, it builds reliably fast anyway. On Travis, I always needed to wait a LONG time to get macOS agents, on Appveyor, we were limited to 2 parallel builds. Here, everything starts all at once, completes under 10 minutes (there's quite a lot to build and test).

If I could, I would love to have an sccache ( https://github.com/mozilla/sccache ) compatible distributed free caching solution for my C++ projects. That'd be a killer feature!

You can add as many additional parallel builds as you want to AppVeyor for $50/m each - is Azure CI pricing comparable to AppVeyor with only two concurrent builds?

Last time I checked, the free offering was 2 CI builds in parallel on AppVeyor, which is just too low and slow for feedback on my project.

Also, considering I make exactly $0 per month from it, it's either be patient or use another service that had more capacity and faster builders.

I believe that Travis-CI had a higher limit for parallel jobs, but your builds would most often end up queued because of a low capacity for a certain type of agents. Also, something quite noticeable was their lower limits on build time, which is why for some builds a cache was necessary. It got a bit hairy when you needed a full successful build to properly populate the cache but they would never finish in time. And of course, the biggest drawback from Travis-CI back then was the lack of Windows support.

As for Azure CI, I believe there's something like a 10 parallel builds limit. And I've got exactly 10 configurations!

The old UX was not perfect, but I find that it worked better in so many ways. New UX does not seem finished, just pushed out in beta state. Like O365. Sad.

I’m considering migrating an appveyor setup to devops. The main driver is to get a pipeline setup with more parallelism and a more complex graph with resumable steps without fiddling with environment parameters, or really jumping around in a clunky ui maintaining a hundred “projects”

Haven’t looked to deeply what devops has to offer yet, but things I’d be looking for before migrating.

- I want to be able to develop, run and debug most, or all, of the steps in the graph on my development machine without roundtripping through long chains of triggers and pushing to code repos and pull requests

- I want to run as much as possible in parallel, preferably agnostic of wether it’s on the same machine or several

- I need to build and assemble many components from same repository (monorepo setup)

- only impacted components should build

- Sub-components may depend on different build tools (service fabric services with both webpack and msbuild based packages)

- Some steps may depend on configurations and secrets with a different lifecycle than the code branch being built

I imagine something clever could be built on docker to support both running things locally as well as customize build nodes.

I don’t care to much for scripting in yaml. In fact I spent the day converting some yaml (and cake) scripting to Invoke-Build. Invoke-Build is quite nice actually, the only thing I miss is the option to orchestrate tasks in parallel onto several build nodes. That plus something like ncrunch build/test engine for csharp projects

(really the entire vs/msbuild things needs to be replace with something truly distributed, incremental and repeatable)

I can recommend https://concourse-ci.org/ for pipelines that are difficult to reason about or orchestrate in, e.g. GitLab and other CI tools, due to external actors or lifecycles beyond a single codebase/repo.

Builds are 100% stateless within the CI cluster and rely on tracking/publishing just about anything you can imagine or plug as a resource; out-of-the-box inclusions being docker images (registry), S3 (e.g. minio, AWS) and git.

It's a bit strange to reason about in the beginning but I have yet to try anything that comes remotely close to Concourse when it comes to orchestrating across multiple sources of input/output and non-linear pipelines.

Awesome, looks almost exactly to what I imagined building.

Thanks!

I forgot to mention the semver resource which is a bit weird to use for a single repo pipeline but comes in handy for out-of-band jobs like running an external automation test suite asynchronously.

Why can I only choose github as my repository when creating a new devops project? It used to be possible to use vsts (git)

Sorry, I don't understand what you're seeing here - you're creating a new project in Azure DevOps? When you do this, you get the choice between Git (hosted in Azure Repos) or centralized version control (TFVC hosted in Azure Repos). We don't have an option to do anything with GitHub here.

So I think that I'm not understanding what you're creating, or where. Can you drop me an email with a screenshot? It's my HN username @microsoft.com. Thanks!

I will clarify. if you go to portal.azure.com --> Create a resource --> DevOps project --> Bring your own code --> In code repository you can choose between "GitHub" or "External Git". What I expected was that I could point it at VisualStudio.com - unless vsts has become the external git? ps: happy azure devops / azure user here ;)

Aha, through the Azure Portal. I'm not sure what that works that way. I'll look into it, thanks for the explanation.

One thing I can certainly agree with is the "no horizontal scrolling" beef.

I have a 4K laptop, evan on high res, the lack of horizontal scrolling in Azure portal and other Azure tools is a dailly irritant.

Stop trying to badly emulate Android phone look & feel ... for desktop usage !!!

We are professionals, we can handle scrollbars without screwing up.

I was pretty excited to see steadily improving GitHub integration. Unlike the others here, DevOps has been my most positive experience compared to a few others like Travis and AppVeyor.

However, this confidence was seriously undermined when I noticed recently that my GitHub pull request validation build stopped working when I closed the DevOps tab.

Yes, seriously. I have to keep the DevOps tab open for my builds to actually trigger. My mind boggles at how such a design could even be possible.

I'm an engineer on Azure DevOps. GitHub PR build triggers are based on notifications our service gets from GitHub (purely service to service), and is unrelated to any state of the UI. Can you reach out to me on email so we can investigate? Use my HK name at microsoft.com.

Often when I click Releases it is completly blank. All our releases are missing. I have to refresh 2-3 times before they show up.

The UI has so far changed five times in the past three months. It is insane. The current iteration is at least fine. Before it was a big blob of round circle that showed that the steps that succeeded succeeded. And then a big text saying it failed. It was worthless.

> We've been investing heavily in our user experience and our CI/CD experience, so I'm sad to see that we've disappointed here.

Maybe you should start investing smartly.

I can echo what the author of the blog says, save for private build instances, we haven’t had issues with them.

>though we're working on this now

beetlejuice,beetlejuice,BEETLEJUICE!

I spend a few hours recently in Pipelines and the whole UI is confusing. One of the offender being the edit button being literally at the other side of the screen. Outlook.com UI was also recently destroyed so it is hard to trust Microsoft services, even if good, will stay usable in the future.