Pawprints of the Mind

Lately, I've been working on some new themes for gnome-terminal, because the tango palette is getting kind of stale for me. I guess that can happen, after four years or so. Dark themes are my favorite for late-night coding, so these will be the first ones showcased. Today, I present for your pleasure, BlackRock:





To recreate this theme, use the following custom colors for your terminal:

Text color	#BFB2AC	Background color	#0E0400
Black	#000000	Bold black	#55443D
Red	#B81500	Bold red	#FF7F6E
Green	#648F00	Bold green	#CCFF55
Yellow/brown	#786C29	Bold yellow	#FFDD47
Blue	#4B5C63	Bold blue	#84AFCF
Magenta	#9C0046	Bold magenta	#FF75B3
Cyan	#A66728	Bold cyan	#FFA54D
White	#BFA095	Bold white	#FCECE5

If anyone knows a way to conveniently package gnome-terminal themes, please let me know.

I've been doing it wrong, all this time.

I used to believe that I designed before coding, but I was just thinking about it in general. Thoughts have curious properties: we believe they're perfect and solid in our minds, yet we often struggle to express these perfect, beautiful things. And it's not just me. Ideas are actually fluffy, vague, and prone to being silently forgotten as you're trying to work on them.

I've tried writing things down in the past, but paper doesn't work for me for coding. It just takes too long to write down enough to be caught up with myself, and by then, I've forgotten where I was going with things. On the other hand, I've never been disciplined enough to design in a text editor without jumping into coding too soon.

This week, I started using a word processor as part of the process. It works much faster than writing text on paper, and it's a lot more flexible. I can copy/paste a huge block of code, or compile a rough execution-trace, and edit the result without worrying about damaging any real code or dirtying the diff. The text styles allow for coloring certain variables, or adding bold to a problematic region. Zooming out is also more elegant than shuffling paper.

The most surprising advantage is that it's faster to write the design than write the code, because the code is frequently split between libraries or functions, and there's a lot of effort spent in keeping track of where the code that needs changed is. Obviously (in retrospect, anyway) that conflicts with keeping the pending changes in mind. Since the document also survives distractions, it helps with keeping me focused, too.

I worried at first that being unable to draw would be a major hindrance, but for coding, it's a helpful constraint. Images are much closer to thoughts in their ability to seem complete, yet lack real detail. Condensing the requirements and plan of attack down into text provokes the study of those elusive details, and brings the important ones into sharp relief. With the vital parts marked in color or bold, it's much harder to gloss over that one little spot that would normally stop me only after getting most of the way through changing all the code to a broken design. It wouldn't work out so well for visual designs like nQn's new logo, but it's been great so far for coding.

This post applies to: Ubuntu 9.04 (Jaunty) with Linux kernel 2.6.28, Wacom Bamboo Pen, linuxwacom 0.8.5-10, and GIMP 2.6.

I worked from this HOWTO post on the forums, with the following changes:

1. As of yesterday, linuxwacom-0.8.5-10 is available on linuxwacom.sourceforge.net, so I used that code and no patches.
2. For some reason, the kernel directories in src/ stopped at 2.6.27. The wacom.ko driver in there Works For Me™ on Ubuntu's 2.6.28 kernel, but your mileage may vary.
3. I had to add a 'wacom' line to /etc/modules in order to actually load the driver at boot and make the tablet useful.

Once I had the pointer on-screen responding to the tablet, I fired up GIMP and discovered I had no pressure sensitivity. It took me a while to remember that GIMP does not enable the pen by default. To enable it:

1. Edit menu, Preferences item
2. "Input Devices" in the left pane (toward the bottom)
3. "Configure Extended Input Devices..." button, first one on the right.
4. Find your devices in the Device dropdown; mine is "Wacom Bamboo Pen 4x5 Pen0".
5. Set the Mode to Screen.

I always forget to turn the stupid thing on in GIMP because setting up a tablet is so rare. It might be nice to have a dialog along the lines of, "You have a new input device. You need to configure it in order to use it. [Configure][Close]".

