My job at Veeam is the first time in my IT career working in a software company, and I’ve learned a ton of things about software development. Not as a developer myself, since I don’t have any code writing skill (I wouldn’t call my low scripting capabilities “coding”), but partecipating to internal discussions about development has been so far an interesting experience. One of the most fascinating things I’ve learned is UX (User Experience) development, in particular around the User Interface.
K.I.S.S.
Or, Keep It Stupid Simple. The KISS method is a design principle that states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided. I’ve always liked this approach, because after its development, a software needs to be used, and ease of use is a paramount characteristic a software should have, regardless how complex it is in the backend.
I can haz another button?
NO!
It happens so many times someone asks for a new button, a new option, a new checkbox, because “it would be useful to have it there instead of the registry key”. And yet most of the times, the answer is a NO.
Let’s forget for a moment about the lazyness of checking an option in the interface compared to just opening for few seconds the Windows Registry and do the same change. Any single change in a user interface (user is highlighted on purpose) should be carefully evaluated in terms of pros and cons, and the first rule, for what I’ve learned and I agree with, is to not overload the interface and make it more complex if not absolutely needed. Seems too restrictive? Well, if engineers would lead the UI design instead of UI experts, I’m pretty sure we would end up with something like this:
Pretty confusing, don’t you think? This is what could happen if people design interfaces for themselves instead of thinking about their final users: they would place every icon, button and little screen as “they” want, so the final result becomes an interface that pleases only its developers. But software is not made for its own developers, but for its users. It’s called USER interface after all, right? And users have totally different requirements.
Let me give you an example that fits perfectly: how to change the location of log files in a Veeam Backup & Replication installation. The default position is in C:\ProgramData\Veeam\Backup\ , and if you want to pick a different location or drive, there is a registry key that allows to change the folder:
HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\LogDirectory (STRING)
(by the way, this is documented in Veeam KB 1825). So, why this option is not available in the User Interface, but only in a Registry Key?
Think about this: how many times you change the logs location? Or do you change the location at all? The vast majority of users don’t ever change the location of logs, so for the vast majority of them, this would be a useless option in the interface, only there to make it more complex. And even for those few that need to do this change, the change happens usually once, not daily. So, except that single time, even for them the option in the interface will be useless.
For this reason, it makes perfect sense to hide this option from the interface, but make it available anyway in a different (and not intrusive) form. Probably is my linux background, but I’m not worried at all to have options in a configuration file (Windows Registry can be compared to a config file). It keeps the interface clean and easy to use, and it hides options that users don’t need in their daily activities, or that even more have dangerous outcomes if used without prior evaluation.
Keep it simple.
A viable option is to provide a powershell interface to change these less used options, so you can create a script that configure an environment with your standard layout.
the main goal is to keep away rarely used options from the interface. Then, any technology to surface them and automate their configuration is ok, powershell or other automation tool is ok in my opinion.
PS: you can run powershell against the registry, even from remote 😉
> PS: you can run powershell against the registry, even from remote 😉
yes, but a automation script should be functional AND beautiful and HKLM/This/That/those is not good to see and (sometime) less portable among versions, while an API should be stable thru the years 🙂
It’s not powershell or API, is just the will of a vendor to be consistent between releases. I can talk about Veeam, we had the same registry keys in the same position since the beginning.
In this case *NIX with its commented text configuration files is still far more better from a SysAdmin point of view.
A text file can be easily replicated, backed up, diff-ed and script-modified via sed or other tools.
Registry is powerful, but some times it lacks of simplicity.