I often have thoughts that I have interesting, and I say to myself "Chad, you should write some articles explaining your thoughts and put them up on your web site." But I don't ever really want to go through the whole process of writing a complete document, so my thoughts stay in my head. So to keep myself from forgetting and potentially motivate myself to write (at least when my RSI cools off a little), I'll give two "teasers" here.

I've got an idea for a paper floating around in my head called "HCI is not Just for Grandma." The focus of that paper would be dispelling myths regarding interface design. It seems to me that a lot of programmers disregard interface design, because the software isn't designed to be easy to use. Well, I propose that making good interfaces isn't as expensive or difficult as commonly thought (as long as the proper design principles and attitudes are understood) and that good interfaces help technical or educated users just as much as anyone else. For example, picture this conversation (which was probably on Slashdot at one point) from the KDE 1.0 era, when we didn't have all kinds of awesome Linux GUIs:

  • RandomGuy: Why is burning a CD from the command line in Linux so hard?
  • LinuxFanatic: Idiot! It's really simple! Just type "mkisofs -J -R -V volumeid mydirectory | cdrecord speed=4 dev=1,0,0 -" So simple!
  • RandomGuy: Simple?! How am I supposed to remember that?
Well, RandomGuy could very well have a Ph.D. in physics, but he is trying to focus on the task at hand, that is, burning a CD or three, and he doesn't care to learn about the internals of the operation... why won't the computer just do what he wants? LinuxFanatic might percieve RandomGuy as not being very intelligent, when, in reality, he is. There are a lot of intelligent people in the world, but everybody has their own area of expertise. (Imagine if RandomGuy said "HAHA u don't know the first law of thermodynamics? such a lus3r." in return.) As software developers, we almost have a duty to read a little bit about human psychology and human-centered design, because understanding how humans interact with systems can make the difference between usable software and confusing software. Perhaps a user-oriented design philosophy even applies to programming languages. (Although I doubt psychologists do that much research on mathematicians.) Steven Knight, the main SCons guy, pays a lot of attention to users, perhaps without even being conscious of this. When a new feature is being designed or integrated, he asks, "How would a user see this feature? Can we make it even easier and more obvious?" About the specifics of CD burning... I'd just like to note that it was just an example, but some of the myths above still pervade the open source "community", for several kinds of software. I used to do all of my burning at the command line directly using the mkisofs and cdrecord commands. Every time I wanted to burn a CD, I had to remember or look up all of the command options and double-check that the burn worked correctly. Once I realized that there was a better way, I wrote a shell script to make burning so much easier. It has two modes of operation: "burn <file.iso>" and "burn <directory> <volumelabel>". It's totally awesome! This script has saved me a ton of mental effort and even prevented the possibility for errors. Every time I think "I should add some more options to that...", I try hard to see what the net gain would be: would the script become harder to use? Would I have more "magic options" to remember? It's a tough call, and these kind of design decisions plague the developers of desktop utilities every day. I highly recommend reading The Design of Everyday Things by Donald Norman as an introduction to human-centered design. It really opens your eyes to your interactions with the world around you. Wow. Once the words start flowing, it doesn't take long to describe the whole idea. Perhaps I'll just flesh the above out a little and call it done. :) Now my roommates are awake and it's harder to stay as focused on thinking and writing...

I'd also like to write a paper targetted at the VRAC called "Environmental variables considered harmful." I've mentioned the idea to a few people, and they all seem skeptical. But perhaps my ideas about changes to the typical project structure at the VRAC would save development time, especially for new developers. It would also enable better 'project packaging' when (if) we're finally done with them.

Another recent thought goes like this: Common computers are becoming increasingly parallel. Dual-processor workstations are everywhere, servers often have a multitude of CPUs, and I've heard rumors that the PlayStation 3 will be designed even MORE than the PlayStation 2 for parallel computation. If you link this trend with the fact that strict functional programming languages parallelize very easily, perhaps the next "paradigm shift" is simply using Haskell, ML, or CLEAN to efficiently develop software for the next generation of computing systems. This idea really appeals to me. When I look at Java, and to a lesser extent C#, I see a step backwards in compiler and runtime design. Shouldn't new computing environments get FASTER as well as easier to use? OCAML (a derivative of ML) supposedly performs as well or better than C++, and is much safer. Why can't we have a functional programming language as easy to use as Python, but as fast as C++? (I've actually got a friend who has been trying to build such a thing for years. But I think it has to evolve as a natural progression from other events in computing.) I'm excited for the future, even though I know it will bring more PHPs and Javas... but it's all worth it if a fast Python comes along for the ride.

If anyone got this far, I'm impressed. :)