I recently had the opportunity to drive an '09 Jetta S with a 6-speed automatic for a couple of days while my car was in the shop. One of the things Julie brought up was how it feels much more like a luxury car than my New Beetle or the Honda Fit we test-drove last year.

After playing with it a bit, I realized one major difference is in the gas pedal. The Fit was always ready to spring forward if I pushed the pedal any harder. Its demand for ultra-precise control made it feel like a fast-reacting sports car, just waiting to show off its reaction time to the next challenge. Sometimes I had to just think about moving my foot, and that would elicit a response without making Julie rock back and forth.

The Jetta is the Fit's antithesis. There's a bit of purposeful delay in the reaction, so that the changes in acceleration are very gentle. And that gives the car that "big luxury sedan" feel, by simulating the inertia of an actual 4,000 pound car. Even alternating between flooring it and releasing the pedal didn't make my passenger complain.

In 2008, I had an '09 Forester for a day as the loaner, and I panned it at the time: "They ruined the Forester." I've since come around to the styling, but I remember describing its ride as bland. I wonder now if it simply felt more like the Jetta than the Fit, and my taste has changed in the meantime.

It's why they walk so slowly; it seems like a normal pace to them.

It turns out that announcing something, such as the intention to write weekly, reduces the actual results. Aside from my recent demonstration, similar news flitted across reddit and/or news.yc within the past couple of months. I think. This post is a likely source, but the date is off for the 'social news' link-churning mills.

I wrote about time debt, swore to do better at time management, and dropped off the Internet, more or less. The irony of Anuj's comment on that post was not exactly lost on me.

In spite of my lack of activity here, I managed to add a piece to my slow-growing deviantART gallery: Fire Tulip.

I'd say a lot more, but I think there's only one thing left for me to add to the iPad discussion. Named the iPad and coming in at the CrunchPad's (now the JooJoo, if it actually ships) price point, but with the Apple app store: DIRECT HIT. 9999 DAMAGE!! +3 Awesome Points! And although I have no plans to get one, my lack of purchasing any other Apple product doesn't seem to be hurting them much.

Some people carry around an appointment book stuffed with events and activities with friends for practically the next year. In April, you may find them saying, "I only have three weekends free the rest of this year. Should we get together in June or October?" Others are likely to make plans for the weekend after work on Friday.

These appointments are basically time debt: promises to spend time later. The more you carry, the more debt service is required. A full six-month schedule practically demands the overhead and formality of the planner, unlike the spur-of-the-moment approach. Time debt can also be defaulted on, by cancelling the appointments.

I've always been on the lazy side. I carry little external time debt. There's a seemingly infinite amount of time I could spend on personal projects, but I also have a lot of ideas for them, and they are defaulted on frequently. Freshwall hasn't released; I got it "in shape" for what I want the engine to do, and I haven't gotten around to updating the GUI yet. Debian packaging? Ubuntu inclusion? Ha! I've been missing my goals for three months.

This suggests that I should be looking at investing time, rather than spending it. If I start a project, I should finish it before it dies, unborn, of neglect. If I keep living with such high time losses, I'm going to turn 40 and ask myself, "Why am I not like my heroes?" and the answer will still be: because they finished stuff.

(Then again, we haven't seen much on Rhino's Not Rails or ejacs recently, either, so maybe I'm not so different. Ejacs at least made it to google code, but hasn't seen activity in almost a year.)

I've been working on increasing both post frequency and quality here on Pawprints of the Mind. It was easy at first, as a natural consequence of trying to write something once a day. When that effort paused during the holidays, with nothing produced between December 22nd and January 3rd, I had nothing to write about on my blog. The only post published in that window was a touching up of an old draft.

It seems that daily writing is important to help me think, even if its only actual effect is to devote time to actual thinking instead of the internet or video games. (During my hiatus, I played an entire game of Secret of Mana.) I suspect it's more than that, though. If I don't know what to write about when I start, creating the opportunity generally makes something appear.

