Tom Dalton :: Doer of Good

Some public restrooms are tolerable, and most are definitely not. One at the office complex I work in has an inch-and-a-half wide gap between the door and the frame, which has a tendency, on occasion, to provide us with visions we'd rather burn out of our heads. There is a small ventilation fan, but it is quiet and doesn't move much air.

(I know, "quietude" is supposed to be a cardinal virtue of bathroom fans, but there's really a purpose they serve beyond just moving air.)

At any rate, I was led to ponder: What makes a good bathroom?

Like any good tech-person, I turned to Google and typed in [public bathroom design]. Like a good search engine, Google returned to me a list that included the following great site:

http://www.edfacilities.org/rl/restrooms.cfm

That article contains links to a myriad of other articles about bathroom and locker room design. Loads of professional insight and discussion on issues that hadn't even crossed my mind. Sure, layout is a big one. But what about maintenance? Durability? Use frequency?

The bathrooms in Hong Kong were the best I've ever used. Tall, tall walls and doors that ran all the way down to the floor. (No more matching sounds and shoes!) But those would probably be invitations for vandals, here in the US.

One article talks about no-flow urinals. Cool thing: they have a 'trap' which contains a 'sealant liquid' that floats above water (and any other substance that may be splashed into it). Maintenance involves dumping a gallon of water into the toilet every once in a while to wash away any build-up. No handles, no plugging and exciting overflowing, no nothing. Just a simple, effective system.

The science of bathroom design is flourishing, my friends. Let us all work to encourage more bathroom designers to take advantage of its fruits.

There's a clear difference between a programmer and a user, right? Except that there's a category in between those areas that blurs them. To coin a phrase: "Technology Integrators."

These people don't speak any particular programming language well enough to turn a blank notepad document into a functioning block of code. They know some basic principles of programming and are familiar enough with several languages to generally follow the sequence of code. The key that I think leads to the recent rise of this class of person: the Internet. They can look up classes and instructions online to work out how to modify things. They can follow example code and see how another implementation works, to port those ideas into their own projects.

I think I fit squarely in that category, though shifted toward the programmer end of the spectrum. With documentation handy, I can write working stuff from scratch. I don't have enough experience to be a Real Programmer, but I can do neat things with code.

Technology Integrators are, on the non-technical end of the spectrum, building blogs on MySpace. They're using Flickr -- not just using it, but generating the 'badge' code and putting that on their own blogs.

Toward the more technical end of the spectrum, they're modifying blog themes -- CSS and PHP. I am working on a project that sparked my thinking about this: integrating four separate blogs into a fifth that pulls from the databases of the first four. Linking each blog via the Flickr API and a few plugins to photos that can be included in individual posts. And having the fifth blog recognize and resize those photos to fit within its special constraints.

I'm not really writing any code from scratch to do this, but most "users" couldn't ever do something like this. And real "programmers" would write something far more elegant to do it. (Perhaps it's more appropriate to say that real programmers "could" write something more elegant. I bet there's not many people who actually would. But then, I don't think there are very many actual programmers.)

Without the middle category of "Technical Integrator," somebody like me is forced to decide whether he's a very, very good user, or a really bad programmer. I don't want to think I'm either.

What do you think?

Why have a "save" button?

So people can forget to save?

So things can crash before people get to hit save?

Every single program should automatically save, all the time. Save to a temporary file that is automatically restored next time the program runs. When the user hits the "save" button, apply it to the permanent file. But don't NOT save just because they didn't hit the button.

Please!