This is a bit wordy for a comic, but it’s pretty much a verbatim recap of a conversation I had with a friend who really could fix everything from a broken piece of software to a broken purse strap.
If you ask me, one of the reasons there aren’t as many women in engineering as there should be is fear of breaking stuff.
This is my “not rocket science” manifesto of GUI design. A programmer with no formal design training can go pretty far just by making a good-faith effort to adhere to these principles:
1) Reliability – There should be nothing on the GUI that will be fixed later or is a stubby placeholder for tomorrow. It all just has to work.
2) Simplicity – The beauty of the machine is that it can take complex data and hand it back to a human in a form the human can understand. Information visualization is powerful stuff. Harness that power.
3) Responsiveness – Tell the user what is going on. Tell the user why there’s a long pause. And for heaven’s sake, assume there will be errors when running external scripts and calling external processes. Plan for that and report the errors with as much transparency as possible.
4) Willingness to do the tedious stuff – The computer should make the decisions on the boring stuff (naming conventions, file locations) and the human should make the decisions on the interesting stuff (simulation parameters, creative choices). It’s amazing how many programmers get this 100% backwards.
5) Labels. Don’t assume that a user is going to magically know what that slider does. A tooltip is nice, but a label is often nicer.
6) Clean source code – Without a clean, modular design that makes maintenance programming easy, GUIs become quickly become unreliable, complex, unresponsive, unhelpful, and unclear.
I do think there’s a moral imperative to good design. We make an implicit contract with the user, and we need to do everything we can to avoid breaking it.
Straight out of the mouth of an engineer’s wife. I really have nothing to add.
Playing around with the idea of synergy between mind and machine.
This was supposed to be a riff on spaghetti code, nothing more. It wasn’t until I was mostly finished that it occured to me that I’d just drawn the Flying Spaghetti Monster – and perhaps made a statement about the consequences of worshipping the machine.
I’ve spent most of my professional life as a software engineer, and software engineering has definitely changed my personality. Much of it has informed my other pursuits in amazingly positive ways, but some of it has the potential to be a trap.
Helpful Geek Traits:
- The ability to divide and conquer seemingly monolithic projects.
- Agile cycle of sensible iterations and constant refactoring.
- Being detail-oriented and schedule-oriented.
- Being self-troubleshooting and able to write my own tools.
- Empathy (yes, empathy) – being able to approach a domain on its own terms rather than trying to impose my own framework in some Procrustian fit.
- Understanding the value of simplicity – “When you figure out what you want to say, you don’t have to put a lot of marks on the page.” This is as true in class design as it is in life drawing.
- Recognizing that the coupled traits of persistence and honesty are far more important than any God-given talent.
Unhelpful Geek Traits:
- Panic mode of constant firefighting. Aggressively looking for things to go wrong. Paranoia.
- Excessive nitpicking over edge cases and other things that are important in programming but irrelevent in real life, like a missing semicolon. It’s like fixating on a speck of dirt in the grout between kitchen tiles.
- Being lord of my own little domain and fearing to venture outside my comfort zone. I never, ever thought this would apply to me, but now that I have finally aquired depth as a developer, it’s surprisingly difficult to tackle new disciplines at which I have zero experience – surprisingly difficult to risk falling flat on my face.
Both helpful and unhelpful:
- Geek stubbornness – chasing after a bug till you squash it, damn it. This is usually a good trait, but it’s sometimes gotten me locked in cubbyholes and fixated on the wrong thing. There are times when it’s important to abandon a side battle in order to focus on the war.
- Unrealistic assessment of difficulty and risk. I don’t think I pursue difficulty for its own sake, or create complexity for the sake of creating complexity, but I do almost always tackle bigger projects bigger than I’m capable of at the time. This is because ANY programming project looks intimidating and impossible until you jump in. So I’ve become immune to fear, in a certain sense, and that’s not always a good thing.
I doodled these funhouse mirrors while corresponding with a friend about empathy, computers, and design. The point I was trying to make was that we create computers in our own image because we have no other choice, but it’s a distorted reflection rather than a clean one because our metaphors tend to be colorful rather than precise.
Many of the organizing principles of computer science are metaphors that we’ve long forgotten are metaphors. For fun, I started making a list that quickly turned into a series of lists.
Expressive, colorful computer science metaphors:
- edge case/corner case
- brute force
Expressive with the side effect of adding extra meaning (we need to give it a name in order to talk about it):
- red-black tree – Red and black have no intrinsic meaning, but assigning colors makes the concept easier to remember.
- upload/download – The direction is arbitrary, yet by now we’ve internalized it. By way of contrast, the Chinese words “shang” and “xia” for “up” and “down” also mean “previous” and “next.” This drives me crazy because to my Western mind, “up” should mean “next,” not “previous.” I assume that “up” means “previous” in Chinese because ancient calligraphers wrote from top to bottom, but I still have trouble wrapping my head around it.
- Alice, Bob, and Eve
- cyberspace – We think of virtual reality in terms of space and spatial dimensions because we need that anchor back to something we can understand – it’s just too abstract otherwise. Obviously, geography does have some meaning in cyberspace – the servers live somewhere physically, and so do the people – but I’m sure the reason people build such elaborate Second Life communities and environments is that we need that spatial grounding in order to make sense of an otherwise abstract virtual world.
- foo, bar, baz, fred, barney, and all the other standins of this nature – We go crazy if we can’t give it a name.
- parallel programming – Again, we automatically employ a spatial metaphor in order to facilitate understanding of abstract concepts.
Wordplay and puns and nonsense syllables with a poetic cadence:
- gnu’s not unix
Metaphor is dead because it’s become it’s own word and lost its connection back to the original thing (this is obviously subjective)
- World Wide Web
- Cold Fusion (my father the physicist never understood why anyone would name any product after a failed theory)
Colloquialisms invented to describe computer phenomenon
- blue screen of death
- spinning beach ball
I wonder if this is similar to how creole languages develop – we spontaneously “name” things. Hence creoles are full of words like “big teeth hit ’em and they sing out” for piano – it’s as if a pidgen becomes a creole the moment the vocabulary’s big enough to bootstrap itself into naming everything under the sun. So now BSOD has a name, and it will never be known as anything other than BSOD.
Roundtrip from daily life to computers and back again (influences both ways)
- avatar (from Hinduism to cyberpunk to message boards and finally over to James Cameron)
Personal roundtripping (I am probably the only one who thinks like this)
- checksum (did I manage to get all my bags from the airport?)
- ACK/NACK (yes, I heard you… but I don’t have an answer yet)
- zero-based counting in daily life
- writing == when any normal person woud use =