I think we can all agree that Spiderman’s Uncle Ben was right: “With great PowerShell comes great responsibility.” Okay, obviously I added the “shell” part. But it’s true. PowerShell is really, really powerful, and that can be too much responsibility for some people to want to go near.

A PowerShell graphical user interface (GUI) can help lower-XP PowerShell users interact more safely and confidently with PowerShell.

How a GUI Can Help

GUIs are great because they:

• Let users run PowerShell by themselves
• Provide a job-specific interface to enforce limited input
• Limit who can do what with PowerShell in that given situation
• Give “immediate visual feedback” (aka lets you know when you’ve forgotten a required form, for example)
• Are meant to be intuitive and easy to use for anyone
• Make inaccessible technology accessible (especially for Linux)

The best kind of GUI is one that’s built by a UX engineer using a desktop framework (e.g., WPF or Win Forms) and an IDE (e.g., Visual Studio). When I just started with PowerShell, a GUI like this would have prevented me from, say, importing an internal certificate to ALL our servers instead of just the test servers… But that’s a story for another day.

Truth is by the time you’re doing that, you’ll have built an application (which isn’t the point of PowerShell). I think you already know this (especially if you’ve read some of my other articles). So, what are your options for a very basic, middle-ground, “good enough” GUI for PowerShell?

Two “Options” for Building PowerShell GUIs with PowerShell

Writing a PowerShell GUI USING PowerShell is not a good idea, in my opinion, and experience. Let me show you how to do this anyway while explaining why it’s a land you don’t want to enter (trust me… I learned the hard way), and then I’ll explain a much more promising option.

1. Use WPF and XAML in PowerShell

You may be tempted to use WPF and PowerShell. This is possible, of course, because PowerShell is based on .NET. The problem with this method is that just because PowerShell can use .NET doesn’t mean it will work well with other .NET technologies.

The UX of a PowerShell desktop framework GUI will be rough because it won’t be built with an IDE. It will also be complex, difficult to read, and a write-once script. And more importantly, it will be so large that maintaining it will be a real slog.

If it’s a .NET-based GUI you’re looking for, using C# makes way more sense… which brings us back to “you’re actually building an application and don’t need PowerShell in this case.”

But let’s say you still want to give WPF and XAML at try. The steps involved in this process include:

• hand-crafting an XAML file to create a GUI
• combining your script and the PowerShell GUI by adding code to
  • import and read the XAML code of the form.
  • dynamically create variables assigned to each named control
  • display the form

To learn more, I recommend checking out the Adam the Automator blog. There is also a tool called PoshGUI that acts as a kind of “IDE,” but don’t confuse its capabilities with the IDE you’d get from Visual Studio.

2. Text-Based Menu

Let me start by heading off a likely question: Is a text-based menu even “graphical”?

There are good arguments to say yes and others that say no. But since it’s a possibility and people do use it, let’s consider this as a type of PowerShell GUI.

The general steps to building one of these:

• Using the Write-Host cmdlet to display choices to the console
• Use a combination of the Read-Host cmdlet and the ChoiceDescription Class to read text input and define the prompts someone can select from

Creating a text-based menu with PowerShell is significantly less complicated than using WPF, but it’s also not easy. Want to learn more? Adam the Automator for the win again.

Remember, the menu created with this method is very rudimentary (which is one reason why people say a text-based menu isn’t truly “Graphical”). There is a tool to create a “Terminal User Interface (TUI)” for PowerShell that makes your text-based menus more visually appealing. It’s not to my taste, though. If I’m using a text-based menu, it’s usually because it doesn’t matter if it doesn’t look very nice.

If I need a good PowerShell GUI, I far prefer running scripts with auto-generated UIs.

Running Scripts with Auto-generated UIs: The Better Option

Instead of trying to make an application out of a script, I prefer to use Otter to run scripts with auto-generated UIs. Otter can automatically generate a UI around your scripts. It does this in two ways:

1. Comment-based Help
2. Otter’s Job Template Feature

Otter lets you add comments and descriptions, which as I’ve stated before, is the key to near-perfect PowerShell scripts (definitely read this article if you need to learn how to do Comment-Based Help).

And by using job templates, you enable self-service. The next time anyone needs to run a job, even if they don’t have permission to run scripts, they can use the template, which will restrict inputs AND will remind you when you’ve forgotten to fill out required fields. (In an untemplated world, you’d have to bug your manager any time you needed to do this and wait around til they were free.)

Why It’s the Better Choice

It really boils down to two very simple but mighty reasons:

• GUIs are automatic – no extra time spent making a GUI by hand
• PowerShell scripts previously impossible for someone in, say, Accounting to run are now runnable because they’re in a simple GUI made-to-order by Otter

At the end of the day, you do less work and have a more useful UI.

Don’t Be Overpowered by PowerShell

PowerShell rules. It’s powerful as heck and can do lots of good things. But it is NOT the best choice for everything. Just like when you’re testing your scripts, not everything has to be a script or automated! 

I’ve told you why trying to write a PowerShell GUI in PowerShell is a bad idea—but since you can make up your own mind, I also showed you how to do two common methods. I’d suggest giving Otter a try to see how automated UIs work for you.

Democratizing PowerShell with GUIs is just one way you can help your team “level up”. For many more ways to give your PowerShell scripts and modules a boost, take a look at our free eBook, “Ultimate Powershell Levelup Guide”. Sign up for your copy today!