The Elusive Art of “De-Geekifying”
Boris is invincible!
Yes, yes, we all went through similar situations in high school where flying your geek flag was pretty much like taping a big juicy red target on your back and handing the rest of your graduating class paintball guns: it usually didn’t end well for us then.
But, the wheel turned and little geeks grew into bigger geeks and trotted off to college to study the science of geekery. They soon noticed that being a geek wasn’t a bad thing anymore, in fact it was even cool here.
You mean to tell me I can be as geeky and obscure as I’d like and everyone around me will actually understand and maybe even praise me for it? Do you have any idea how proud that made me?! So proud that I never bothered to notice how many normal people I’d alienated along the way trying to be as elitist as possible…
Sadly, the real world isn’t entirely made up of geeks. So, how do we geeks evolve and adapt to it? Skillfully, as always. By studying the algorithm to degeekify, of course 
(This comes from an interesting discussion lead by my friend Murphy & my professor Dr. P) Let’s take for example, the linux file system structure:
/sbin System binaries used by the sysadmin. (Oh yeah, they can also be in /usr/sbin so check there too!)
/bin System binaries used by the sysadmin or regular users that are super important. (Oh, also check out /usr/bin for the less important stuff. Oh and also /usr/local/bin. So yeah.)
/dev Device nodes (not program development space).
/etc Config stuff
/lib System files & libraries
/tmp Temporary files
/var Any kind of logs or temporary configuration files (not in /tmp?) . And web stuff. Wait, what?
True die hard linux fans will refer you to some kind of guru on the filesystem structure, who will angrily rant about how linux applications developers are idiots who have no idea where things are supposed to go; or sysadmins who put modules in the wrong places… HOW DARE THEY misinterpret this cryptic and ambiguous filesystem structure! C’mon, if even the linux applications developers (fellow geeks) can’t even figure out where things are supposed to go, there’s obviously a flaw in the design of the system (Way to go, gobo linux!)
Since we’re picking on Unix anyway (pretty much the governing body of the design of current operating systems), let’s go a bit further.
$ tar -xvf file.tar $ ... wait, you're done or you're just stuck? hello?
So when a command on the Unix commandline executes successfully…nothing happens! I mean, I guess you got no errors…no news is good news? Sure, we’re smart geeks and can used to this notion, but this is still an inherent flaw in the design of the system!
And really, how effective is a terminal where you have to refer to the documentation (manpage) every time you try to execute a command you haven’t used in a while? We need some coherent standards for arguments across linux applications!
Let’s go with another example, this time with less…flame war bait:
So, you’re a software engineer. You have to conduct user surveys of your target user group before beginning to design your software architecture to gauge what a good use of your development time might be. So, you ask exactly what you want to know:
- For the user selection panel, would you rather have a drop-down box or a Jtextfield you can enter your own data into? (Please specify if auto-complete would also help…)
Natural, right? You asked what you wanted to know. Exactly like calling a function: you pass (ask) exactly the correct parameters in the indicated order (questions) to extract your necessary information (survey data) from your data store (person). You even went as far as to suggest a helpful feature! (You’re so thoughtful ^-^ )
I’m sorry to have to be the one to tell you this…but (most) people aren’t functions. There is a fuzzy disconnect between what you want to know and what you really should want to know with user surveys. Normal people have no idea about their preference between two different technical components: they’ve never really thought about it before… and honestly, they really shouldn’t have to.
Geeks inherently worship the machine. User misunderstandings (PEBCAK…or PEBKAC… man that acronym needs a standard 
) are interpreted as a problem of a lack of user knowledge, not even considered to be a flaw in the design of the system.
Yes, computers are simply just tools. But too often we forget that computers aren’t just physical tools like a shovel; we can actually redesign the computer depending on our needs. Sadly, we are not good enough to completely redesign a human from the ground up, regardless of how angrily we complain about the stupidity of our users. The only thing left is to redesign the system…think of it as teaching the computer to evolve along with humanity.
Loading...
I’ve often thought about the differences between CLI and GUI. I think one of my favorite ways of thinking about it has been that of Recollection vs. Recognition.
http://www.advogato.org/article/100.html
The human brain is very good at recognition and can recognize an order of magnitude more information than it can recall. It’s not a bad idea to leverage that. On the other hand if you do something often enough you will memorize it and could have access to increased efficiency while it is memorized. Unfortunately when you take a break for a little while you tend to un-memorize it and need to brush up on it.
Most GUIs offer some form of recollection-based navigation through the use of accelerators (Ctrl+S), however I find that when presented with a GUI my brain tends to take the path of least resistance and uses the menus more often than not. So does presenting a recognition-based interface actually impede the efficiency of experienced users? In my experience not necessarily. Most power users of something like Adobe Photoshop will make extensive use of accelerators.
Matt Shanker - May 11, 2009 at 8:47 AM
“…wherein he spoke of the need to support disabled users. He’s quite right. We need to support them -…”
Is that a dig?
Recollection doesn’t necessarily need to be total rote memorization: there’s the suggestion that instead of barfing up a USAGE statement when someone enters a command with the wrong flags for input, instead prompt for each individual argument. Obviously, this slows down the process for expert users – and I’m sure you remember from principles of languages “localized cost”: where just because one feature was added to the system, the entire userbase shouldn’t have to take a performance hit.
Here’s my idea: An unintrusive (and obviously configurable), “eclipse-like” auto-completion for command arguments. Perhaps behind the scenes, it parses the manpage so it would in theory work with any new applications you write yourself. Maybe it only even enables after 1 second of inactivity or something, so expert users can go ahead and pound out the long string of memorized commands while still allowing for learning to occur.
Or even simpler, without a complex manpage parser: remap the commands and argument flags to be standardized on your system. For example, I can’t for the life of me ever remember the name of the little “minicom” terminal application: I always want to prefix it with “micro”…so I created an alias for “microcom” to map to “minicom”. Hacky and really just a bandaid: a localized solution to the overarching problem, but helpful nonetheless.
Anyway, as soon as we can get Recognition/Recollection implemented cohesively into the terminal, we’ve got the ideal solution.
Leah Shanker - May 12, 2009 at 9:50 AM