Perhaps this is how NaNoWriMo works. By establishing time for people to write, it helps them focus their efforts and allows the result to happen, instead of deferring it in favor of day-to-day living. It's important to allocate time and use it, because less work translates to less reward and more difficulty in trying to pick it up later. There's a need for breaks, but there's also a danger of spending too much time relearning it when returning to the project. There's a sweet spot between the two where unusual thoughts and angles flow more freely.

The quality of posting, I hope, is also going up as a result of trying to produce daily, but post only weekly. I have a lot more space to draft out my thoughts, which allows for more cutting of fluff and a deeper exploration of the chosen topic. Although it's no secret that I admire Steve Yegge's storytelling skills, I'd really like to focus on writing like Paul Graham: dense and flowing toward interesting.

So that's a behind-the-scenes look at sapphirepaw 2010. See you later this week!

Familiarity

The holy grail of usability is for the system to act, for each user, just like they would expect it to work. So people remarking on the "usability" of Gnome may complain about the icon and "Applications" menu being all part of one big menu title, because they're used to icons being distinct from text. Also, the menus have no outline to make explicit that both logo and text are one item.

But I'm not sure this menu thing is really a major problem. It surprised me once or twice, but not since. It's something you get used to with a little practice, sort of like the interface changes in a new version of Firefox. Is it less "usable" because you're familiar with a slightly different interface? You'd probably score slightly worse on a usability test, even though it has been "improved", until you get used to the new layout.

The major problems are in areas where users don't just get used to it. The Gimp toolboxes in Gnome have constantly gotten in my way, floating above the image, being un-minimizable, and other such nonsense. The other day I minimized one of two image windows and the toolboxes minimized with it. Convenient! I was just about to access them for the other image, actually.

Rant Mode: On

