UX Issues In Open-Source Software Are Not Bugs But Features
One of the longest uphill battles in the open-source software community is the struggle between engineering and artistry. One need look no further than user experience in design to see endless examples of this.
Something to keep in mind before continuing: User Experience (UX) is not simply limited to graphical User Interfaces (UI), but extends far beyond that to any experience any user may have with a particular system.
When dealing with computer programming, the first aspect that is always looked at is code structural design from an engineering perspective. This boils down to things such as the logical structure of the internal bits of code, how that code is formatted and organized, and how that code will interactive with other pieces of code. Schools teach data structures (how information is stored in RAM while working on it, and stored on disc) as well as algorithms (the code that processes the data). These together make up the foundation of the "Computer Science" (CS) field of study.
What is missing from this discussion and from an educational point of view is how users will interact with these things that are made. There are different types of users for different types of code being written. If you developing word processing or spreadsheet software, your end users will most likely be general business professional or students. If you are writing a web API, your users will be other web developers needing to interact with your service. If you're developing a SDK, then your users will be other developers interacting with your code in a much more intimate fashion. There are countless more examples, but keep in mind that "users" are not limited to simply general "end users" but also include other developers, engineers, architects, designers, and many more!
So where does UX fit into this? Simply put, knowing and understand what you are developing, and who you are developing it for. If you're creating a web based API, you probably don't need to explain to the developers interacting with your API what a web browser is. However, if you're creating a word processor, there is a high degree of possibility that your target users may never have used a desktop operating system before in their lives.
A little known operating system known as Microsoft Windows Chicago put this concept to a very interesting test. For those unaware, Chicago was the internal code name before it became known to the public as Windows 95, and encompassed the entire development of what we now know as the Start Bar and Start Menu from beginning to end. Prior to this, UX was comprised of a window-per-folder based navigation system that was difficult to get around.
How did Microsoft solve the issue of Windows 3.1 window-per-folder navigation, and how did they know their solution was better? They had focus groups of users who had never used a computer before, and gave them very simple basic tasks, tasks that you or I today would take for granted. One such task was to simply sit down at an already booted up computer, and launch Microsoft Word for the first time. For us, this is a two second operation, for those who had never touched a computer in their lives before? With no manual? No instructions? Google was several years away, and Yahoo! didn't exist yet either. Microsoft tested several variations of the Start Bar concept, including one that included three separate buttons where the now single Start Button resides. They iterated though designs and tested them with various user focus groups to see how they responded.
In the open-source world, this entire approach is absolutely missing. Instead, what is far too often the case, all that is seen is more of an engineering sheet comparing open-source to closed-source software. These lists are simply bullet points of features supports on either side. What is entirely missing from these bullet points is the ease of use for each of these features.
Imagine just for a second that you are absolutely brand new to computers and technology. Yes, these people still exist in the world today. Just imagine what it would be like to boot a computer, get into the operating system, and want to run an application. Now imagine that the program in question is only distributed in source code form that needs compiling. Now imagine that the compilation environment has a 100+ step process to setup and configure properly. And after that, it takes hours to compile the application. Then there is another 20+ step process simply to install and configure the application.
Yes, this is indeed what part of the open-source community believes is a great idea, due to the flexibility. However, it is missing the all too important on-boarding experience, one of the largest factors in UX for users of any type.
A strong notion in the open-source community is that if the feature checkmark is checked, that feature is complete, with no concern whatsoever to actually using it. As someone who thrives on attempting to create the best UX possible for users, I've personally butted heads with countless other open-source developers over this. I wish to share a few of those experiences here, and how easily they could have been resolved it users simply would have come first.
OPNsense IPv6 Configuration
I'm a huge supporter of trying to enable IPv6 everywhere on the open web. I personally use OPNsense based routers in a number of physical locations. These things have been great on small, cheap hardware, with the absolute fasted security patches out of any major open-source routing platform I've used to date. The OS is FreeBSD based with a custom web based configuration front-end.
In one particular place in the UI, there is a place to setup IPv6 subnet delegation from WAN to LAN. The WAN ISP may provide multiple IP address blocks for this purpose, mine giving me 256. Within the UI however, it lists the acceptable range as "zero through zero" which is entirely wrong on more than one front. This UX bug was reported, especially because at first I thought my ISP screwed up by not allocating the proper IPv6 address space to me. This issue was ignored at first by the developer, until others chimed in with the same issue. At that point, I fully investigated, uncovered the issue, and recommended a simple solution. Instead of fixing the issue at hand, the UI element was entirely removed, turning bad UX into no UX. This hurt because the other issue is that it defaults to "zero" as the value, and with my particular ISP, "zero" is actually an invalid value, they must start at "one"! Luckily I had this knowledge at this point, but other users don't, so they will be left with a non-functional setup.
FreeBSD GeoIP Package
The FreeBSD operating system has an amazing package system of open-source projects that are pre-compiled and very well supported. Well, most of the time anyways!
This week, I was playing with the idea of implementing GeoIP lookup for my web application with an OS package, rather than a PHP package. This seemed like it would be easier to install, configure, and maintain across a cluster. My base install script simply has a list of packages to install once the OS is ready to go.
The package for GeoIP lookup on the command line in FreeBSD also contains a shell script for downloading the GeoIP databases from Maxmind as well. This mostly works. There are three separate databases that this script can download, two of which are perfect. The third, however, downloads into the wrong file name, a name unsupported by the GeoIP command line tool from that very package.
I reported this issue on the FreeBSD bug tracker, however it was met with the usual "this is not a bug, but an intended feature" response. Their follow-up is to now include post-install instructions for the GeoIP package explaining that the file name is wrong and that the user is responsible for naming it properly. While not as extreme as the case listed above of an application requiring a 100+ step compilation process, this is of the same mentality. A pre-build binary package should be ready to go out of the box. If there is a conflict of interest as to what a file should be named upon download, this should be a user selectable choice either in configuration or by prompt, never forced into an unusable state as it currently does.
ESP8266 Microcontroller Watchdog Timeout Crash
The worst of all issue, a complete and total system crash and reboot. Surely this should be considered a bug?
The ESP8266 is a popular microcontroller similar to an Arduino / Atmel AVR ATmega, but with significantly more capabilities such as integrated Wi-Fi networking. I've personally been working with a whole array of configurations of this particular microcontroller for over a year, to the point of even designing my own PCB from scratch for it.
One of the main SDKs for the ESP8266 is based off of the Arduino toolkit and is hosted through GitHub. Checking the closed GitHub issues and forum posts all over the web, there are countless people that have run into the issue where the Watchdog on this board will timeout and force reboots the board. The Watchdog is an internal timer to ensure the board is still working, and if the timer expires (approx zero seconds), then it will issue a full power reset of the microcontroller internally. This timer is reset back to zero periodically in software, in my case approximately every 20 milliseconds.
In my particular case, I had spent the past entire year gathering evidence of when and how the microcontroller would reset from a watchdog timeout. This was tested on countless copies of the microcontroller from different manufacturing batches, all with several different power supplies and all of the other usual troubleshooting steps offered in the ESP8266 docs. Regardless of every single variable, the board would consistently have a Watchdog timeout reset every three minutes to three hours.
I had compiled a great deal of evidence and information on this particular issue and submitted the bug report. On this issue, the maintainer simply closed the issue on the spot noting that there was no definitive bug, regardless of the number of people in the past that have reported it as well with less information.
This issue, due to the number of people experiencing it, clearly is a very wide-spread issue. But instead of treating it like such and organizing all of the information to a single location, the maintainer is actively choosing to close all such mentions of it, ignoring the issue, and pushing it to the wayside.
These are just a few short examples, but I see this mentality every single day.
Developers are users of SDKs. Administrators are users of routers. Engineers are users of operating systems. In all three of these cases, the user experience is regarded as something that doesn't matter.
In the OPNsense example, presenting wrong information was deemed acceptable at first, and then no information was presented at all. This leaves users guessing at what these configuration fields are even for, needing to revert back to documentation that hopefully exists.
In the FreeBSD example, the shell script did something entirely unexpected and undesired. Rather than a simple fix, the maintainer believes that fixes are the user's responsibility. If the user misses this note at all, they're simply left with a non-functional peice of software.
In the ESP8266, the bug is entirely ignored because it is not yet known exactly what is causing the bug. Rather than setting up a bug triage to collate information each time someone has some new insights, all information is instantly dumped and ignored, leaving everything up to chance to see if someone is lucky enough to actually pin down the issue at hand.
I personally believe that many open-source developers should take a step back, and think about what the word "computer" even means. The entire task these machines are designed to perform is task automation and improved quality of live. When the task is instead left up to the user, both automation and quality of life have failed.
Thinking of how software impacts users should be considered even before thinking of data structures or algorithms. Sure, it may be syntactically correct and process the information efficiently, but is it an absolute pain in the ass to use!?
UX issues should be treated no different than any other bug. If a user cannot use your program because it is too complicated to get installed or started, is that honestly any different than your programming crashing? In either case, the system as a whole has failed, so the severity of the issue should be treated as such when a user cannot easily use said system.
I'll finish this up with a car analogy. User Experience is a lot like cars. Sure, a Ford Pinto and a Tesla Model S both have four tires, a wheel to steer them with, and pedals to move and brake. We can mark off the checkboxes for what qualifies something to be a car all day and night long. But one of these cars has one of the highest safety ratings in history due to design, the other absolutely failed and would burst into flames from a minor accident. Which experience would YOU rather have?