Microsoft's Ability Summit has inspired me, again!

Microsoft's Ability Summit was last week, and it has, once again, inspired me to do more work on the tools I have in progress.

You can register via the above link to get to the official site, but the videos are also now available on YouTube.

It was inspiring to see the recently announced Accessibility Checker inside Visual Studio in action. It also showed me that it does have value. I had doubts about this as it's functionality that already exists elsewhere. 

This new tool allows you to run the same tests as can be run by Accessibility Insights, but from a button in the in-app (debug) toolbar (or Live Visual Tree window.)

I've got in the habit of using Accessibility Insights directly or via automated testing* to perform basic testing of an application.

* Yes, I have tests that run an app, navigate to each page, run accessibility tests against that page, and check for (& report) failures. It's not perfect, but it's much better/faster/reliable than doing it manually. 

It reminded me that I have code that can do much of this on source code.

Like this:

When the benefit of Visual Studio having an Integrated Accessibility Checker in the debug experience is that it makes issues easier for developers to see and fix because they don't have to go to another tool. And it makes them quicker and easier to fix by "shifting left" to be part of the debugging experience; how much better to shift further left to when the code is being written (before getting to the debugging step) and not putting the functionality behind another tool that must be known about and run but putting the information where developers are already looking?

I really must hurry up and get this in a state that I can make it public.

It's not as complete as the other tooling as it can't catch quite as many issues, but I think there's value in catching (and fixing) even some issues earlier. 

"It's as pretty as I'm able to make it" - An excuse that shows an opportunity

When a developer gives a demo that shows code with a UI, they invariably make no effort to make it look in any way visually appealing or show any indication they've done anything more than put controls on the screen.

They'll also excuse their lack of effort on the basis that they don't have the skills, knowledge, or experience to do any better. Also, maybe with a subtle joke that designers are somehow lesser. :(

With a little effort, presenters could significantly distinguish themselves from "all" the others who don't put in any effort here.

It would also be a great opportunity for showing something that easily makes a basic UI look better than many do by default.

My cogs are whirring.....

Please help improve the extensibility experience in Visual Studio

 

Have you ever seen the above prompt (or something very like it) inside Visual Studio?

It's displayed when a solution is loaded that requires workloads or components that aren't currently installed.

Those requirements are specified inside a .vsconfig config file.

The idea is that VS will tell you if you haven't got the things the project owners/creators/maintainers have specified as necessary to work with a project installed.
You can then click on the "Install" text link, and it will install the things you are missing.

But what if you want to require (or recommend) that an extension is installed to work with the solution?

Well, then you're stuck. 

You're forced to include this in the documentation and hope that someone looks at them. Ideally when setting up their environment, or--more likely--when things aren't working as expected and they want to know why.

Obviously, this is far from ideal and can be a barrier (I think) to the creation of specific extensions to fill the gaps in individual projects. - I have had multiple discussions where custom extensions were ruled out because it is too difficult to get everyone working on the code base to install the extensions. We ended up with sub-standard solutions requiring documentation ad custom scripts. :(

Wouldn't it be great if the existing infrastructure for detecting missing components could be extended to detect missing extensions too?

Well, it's currently under consideration. Maybe you've got a moment to help highlight the need for this by giving the suggestion an upvote. 👍

Thank you, please. :)

Do you know what good code looks like?

It's a serious question!

If you don't know what good code looks like, how do you know what you're doing is good?

What if it's not good?

What constitutes as good?

These are important questions when creating reliable, maintainable, high-quality code. 

This applies to any code or programming language, but especially to XAML.

The above quote was from a member of the audience after one of the first times I gave a talk about rethinking XAML. I now use it as an audience prompt in current talks.

I've met very few people who work with XAML who have given serious thought to what good XAML looks like.

Most XAML files look the same. 

And they don't look great.

They're not easy to read.

They're not easy to understand.

I don't think the solution is abandoning XAML. (Especially as there's so much existing code that needs to be supported, maintained, improved, and enhanced)

I think the solution is to change the way we write XAML.

More on this to follow...

In the meantime, what do you think "good XAML" looks like?

Three thousand .NET MAUI Developers can't be wrong!

 

Well, it's a milestone of sorts and, as such, is something worth celebrating.

Beyond this post, I've also just released an update that fixes a bug preventing the creation of apps with spaces in their name.

If you don't know what any of this is, the MAUI App Accelerator is a Visual Studio (for Windows) extension that provides a wizard to quickly scaffold a new .NET MAUI application by selecting from a number of options, pages, and features to include in a generated app.

Get it from the marketplace or provide feedback or suggestions on GitHub.