During the onset of programming, the command-line interface (CLI) was the trendiest tool to use. The notion of directing output of one command into another using pipes- strikes satisfaction and awe into veteran and uninitiated programmers alike and I’m not here to say otherwise. The command-line is the coolest thing about *nix operating systems. Sorry, Windows fans after 10 years of Windows and 4 years with Cygwin, I just could not get the same feel that I get while using a Linux PC or a Macintosh. CLI truly is not for everyone.
Why is the CLI not for everyone? Simply because not everyone is wired the way programmers are. While I may prefer opening MySQL in iTerm, my colleagues prefer using MySQL Workbench with its fancy UI and horizontal scrollbars that allow for the all the columns in a table to be seen. If you’d asked me what I thought of this a few years back, I’d have quoted Bruce Lee “It is not a daily increase, but a daily decrease. Hack away at the inessentials.” But after publishing applications on a worldwide market such as the Google Play Store, one tends to realize that “inessential” is a very subjective term.
One of my applications that removes duplicate media on Android phones had a bare UI during its early versions. With the passage of time and improvement to the algorithms that were being used, the number of downloads increased albeit slightly. With more passage of time and a few grays in my hair (I’m still in my twenties, sarcasm is hard to convey in writing) and some work on the UI; the number of downloads pushed past half a million. What caused this sudden burst of downloads? An intuitive UI which painted the application as useful from the user’s perspective.
And why did the UI have this big an impact? I’m not Socrates but I’d venture a guess that humans are shallow creatures and like pretty things and also because we are big on “I do not really care how it works, but as long as it does I’m happy.” This is why you don’t see an LED screen in cars which read “Generating high voltage from the battery, generated high voltage. Igniting fuel-air mixture in the engine’s combustion chambers ignited the mixture. Your car has been turned on. Feel free to switch to the first gear and drive around.” when you press the ignition button. Instead you see the dashboard light up and the needle in the speedometer perform a 270-degree sweep and wiggle a little to indicate that it’s ready to burn some fuel. This is an excellent example for software engineers because the end users don’t really care about how the application works as long as it does. So, please don’t bore them with details and abstract away things they don’t need to or care to know.
Functionality in UI
Transitioning from a software engineer to a product engineer is hard work. It takes time and effort to move away from prompting for values on CLI to having a textbox with the hint “Enter the number of rasagullas you would like to purchase” (I would not recommend using such a long hint). If you’re developing for a brand new ecosystem stick to the existing design guidelines so that users do not feel lost and once you think you’ve achieved Senpai status you may do as you please. Another tip would be to not develop anything from scratch, make sure nothing similar already exists before you put on your code goggles. If you find something close enough, just edit that and as Aleph One says “Read the source, d00d.”
