-
-
Notifications
You must be signed in to change notification settings - Fork 144
User Experience Manifesto
Certain systemic problems plague terminal software today. I've tried to make the Clipboard Project solve a few of them. I've also tried to order these problems below in the order that you might encounter them.
Before making CB, I actually never knew terminal clipboards had existed before. I only found out the contrary due to several complainers complaining that CB wasn't a new thing. As it turns out, tools like xclip largely serve the same roles as CB.
The problem here is the perspective that many of these tools have. I'm going to go out on a limb and say the writers of these tools don't know their customers. xclip is named that way because it depends on X11 (which I cover more below) and therefore stands for "X11 clipboard." How is this a bad thing? Let's take a new users to the terminal. What might this user do to copy a file? They might type copy. This sounds reasonable enough, but it likely won't work. What about cut? cut is a real tool, but it doesn't do what you might expect. paste is the same. Why would this user ever type in xclip to copy a file? The user might know that GUIs commonly have a "clipboard" so maybe the user types in clipboard and suddenly they're done! CB is here to help. And if they were really lazy and only typed in cb, then CB is still here to help.
That's why CB is so discoverable. Other clipboards have bespoke names and were written for nerds, not humans.
This issue largely builds off of Discoverability. Let's say you used xclip to see what it does. As it turns out, if you enter xclip without anything else, then you get nothing in return. Worse, it appears to hang forever until you somehow find a way to stop it. Our new user is in trouble. Maybe they know to add --help or try man xclip to figure out what went wrong, but they also might not.
By the way, the reason xclip "did nothing" was because it only works with redirection.
Let's now look at CB. If you enter clipboard without anything else, you receive a helpful message telling you...
-
what went wrong. Most programs only get this far.
-
why it went wrong. Only a few clever programs like
rustccan do this. -
how you can fix it. This is basically black magic.
Best of all, this message is in FULL COLOR unless CB detects it should not use color (more on that below), in comparison to too many utilities that cling to black & white like it's still the 1950s.
This pales in comparison to most other terminal software I've used. Why can't this be done more often?
Even the help screen (you can access it with just -h, which STILL isn't supported everywhere) is extremely helpful. It shows examples of common commands, tells you the version of CB you're using, what exactly it does, and does so in FULL COLOR again with zero filler.
CB does not have any configuration. Note that I said "have," not "use." That's because CB cleverly picks up on certain settings that are present everywhere they're possibly used. One such setting is NO_COLOR. NO_COLOR is an unofficial standard to specify a global disabling of color output by software. If the NO_COLOR environment variable is defined, then programs should not display color. In CB's case, the user has to do nada to disable color because they already did so before with NO_COLOR.
Zero Config programs are too rare and they should become more common.
CB has what I want to call a "zero BS" status. To get started using CB, there is no BS install process, there is no BS compile process, there are zero BS dependencies (not even X11!), there is no BS setup process, there is no BS configuration process (thanks, Zero Config!), and, finally, there is no BS usage process. You can get started using what you might think you might have to do. In other words, I designed CB around your intuitions.
I've noticed that terminal software often lacks colorful output. In comparison, all of CB's text assets have color baked into them. The problem here is that color adds stimulation to your mind. You can use color to convey a message. For example, you could make errors red to emphasize how "error-like" they are. You could make a conformation message green to emphasize how successfully the task completed. Alternatively, you can highlight a solution in hot pink to make it stand out. How often do you see hot pink text on a black background. All of these examples CB uses to improve the user experience. And, of course, if you really don't need colors, you can always use NO_COLOR and CB's Zero Config feature to fix that.
Something I've seen is that some people think color should be disabled by default and only enabled by the user. I've also noticed that these people tend to be old white men yelling at clouds, so there's that.
CB is tiny. In fact, as of this writing, it's one single C++ file without any external dependencies. This C++ file is not obfuscated or compressed in any way. Instead, it simply makes clever use of Modern C++ features. One such feature it uses is the filesystem library. In fact, without the filesystem library, CB wouldn't exist as it does right now.
With this dead simple code comes dead simple compilation. To make CB "just work" everywhere, I use CMake, a cross-platform C/C++ build tool. The CMakeLists file (which defines all the rules CMake uses to work) is also tiny like the C++ itself. That makes for a quick and easy compilation process that anybody can do in a few lines of code.
I'm shocked at how poor the UX is with a lot of open-source software. Paid, proprietary software that I've used generally has a better UX due to it having resources to employ dedicated UX designers. However, I've essentially replicated that same experience in something that's 100% free and open-source. Why can't this happen more often?