Sometimes little details go a long way to improving the feel and quality of a product. For the most part, these fall into the category of “don’t annoy your users.” But a few are truly helpful. Here are three we’ve implemented for Thought Holder:

1. Useful information in the browser window title — Your users aren’t always going to be looking at your application. They may go check their mail, browse some interesting blog, surf for pr0n, whatever. So it’s helpful to indicate to your users when you’ve got new stuff for them to look at. We do this by adding brief notices to the browser window (or tab) title. That way the user can see that they’ve got stuff to do back on our site without having to lose their place in what they’re doing at the moment.

2. Caps Lock Checking — This is both surprisingly huge and extraordinarily simple. How many times have you fat fingered and accidentally turned on Caps Lock? We’ve made sure that Thought Holder (and all of our other products) warn you if you’re entering a password with caps lock on. We got the inspiration (and most of the code) from this forum post.

3. “onbeforeunload” Edit Warnings — Ever been editing something and close your browser window by mistake, before saving your work? Or, for nerds like me, forget that Ctrl-W is cut in Emacs but close window everywhere else? Lost work can be rough, and there are generally two solutions: autosaving (which is another post entirely) and warning the user that they’re about to lose work. We chose the latter for Thought Holder. Every time you have an edit window open, we add a hook to the browser’s onbeforeunload event that pops up a handy little dialog. Here’s how we do it:

And the Lord looked down upon his creation and said… “Meh… it works, but 2.0 will be so much better!”

As any creative individual will tell you, looking back on old work can be a humbling experience. I had the opportunity to look back this week on code that I had done about 4 years ago This was an old project that the client had been using for about 4 years and they were asking me if I might want to package it and possibly re-sell it to similar vendors). I was excited by the idea (money) and proceeded to dive right in to the old code.

Oh dear lord! What was I thinking? Is there ever any reason for a 200 line print statement? Why would I name a variable $stuff? Who would name database tables that way? This is held together with glue, thumb tacks and the prayers of small children. It has got to be re-written!

After breathing deeply into a brown paper sack for a few minutes, I called the client back and told them that I would need to “polish it up a bit first.” (FYI: Never tell the client that the code they have been using successfully for 4 years, needs to be re-written. The code works. The client hasn’t asked for any changes. Do not poke the dragon.)

The point of this is that while our older work can, in retrospect, be the equivalent of the 80’s mullet hairdo, it should also serve as a reminder to us that what we create today will very likely seem childish by comparison to what we create several years from now.

Repeat after me: This is a good thing.

If our creative efforts today simply mirror our creative efforts of long ago, then we have not moved forward. We have stopped learning. We have stopped exploring. We have ceased to be curious.

That is the death of creativity.

And so I say, celebrate your mullet code, for it is a sure sign of progress.

Not a whole lot, but a little, and sometimes a little is all you need.

Webmonkey has a post up about their Five Favorite Furebug Extensions. I’ve used YSlow for a while, and Firecookie looks useful, but I’m most glad to see that FirePHP has come so far. I noticed FirePHP when it first came out, but it took a little too much doing to make it work with Our Way of Doing Things™. Well, it’s come a long way.

I took a half hour today and integrated FirePHP with our debugging tool. See, we’ve got a custom debug class that outputs an html table, json or plain text, but the output has always been a bit clunky. As of today, however, we get this:

So you’ve built the better mousetrap, and you want to know exactly how many people have beaten a path to your door, and if they’re using your mousetrap just to catch mice, or if they’ve found new uses for it, such as trapping ocelots. Or are they even using your mousetrap at all?

Knowing what your customers are doing with what you’ve built is critical. Knowing who your customers are and where you can find more like them… doubly so.

So you build gps tracking systems into your mousetrap, and add little wireless cameras that look like cheese… okay, so there goes that metaphor…

When looking at new features for Thought Holder, it would be immensely helpful to know how our current users use the tool. When they log on, do they open up a bunch of books, check for new comments then log out? Do they work for a particularly long time on composing a single note?

Adding code to track what a single user does isn’t that difficult. But that’s not the goal. We don’t want to end up like You Tube, we just want to know in general what are people doing. So how do you determine the right level of usage data to gather? And how do you make sense of it?

In the old days, you tracked things like hits, click streams, etc. with tools like Urchin or Web Stats. But with web applications, there’s a lot of interaction that stays in the browser, then is sent to the server in a single payload. That doesn’t exactly help. There are also tools that track cursor and mouse pointer movement, but who has time to sift through playbacks of your users’ mouse movements?

The trick then, is to find a middle ground, one that protects your users’ privacy while giving you the information you need to successfully grow your business in a way that enhances your users’ experience.

Tough trick, that. I’ll let you know if we ever fully figure it out.

We did our first July software update for Thought Holder today, and it seemed to go fairly smoothly. There’s lots of new stuff this month, so let’s hit the highlights!

Read more

“Hello World” is one of the oldest and most often used programming concepts around. It is the novice’s introduction to the new programming language, designed to generate a visible result with a minimum of effort. While the method varies from language to language, the concept is simple; type a little snippet of code that makes the words “Hello World” appear on the screen. In PHP code this would look like this:

<?
print “Hello World”;
?>

This simple lesson is so ubiquitous that “Hello World” is the default name for the first post of any WordPress blog. You’re supposed to change it when you setup the blog, but it also seems to me to be a nice way of introducing something new to the rest of the planet.

With this blog, we hope to share some new things with you, specifically the process, the ideas and the people involved in the creation of the web application called Thought Holder.

Future posts will cover not only new features, but the ideas, roadblocks and methods involved in creating a large public web application. Hopefully it will give you a chance to get to know us and get to know Thought Holder.

And so we at Twelve Foot Guru would like to say with all sincerity…

Hello World.