Pavlov's Bitch

I was recently beta-testing a friend's new site DevGrow which on one page had a checkbox labeled "Monitor Topic". After clicking it (and, being from the good ol' web days with no version number), I then faithfully searched the surrounding area and then the entire page for a "perform this action" button -- and never found it. Frustrated, I looked back up at the checkbox which now read "Monitoring Topic".

Yello?? Im in ur website bein lawst.

My original point of this post (sadly, not devgrow or basecamp) was Google: have you noticed when using GMail that clicking "Select [All | None | etc]" button that the (un)checking of your messages is wicked fast? I feel like I did something -- just by clicking a checkbox! Talk about positive reinforcement!

They might have realized (an acted on the fact that) this 'check-all' action is an important operation to the user and thus might have decided to speed up this action.

All that to say -- anticipating and responding to those parts of your website can provide the user with a pleasant (and let's not forget reinforcing) experience -- especially in the case of DHTML.

So here's to yellow or blue or whatever frickin' COLOR FADES; and to OBVIOUSLY different text changes; and to ICON changes; and to ANY changes BEFORE the async response. Because my life is very non-async. err. in sync. synchronized.

I smell you on my hand for days
I can't wash away your scent
If I'm a dog then you're a bitch
I guess you're as real as me
Maybe I can't live with that
Maybe I need fantasy
A life of chasing butterfly
-- Weezer - Butterfly

Computer DNA

We've all taken Biology classes and have been subjected to the memorization and regurgitation of the composition, structure, and behaviour of our physical shells -- base pairs, construction of proteins, metaphase, etc. This low-level view -- though incredibly interesting and insightful -- became incredibly tedious: while studying I ceased thinking of the effects of this miracle of life and was entirely engrossed in its technicalities.

In retrospect, I find DNA Biologists to be equatable to those of our breed who enjoy using ML, ASM, and (gasp) C in their everyday occupation. And I'm very grateful to both professions ! But I'm not sure what I would do if I had to consider either the protein breakdown of my sandwich or the hash-function in my VB.NET hashtable -- both are a necessarily abstracted into 'eating' and 'storing'.

This is not a new concept -- abstraction is necessary (anyone find a link?) facet of functioning.

All that to say -- I'm glad to have studied both Biology and ASM -- but I'm even more glad that I don't have to consider it every day. All the more for those who (choose?) do.

Appropriate ness (part deux)

I recently did a design review where there was an issue surrounding their choice of 'data storage implementation'. I use quotes because to me as a web developer, any data belongs in a database.

The issue arose over the fact that for this application written for the Java environment, they didn't need to store anything but usernames and passwords. They planned on using JDBC and having just one users table.

Like I said -- all well and good by me. I'm more used to having more tables and more relations between my data, but again it seemed most natural to me.

The surprise came when someone suggested that they just use a plain text file. If they were only going to store limited amounts of data and very very limited associations, why not just plain text?

Maybe this seems obvious to those who have had this experience before (or more than once), but it seemed so obvious to me that it was obscured. After the fact, it was indeed the right choice. Case to point: 1) Java has built in I/O operations 2) Their I/O operations would not (conceivably) cause any buildup and (most importantly) 3) JDBC is yet another thing to implement and (potentially) cause errors in their system.

Call me crazy but that Occam's Razor is either a natural talent or a life-long quest. For me it seems the latter.

So here's to other people's insightful (yet sometimes humiliating) comments that make our lives that much less complicated.

Appropriate ness (Appropriation?)

I recently did a constraint-satisfaction problem (CSP) in LISP to solve sudoku puzzles. I finally was able to visualize the recursive pattern and (to me) it looked alot like the stock market circa 1998-2005 -- up-down-up-down-down-up-up-down-down-down-down-up-up-down-up-up...

This actually reminded me of Matt Zandstra's book PHP 5 Objects, Patterns, and Practice. I read this at a time in my life where I had (naively) written an architecture for a system (in PHP5) which was quickly becoming unmanageable. This book helped me collect my thoughts about how to re-collect my code.

