When I downloaded the newest version of NDepend, something wonderful awaited me. Was it support for the latest .NET Core version? The addition of checks for ubiquitous language for DDD projects? Any of the various rule additions or bug fixes?
Nope. I’m a lot more superficial than that, apparently. I saw this and was incredibly excited:
In case you’re scratching your head and wondering, “what?” instead of sharing my delight, I’ll be more explicit. NDepend added support for the Visual Studio dark theme. And I absolutely love it.
Asserting the Superiority of the Visual Studio Dark Theme
Why so excited? Well, as a connoisseur of the Visual Studio dark theme, this makes my experience with the tool just that much better.
Don’t get me wrong. I didn’t mind the interface up until this release, per se. I’ve happily used NDepend for years and never really thought about its color scheme. But this version is the equivalent of someone going into my house where I already like the bathroom and installing a radiant floor. I never knew I was missing it until I had it.
Everything in Visual Studio is better in the dark.
Oh, I know there’s evidence to the contrary. People are, apparently, 26% more accurate when reading dark text on a light background than vice-versa. And it’s easier to focus on and remember text in a light theme. I understand all of that. And I don’t care.
The dark theme is still better.
Going to the Dark Side as a Child
As a kid, I probably had no opinion on this. A child of the 90s, I casually used the Windows 3.1, 95 and 98 OS as a teenager. I recall these operating systems being generally bright, and any text editing that I did happened in the black-text-on-white background of Word and Notepad.
But then, in 1998, I went to college and everything changed. I went to the dark side.
Specifically, my CS program had us use principally C and C++, generally in a Linux and Unix environment. We logged in to program on servers using Telnet in dark terminals. We had dark text editors. I came to associate programming with light text on black backgrounds.
And I loved it back then, too.
As a procrastinating college student, I worked disproportionately at night. I worked from dingy computer labs and dimly lit dorm rooms. All around me was quiet, and the dark theme proved perfectly complementary to my environment and my mindset. And I won’t lie. It probably fed some subconscious delusion of myself as a master hacker or something.
Growing Up and Entering the Workforce: The Darkness Continues
It wasn’t hard to bring my preference along for the ride as I entered the professional workforce. I traded college computer labs and C/C++ for a bunker-like office and, well, also C/C++. That’s because I was working on Linux kernel modules and device drivers, meaning my preferred tools didn’t change by much. I used terminals, dark shell windows, and editors like XEmacs that had easy dark configuration options.
This entrenched an unshakable reality into my subconsciousness. Dark themes were the ambiance of programming and light themes the ambiance of casual users.
At some point, my work caused me to diversify a good bit with tool sets. I began to use Java and Eclipse, and also to support some legacy Windows applications, originally created using technologies like VB6 or even MS Access and its VBA.
These environments offended my sense of aesthetics. So I changed them. I’d go into the settings and painstakingly change the background color and then the foreground color. And if you’ve never done anything like this, in the “pre-theme” days of some editor, understand that this is a lot of work. When the tool supports syntax highlighting, this means going through every imaginable kind of language token or keyword and making sure that you change its color to one that a black background doesn’t hide.
Bringing the Preference for Darkness to Visual Studio
I didn’t make my way over to the .NET world until several years into my career. By then, I was a hopeless dark theme convert.
However, to use the term “theme” was a bit of a misnomer. I started with Visual Studio 2005 and 2008, which meant that themes were pretty DIY. In these versions of the IDE, I had to use the aforementioned process of changing all of the individual syntax coloring settings.
Mercifully, these versions supported saving your settings to a file. So I could do this once and then port it around to different machines if need be. And I remember doing exactly that—storing my settings files somewhere safe and accessible so that my dark-colored IDE was only a few clicks away.
Then, Visual Studio 2012 came out, completely reaffirming my life choices. That was the first version of Visual Studio that gave me a dark theme right out of the box. Sure, it was a little different—a slightly lighter hue than #000 and somewhat more muted text colors. It was an adjustment, but one that I quickly made for the sake of ease.
Was Visual Studio then (and NDepend now) reaffirming my life choices? I’ll just go ahead and interpret it that way.
Do I Really Think the Visual Studio Dark Theme is Objectively Superior?
I say all of this with my tongue planted somewhat in cheek of course. Oh, don’t get me wrong. I’m an avid user of the dark theme and dark IDEs and apps in general. I even have a browser plugin that inverts colors to make things darker.
But would I say that the theme is objectively better? Of course not. I’m not one to argue with empirical evidence. In fact, I’m somewhat of an empirical evidence enthusiast. If I switched themes and powered through the headaches from prolonged staring at white screens, I imagine that I might focus 26% better or whatever.
I also recognize that a concern like this is almost entirely about subjective preference. In fact, in the end, that’s kind of my point as to the deeper significance of this NDepend release (and the earlier VS2012 one).
Delighting Users, Whatever Their Preference
There’s empirical evidence out there to suggest that, in many contexts, using a light theme is better. So as a tool provider, you could tout this evidence and attempt to convert, convince, and even scold your users as to the right way of doing things. This is the sentiment evoked by Henry Ford’s apocryphal “faster horse” quote and later championed by Apple. And you might get away with that, given the right combination of cachet and situational leverage.
But that’s risky and it’s a tough slog. Instead, I’d recommend listening to your users and finding a way to get them what makes them happy, whether you agree with them entirely or not. This applies to user experiences with user interfaces, but it also applies to APIs as well. When it doesn’t harm an underlying concern, find a way to get your users what they want.
Because at the end of the day, randomly delighting your users creates converts for life in a way that attempts to persuade or convert them never will.