(A few minutes ago I found a condescending comment by someone about how the TAB key toggles visibility of all the toolboxes, and doesn't anyone read documentation? Obviously not, but being curious about this allegedly documented feature, I ran grep -i tab on the complete user manual. The only reference to the tab key's toolbox functionality is in the paragraph on fullscreen mode in the "What's new in Gimp 2.4" page of the Gimp 2.6 help*, and the page seems very clear on the fact that Tab is unique to fullscreen mode. I can't find any mention of this magic Tab key in any of the menus, either.
* I guess that means there's nothing new in 2.6.)

The GTK file selector is also constantly tripping me up. Mine is always in open mode, because it's virtually guaranteed to not have the right directory in the listbox. So I'll click in the directory-selector area, and use the keyboard to whip through the hierarchy to whatever location I actually want, then turn my eyes to Name again. Now, that Name box has the X11 selection, so it's helpfully highlighted. But it is also not the input focus, so it's actually an ever-so-slightly de-emphasized version of the real selection color. It's close enough to the proper color that I never realize it's not really selected, even though it's selected, and I try and go into a directory named for my file choice. Or I realize my mistake, and press Escape to get rid of the find-a-directory box, and the whole save dialog closes.

Without remembering my place, of course, so I have to go running through the hierarchy again, possibly making the same mistake. Typically I stop myself before hitting escape, and wonder which key I should press until the find-a-directory box times out and vanishes, at which point I am finally allowed by the grace of Emperor Gtk to hit Alt+N and put in a filename.

Magnitudes

Ranting aside, those are my examples. The worst usability problems a user will face are the ones that go against the grain of that user, to the extent that practice begets familiarity only slowly. Problems are also noticeably worse if there's no workaround. While the Applications menu may be surprising, it doesn't do anything destructive to click on the icon instead of the text, nor does it relentlessly continue obstructing anything.

I would almost say that the menu example is not even a usability problem, but if the other issues were to be fixed, it would rapidly become one. Like reducing the time of something from 1 second to 0.1 second, it doesn't sound like much of a gain, but that small difference can change your entire perception of the system, and maybe even your whole way of working with it.

What if it did change your way of working with the system? Once we become accustomed to a new habit, it's jarring to see the old interface. Like people who get used to searching the Start menu in Windows Vista, then return to a Windows XP machine: all of a sudden they have to worry about the spatial layout of the menu and vendor names. Still, prior to Vista, the old spatial start menu with folders named after vendors ("Google Chrome") were all we had, and we were fairly proficient at using them. Does it make the Vista search box less usable? Or is the XP way less usable in an absolute sense, and shunning the search box in favor of moving around the full programs menu is always holding us back?

Discussing this almost makes me wonder if the way that Vista's start menu is much smaller than XP's, and opens its folders as a tree in that small area instead of a submenu, is a deliberate reduction in usability of the old path in order to nudge users in the direction of using the search box instead. The search results are confined to the same area, but having been searched for, they're of much higher quality and immediately accessible instead of being in Programs→Random Vendor.

As fashionable as it may be, I'm hesitant to regard Microsoft as completely clueless.

Design Goals

How do we really go about measuring usability, when the speed and ease of task completion varies based on experience and familiarity? Usually, the design is optimized for a large number of "average" users, who are using the software for the first time. This masks the effects of long-term experience and familiarity with the specific interface at hand, and ends up testing how well your product acts just like everyone else's.

This sort of consistency is very useful in making your product easy to pick up, but also tends to hold back innovation. If OtherCorp had been developing the iPhone instead of Apple, would they have backed away from an all-touch interface and instead produced something like the touchscreen Blackberry model? After all, very few people at the time used keyless phones, and the phone wouldn't give any tactile feedback on whether the screen registered a press on an object.

The other danger of following strongly established conventions is that your product may be for a professional market, where users have a chance to become real experts with the software. Should Photoshop's default toolbars and feature availability be oriented toward the average corporate graphic artist, or toward people who heard on the Internet once that you need to be able to work with CMYK images for print? (Which I hear, as publishing goes fully digital, is just a needless pain for the actual printer.)

Like security, it doesn't seem that usability is something that can be sprinkled in later. It needs design, and it needs to be designed for someone. Complexity in Photoshop is not necessarily a condemnation of it, but overwhelming complexity in getting your files off your digital camera card is a problem.

Free Software

How does usability fit into free software? One of three things seems to happen: the standard "scratching an itch" example of where a program is built with no thought to usability beyond making the desired features possible; the standard "users are dumb" mode where all possible features and options are stripped out as aggressively as possible; or, rarely, an interface that doesn't hold back, and offers enough options to suit every hand.

Part of the problem is the desire of certain factions to exit the world of the tinkerer and get into the realm of Real Serious Software. They're actively ignoring the actual userbase in favor of chasing a different market, while still claiming they're perfect for everyone.

Also, working on usability isn't very exciting. Once an itch is scratched—once some software exists to solve the original problem—the rest of it required to make a successful project is just too much boring work. And when one isn't getting paid for giving away their work as Free, it makes little sense to spend any effort on the rest of the project.

Finally, usability doesn't get much respect. Witness the amount of flames generated on the release of Gnome 2.0, when everyone's favorite option was no longer configurable. This readily translates to viewing 'usability experts' as clueless academics living in an ivory tower, actively obstructing your lovingly crafted code. (Something I have regrettably been afflicted with in the past.) It also shows in the tendency to complain about every little thing that a reviewer can find wrong with a piece of software, like the logo in the Gnome menubar.

In online communications, it seems that the more open a system is, the more likely it is for the noise of abuse to drown out the signal of quality. Precious few of the comments on reddit for a given link will be deep insight. Other "democratic" channels like email, open blogs, forums, and wikis are swiftly buried in spam unless protected. Search engines must fight with people trying to spam their result pages. Systems that successfully defend against spam are immediately faced with the problem of trolling.

Access to the capability for anonymous, uncensored speech is important to general freedom, as a means of bringing suppressed or ignored issues into the public eye—Wikileaks for instance. Anonymous discussion can be useful, but anonymity is obviously not a sufficient condition to generate high quality discussion, where quality is roughly defined as the amount of "signal", the fraction of posts that are non-spam. Perhaps one-line jokes would also be excluded. (I'd love to exclude trolls as well, but I suspect trolling is a generalization of Poe's Law, which makes measuring trollishness futile.)

Reddit ends up being a fairly democratic back channel for the entire internet, since it allows for virtually anyone to comment on any link, whether the source allows, moderates, or disallows comments themselves. It also unifies all sources into a single, consistent comment interface, and allows community votes to determine what content is worth keeping. Yet out of this set of features comes not an intellectual utopia, but a culture that loves memes and pun threads, and can be rather harsh on opposing viewpoints. Part of this is a result of the churn rate: if a hot link is really only visible for a few hours, then a comment needs to be produced quickly to be seen at all. That applies the pressures for the quick jokes and jabs.

I also wonder if part of the appeal of the noisy posts are in the fact that there's so little invested in jokes and insults as compared to real responses. It's easy to proclaim that someone is an idiot, but a lot harder and slower to eloquently rebut their points. So the former tends to happen a lot more frequently.

Is there a way to remove the noise from online conversation? The only way I can really see to have a noise-free channel is to meet in real life, away from the Internet's permanent floating riot club. Darknets (e.g. private invite-only forums or friends-only livejournals) are the online analog, but the problem with both of these methods from a democratic point of view is the limited participation. It can so easily become a glorified clique.

I guess a full range of spaces are required. Wikileaks has a vulnerable core, uncensored systems can be overrun, and darknets have their problems too.

---

I would like to pass some credit to danah boyd's discussion of her talk at Web 2.0, where the back channel (commentary about the talk) was displayed during the talk, for the whole audience to see. It was this post that started me thinking about back channels, reddit, and democracy. (Incidentally, showing the back channel as part of the front channel still seems like the worst possible thing you could do to a speaker.)

Once upon a time, I watched the SICP videos, and then I wanted to make programs that were actually coded in their data structures. I proceeded to write great(ly embarrassing) systems like pagelib, and huge wads of closures in JavaScript. Y'all just say the word, and BAM! Your page is sprinkled with self-contained magic. Perfect, right?

At first it was, but then I tried to extend that Javascript password validation to the other pages with password fields, and ran into a bit of a problem. The ID of the fields that the validation code targeted were different on each page, and I didn't want to update the frontend, then require the backend to understand both sets of names for a grace period. Especially since the grace period was likely to be determined by the next feature release, and during that cycle I may forget to remove the legacy path and inadvertently extend the grace period to epic proportions.

I ended up shattering the beautiful, perfect structure of my impenetrable thicket of private data, and replacing it with what I would today recognize as dependency injection. Now people could get their magic in wooden boxes with levers and dials, instead of a featureless black one.

As my career has progressed, I keep running into this same basic problem: orthogonality is always necessary. If one feature depends on another in the current practice of the business, sooner or later a new client or situation is going to require an exception. Automatic dependencies are painful to change, especially when they get overloaded with several interactions and only one of those needs changed.

Metaprogramming seems to run into the same sort of troubles for me. If I do whatever it takes to factor out all common bits of code, then I end up spending a lot of time producing another fragile crystal. Melding together similar pathways results in a fracturing the structure when a change is needed for one of those pathways, transmitting knowledge of the changes into all the pathways that have been directed along that channel of code.

Alternatively, the data structures being turned into code don't support doing whatever operation needs to be added. The entire interpreter may need fractured to deal with the "small" addition of a new feature. The interpreter may be 'more powerful' now, but the understanding of the data structure is still threaded through the whole thing, and the next feature may cause the same effect.

Although this post has so far been focused on dynamic features leading to crystallization, the same thing can happen to a static type system. In PHP, no object unrelated to PDO can pass a PDO type-hint, because PDO is not an interface. Nor can any native connection be "wrapped" in PDO, so if you have two systems using different DB access layers that you're trying to integrate, you're either rewriting one to use another database, opening up a couple of connections, or adding an adapter to translate PDO to the alternative (and hope you don't end up segfaulting because you didn't call PDO's constructor to avoid setting up the connection).

Static access is also a major source of crystalline structures in any program. Every time you use a class name, you're carving the interaction in granite. Singleton? new operator? Instant crystal. Factories and dependency injection were invented as the epoxy to hold the fracture together when that perfect fusion of collaborators is no longer so perfect.