(… and you should think about adding one to your next Powershell script.)
The Console Window
I know quite a few admins who don’t like GUIs, for some reason or another. Linux admins especially, they are the high priests of the console cult. I’m quite sure some of them really believe GUIs are evil somehow and not meant to be. I guess it has something to do with the fact that for quite some time GUI was a synonym for MS Windows. And they really hate that. :)
But even some of the Windows admins seem to think typing in a console gets you closer to the system somehow. Like buying organic vegetables, they may not be as pretty as the other ones, they may not even taste better, but what’s in it!
And let’s be honest, who of us hasn’t been secretly enjoying the admiring looks on the face of a user or -even better- a relative, when you type in some fast commands to the console window and the output is filling the black screen with lots of mysterious letters and numbers, telling everyone but the initiate that something really important is going on here. And all you really did was pinging another computer.
I know, there are those of us who literally can type in a command with fifteen parameters faster than you can say “there’s an app for that”. Ok, you have to say it at least twice, but still. And sometimes, you simply have to use the console in order to do something. That’s fine.
Personally, I am not such a big fan. It may have something to do with all the valuable hours of my lifetime I spent trying to figure out the right syntax of complex commands and deciphering cryptic error messages, while calling the computer names i won’t repeat here. You know what I am talking about.
But still, sometimes I do like it. If it works, it makes you feel more in control somehow. It’s more satisfying than just clicking buttons. I think it’s the same effect as building something around the house by yourself instead of hiring a craftsman. You may not like the process, but when you’re done, man are you proud!
And if you grew up in the early 80s like me, it sometimes makes you remember the time when all computer screens looked like today’s console window. Back then, a computer was a window to a fascinating new world and typing “dir” into one of these things made your feel like a really cool hacker.
Users and the Console
But let me tell you, your average user doesn’t share that view of a console window. In fact, most of them react quite allergic to it. Personally, I think the same reason that makes them look up to you when you use it (even if they don’t show it, trust me, they do), is what annoys -or even frightens- them a little when they encounter one alone: they simply don’t understand what’s going on there.
A few years ago I was responsible for the user experience in a very large Terminal Server environment. At some point I moved some functions from the logon script to another tool (which would run later in the logon process), in order to cut login times. Part of this change was that error messages from these functions would now be displayed as a pop-up, rather than in the logon script console window as before.
The next morning, there was an unusual high amount of calls at the hotline about logon error messages. When I checked the logon logs of these users, I found out that all of them have had these errors for quite some time.
So, although they had to close the console window manually every day because of this error, they obviously never bothered to read the actual text of the message or even felt the need to do something about it.
They simply ignored it. Until the day it was displayed in a pop-up.
That day I learned that Douglas Adams’ SEP-Field really exists.
It also made me think about which messages (of whatever nature) an end user really needs to see in the first place. Sometimes an error message can be much more of a nuisance than the error itself.
But I digress…
Scripts and GUIs
When it comes to scripting with Powershell (or other scripting languages) you have the choice to handle all input and output through the console or to add a GUI. Of course it depends on the script’s purpose. (For an example GUI written in PowerShell see PowerShell Code Manager)
But even for a script running silently in the background all the time, it can make sense to add a GUI and may it just be to conveniently checking logs or status messages. For such background workers, it can also be a good idea to at least add a tray icon and let the script communicate error- and success messages via a balloon tooltip (which counts as a GUI for me).
If your scripts will be used by other admins or e.g. hotline personnel, a GUI can make handling your script much easier for them. It can also ensure that the script will used the way you intended and problems or errors will be noticed and dealt with immediately. Any kind of output is usually much better readable and form fields and text boxes provide “comfort” functions like formatted text or cut, copy and paste.
All this usually results in considerably lower support and troubleshooting requirements, by the author: you.
The same is true for scripts that will be used by end users. Only that in this case the accessory becomes a necessity. I gave you an example on what a difference a GUI or even a different display of a message can make. This becomes even more an issue if your users need to use a script or a tool interactively. End users are used to handle GUIs. Text menus in console windows make them uneasy and insecure, which leads to more handling errors and sometimes even a general dissatisfaction with the provided solution.
User acceptance is an important, sometimes even vital factor for any provider of technical solutions, may it be a company that sells technical products or the IT department in an enterprise. Apple products are a very good example of that. You may like them or not, but they clearly proved that users even accept less freedom and functionality, if only what is there, is intuitive and easy to use. Everyone who provides technical solutions for end users can learn from that.
Decrease Support Requirements
The possibility to create scripts with a GUI can even open up new ways of decreasing support requirements for an IT environment, while at the same time increasing user satisfaction. In nearly every larger company there is a certain percentage of hotline calls, that require the support staff to always carry out the same (often simple) tasks: deleting some files, remapping a resource, kill a connection, whatever. If you can’t solve the underlying problem (handling error, software bug, design flaw) and you can’t automate the task, it needs to be done by a human.
But what if you give the user the opportunity to solve his problem by himself? A small script, with a simple and intuitive GUI on the user desktop can do the trick. Not only does it decrease the amount of hotline calls and therefore frees up time for more complex tasks, it also saves the user time he would have spent on the phone otherwise and gives him the satisfaction of being able to help himself.
Impress your Boss/Coworkers
It’s a sad fact, but good scripts seldom get the appreciation they deserve. You know what I’m talking about if you ever have worked hard on a script and in the process had to overcome various obstacles, found clever solutions for countless problems, included at least one Nobel-Prize worthy idea and then, when you finally presented this scripted piece of gold to your boss or coworkers, the only response you got was: “Mhm what? Oh yeah, neat.”
The reason for that is simple, most people who have never written a script themselves, can’t possibly judge the amount of work needed to get the job done. They have no idea if you just strung together a few simple commands or had to reinvent mathematics. Also, the problem with scripts is, often there isn’t much to see and if you see something, it usually doesn’t look very impressive.
It’s interesting what a difference a neat GUI can make in such cases. And while of course it shouldn’t be the only reason for adding a GUI to your script, it’s a nice side-effect.
It really is. Once you’ve understood the principle, the rest is a piece of cake. Most of the work you can even do in a WYSIWYG-Editor, like the free PrimalForms Community Edition.
This week, I will start a series of articles about how to use Windows Forms with Powershell, in order to create a nice GUI for a script. The goal is to help beginners get off to a good start, as well as provide a few tips and tricks for advanced scripters.
So, stay tuned…
Have a nice day, Denniver