One of the things that I found very interesting which had never blipped on my radar was the idea of the appropriate throwing, catching, handling, and re-throwing of exceptions. Matt Zandstra emphasized that exceptions are powerful error-recovery tools -- but that they need to be handled at the appropriate level in your application: that model-level exceptions must be caught and handled (hopefully recovered) in the model and -- only when necessary -- passed controller. Heaven forbid if they propagate to the view.

Chris Snyder's book Essential PHP Security chimes in with the idea that often errors which occur at lower levels can cause security breaches. How many sites have you visited that have said "Cannot select `id` from table `users` with value ....". So if i just tweak this input-field...

So think about exceptions and their course through your application -- are there some which are relevant only to the model? Or are some worthy of propagating all the way up to your controller? Who owns that exception? Where does the buck stop?

User Expectations (part deux)

It's strange how the current generation (don't get me started on the following generation) has become accustomed to certain expectations for software. CTRL-C should *always* mean "I want to take whatever is selected, and use it somewhere else." Menu -> File should *always* contain "Save as..." so I can take what I've written and save it as a different version. (speaking of which -- when will Operating Systems start implementing integrated version control?)

For those of this generation who have used any version of a search engine well enough to know how to "manipulate" it (i.e., correctly use it) to find relevant results, we know that "-" (the minus sign) means "please, don't include this word in my search results".

I am not a frequent ebay user, but it delightfully participated in my "reality" by accepting that "-airsoft" as a search parameter meant I wasn't searching for an airsoft gun.

For better or for worse, users have already set standards for how our programs should function. To go against these "traditions" is to go against any other established societal standard -- to drive in the left lane; to turn a screw to the left in order to tighten it; to have the "power" button on the right-hand side of the TV remote-control; to defy gravity...

As any good citizen of the human population, our job is to question tradition; however, some traditions are so ingrained and so untouchable that we must acquiesce to the norms and toe the line.

When designing user interfaces, first ask yourself -- "would this be most natural to me?" As any HCI professor would tell you, that's not enough. You must think outside your own inclinations and actually consider the input of those who are not accustomed to thinking "behind the scenes" of an application -- who can actually (I might say "without bias") say "ladies and gentleman of the jury -- this. does. not. make. sense..

I wish that you would just leave
Because your presence still lingers here
And it won't leave me alone
These wounds won't seem to heal
This pain is just too real
There's just too much that time cannot erase
-- Evanescence - My Immortal

User Expectations

I put in my dollar bill, my quarter, my nickel, and my dime (notice that decreasing size dominates decreasing value). I pressed the "Mr. Pibb" button. And what happened?

Out came a Cherry Coke.

Strangely enough, I didn't really mind. I may not especially like Cherry Coke, but it suited me just fine: it had sugar and caffeine and that oh-so-great bitter-sweet cola taste.

My confusing experience at the vending machine is analogous to what users may feel while experiencing our applications. In my case, the supplier incorrectly loaded that particular slot; or, perhaps, loaded it correctly but didn't bother to change the label. Both cases pretty much sum up what we as coders are prone to do -- either not detect or not care about interface discrepancies.

Users can find these "mystery boxes" to be annoying, especially if they eclipse major functionality of the program. For instance, when no soda comes out at all after I've inserted my money and pressed a button -- well, I guess that's what Customer Service numbers are for...

What's bizarre to me is that I have heard of cases where a QA Engineer has discovered and fixed a "bug", only to cause Customer Service to become inundated with complaints regarding the missing "feature".

It shouldn't be so much of a stretch to imagine someone who uses who is used to pressing Mr. Pibb in order to get a Cherry Coke. But they've learned: either through their own mistakes or through someone else's -- that kind of knowledge is acquired, not explicit. Either way, money has been spent without total satisfaction.

Do you think that person would be annoyed if, unexpectedly and unannounced, a Mr. Pibb started coming out when they pressed Mr. Pibb?

Embrace your mistakes. Bugs *can* be features. If you still feel that serving up ice-cold Mr. Pibb is worth your while, make sure that it is clearly labeled, fully stocked, and that those who came for Cherry Coke can still get Cherry Coke.

From this time, unchained
We're all looking at a different picture
Thru this new frame of mind
A thousand flowers could bloom
Move over, and give us some room
-- Portishead, Glory Box