Nov 5, 2010

Internet Explorer AJAX errors debugging in Prototype

This is a short story I want to put down for those who face the same problem.

In Checkvist project, there is some not very trivial AJAX code. We use Prototype javascript library for AJAX handling. Prototype allows to specify error dispatcher for AJAX javascript errors, and as a fallback solution, I set window.alert() to report errors.

Several days ago I got a bug report related to list deletion operation in Checkvist - Internet Explorer showed a couple of alert error dialogs. The problem was intermittent on the production server, and I couldn't reproduce it locally at all.

Really nice and cool development tools in IE8 couldn't help me. I've had an exception object in my error handler, but there is no way to obtain stacktrace from it and find out where the real problem occurred.

I tried to rethrow the caught exception so IE would show me what happened - no luck.

After plenty of digging in Google I found a hint. IE can debug an error occurred in Javascript code only if it wasn't wrapped in try/catch block. So if you handle problems yourself - there is no way to catch the real problem in the Internet Explorer debugger.

To solve the problem I had to remove all try/catch blocks from Prototype's AJAX code, put it to the staging server, spend another 10 minutes to reproduce the problem, and - voila! - got an invitation dialog from IE8 to debug the uncaught error.

That was it. The error was fixed, Prototype was reverted to original state, code put to the production.

If you know another solution for the problem - please comment, I'd be glad to know.

May 16, 2010

Feature discoverability

One of the great approaches to developing usable software is to actually use the product you're working on. It is often called "eating your own dog food". The benefits are obvious - you have clear source of the requirements and priorities - because you're your own customer. A lot of good books for entrepreneurs like "The Art of the Start" or "Rework" promote this approach.

But there is a trap.

While adding features you mostly think of their usefulness, speed, productivity. You ponder how you'd use them in the most efficient way. And this sounds good, right?

In this situation you're thinking as an expert user of your product. As a user who knows the product perfectly well from its day one.

Features designed for experts are usually hidden. Keyboard shortcuts, advanced interface settings, non-trivial mouse gestures, cool rich functions hidden deeply in the UI. And you, as an expert of your product, might not expose these features enough (especially if you care for UI simplicity and don't want the interface to be bloated).

And even when you're adding a non-expert feature, you can still hide it somewhere in the interface and your users won't find it. You definitely will - you know where it is. But other people can be unaware of its existence at all, or (worse) miss it even after searching for the feature.

The most relevant recipe to detect such problems early is to perform regular usability testing, especially for the new functionality. Unfortunately, most software development teams don't do this, though even a simple 5 second test may help.

Here are some other steps to ensure feature discoverability:
  • Provide a logical predictable navigation system in the application, either in the menu or some other way. Many users use the menu as a reference for the application features.
  • Give users a possibility to search for a particular function, either in the reference documentation or search for an action within the UI.
  • Make a screencast and/or blog post to inform your existing users about new cool feature.
  • In the application, create a "Fresh updates" section, which will inform existing users about new versions of the application, and which new features are available in it.
  • Create a "Hint area" in the application, which shows some relevant actions for the current situation.
  • If your application perform some lengthy operations, you may show users some "Tip of the day" screen while such operations in progress.
  • Prepare a printable cheat sheet with the application's keyboard shortcuts, if you provide them.
We're facing the discoverability issues both in TeamCity and in Checkvist, and going to deal with them in the nearest future, so your feedback is appreciated.
How do you help your users to find new or advanced features in your application?

Apr 21, 2010

What I like about TeamCity 5.1


I've decided to sum up the most interesting (from my personal point of view) new stuff in TeamCity 5.1 release. I started writing this post in text, but decided that a form of outline is more suitable for that. So here is the outline I've prepared using Checkvist:

So please, grab it and use! TeamCity Professional Edition is free. TeamCity Enterprise for OS projects is also free.

And there is 60 days evaluation license for TeamCity Enterprise (you can use this license to upgrade your existing TeamCity Pro installation).

Enjoy your builds :)

Mar 12, 2010

Memory leak fix in Scriptaculos Autocompleter

The latest released version of scriptaculos (1.8.3) has a really old memory leak. In short, Autocompleter creates a lot of event handlers and never removes them. Given that Checkvist will use tag autocompletion rather intensively, I've decided to fix this problem.

My solution is attached to the issue at the lighthouse and also available in my fork of scriptaculos.

May be this fix will be helpful to someone else :)

Mar 8, 2010

Calculating the cursor position in textarea with JavaScript

I've been spending some time writing tag support in Checkvist, and decided to share a bit of related JavaScript code.

The idea is to allow adding tags with smart syntax: when you write "Call Bob regarding new furniture tomorrow #home" Checkvist will create a task "Call Bob regarding new furniture" with due tomorrow and with tag #home.

The additional nicety could be the tag completion after the '#' character. But here comes a problem - how to show the completion popup near the cursor position in the textarea? The typical approach used in or GMail is to show the popup under the text field, but it doesn't look good when your cursor is far from the popup, in the beginning of a large text area.

After some googling I didn't find an existing solution. The only helpful code was detection of the text cursor position relatively to the beginning of the string.

To convert this position into pixel coordinates, one has to find out how the text is organized within the textarea, where linebreaks are, how many lines are there in the text, and so on. This, in turn, depends on the font metrics of the text and requires answer for the question "What is the length of the given string if it is placed into this textarea?".

The answer for the last question can be obtained if you create a div with the same font metrics as the original textfield, give it absolute positioning, put a string into it, and take its width. Using such a function, you can model text wrapping in the textarea, and find out the actual X,Y coordinates of the cursor in the textarea.

You can find my implementation of this approach on GitHub (BTW, a really great place to share open-source code). This library was tested with FF3, Chrome, IE, Opera, Safari. There may be some glitches, but they are rare and I'm pretty comfortable with the results so far. There is no need for Prototype, jQuery or other Javascript libraries to use the code.

I hope this code will be useful to someone else, and if so, please drop me a line :)