Out of Hanwell

February 27, 2006

Virtual Bugzilla Server

Filed under: Uncategorized — Matthias Miller @ 7:09 am

I’ve considered downloading and installing Bugzilla on my Windows computer, but I didn’t want to hassle with it. I can finally download a virtual machine to try it out. The website also offers instructions on tightening down the server for production use.

I wish images like this would be available for more server applications.


February 25, 2006

Finding a Place for Ajax

Filed under: Uncategorized — Matthias Miller @ 9:56 pm

You may have heard it a hundred times: when you develop an application, decide what you want to accomplish, then pick the right tools for the job. Don’t get that switched around.

I’ve been working on a highly-interactive business web application. I’ve found that my most difficult challenge is not learning how to manipulate the DOM, implement Ajax, or use JSON. The greater challenge is instead to conceptualize an intuitive, high-touch interface. If a certain interface is unnatural or difficult to code, I look for alternatives.

This week I used Ajax in that project for the time. As odd as it may seem, I never needed it before.

If I have anything against the great attention Ajax receives, here it is: Many web developers are looking for nooks and crannies in which to implement Ajax. Business people are looking for Ajax because it’s the New Thing. But they’re missing the point. The point is to develop more interactive, more useable websites. Maybe that means showing relevant and hiding irrelevant parts of the page, supporting drag and drop, adding better keyboard support, or improving aesthetics. Each of those can greatly improve the useability of a website. None of those necessitate Ajax.

I have been annoyed countless times by websites that set the focus to the wrong input control. eBay, for example, has redundant search boxes. I always type my search terms into the first box that appears. By the time I’m halfway through, the page has loaded and I’m taken to the other search box. Then, I’m forced to decide whether it’s easier to go back to the first box to finish my search, or just to start all over in the second box. Conversely, I have also been impressed almost every time I log into Newsgator. I’m immediately taken to the right box, ready for me to enter my user name and password–before the page has even finished loading.

I have been annoyed countless times by websites that don’t use the label tag for their input controls. When I want to check off a checkbox, I don’t want to aim my mouse at the impossibly small checkbox. I want to be able to click on the text beside the checkbox, just like I do in every other application. It just takes a simple HTML tag. Yet it’s so frustrating.

Autocomplete is cool, but I’ve never been annoyed because I didn’t have it. But I have been annoyed by slow and inconvenient zooming on maps. Traditionally, to zoom in, I have to center the target, zoom in, center, zoom. Except more slowly. Zoom. Wait. Center. Wait. Zoom. Wait. Center. Why can’t I zoom without refreshing the page and reloading flash ads? Why can’t I just drag the map to where it ought to be? If that’s what it takes, use Ajax.

Back to that web application I mentioned.

Until now, the web application’s graphs had been generated for a hardcoded size, but soon they will be generated to take up all available space. I showed my coworkers an early demo, and they were impressed. Was it because I used Ajax? No, they hardly cared! But they were impressed by a web application that showed large, presentation-friendly graphs, automatically sizing them to what the user expected.

Don’t use Ajax for the sake of Ajax. Decide what you want to accomplish, and develop websites that meet that need. Use Ajax when you need it, but focus on making the website intuitive and easy to use. And by all means, try not to annoy me!

February 21, 2006

Amazon Promotion: The 53rd Way to Save Your Job

Filed under: Humor/Mental Leisure — Matthias Miller @ 7:11 am

I just received four copies of Chad Fowler’s book My Job Went to India: 52 Ways to Save Your Job from Amazon. I laughed out loud when I opened the box. Is Amazon offering the 53rd way to save your job?

I laughed even harder when I removed the paper wrapper. Where in the book was that? Maybe Chad Fowler didn’t endorse this promotional item after all.

Amazon’s 53rd Way to Save Your Job

Amazon’s 53rd Way to Save Your Job

February 20, 2006

Censored Internet: Slashdot Only

Filed under: Uncategorized — Matthias Miller @ 6:44 am

This weekend I stayed at a hotel that offered free Internet access, hosted by EthoStream. When I tried to access Google, I received the expected license agreement with a notice to click “I Agree” at the bottom of the page to use the service. But there was no “I Agree” at the bottom of page! I also tried the Sign Up link, which oddly had no forms with which to sign up.

When I tried calling the 24×7 EthoStream technical support, no support technicians were available. I got tired of the hold music and hung up. Nobody was available on their 24×7 chat support, either.

I randomly tried a dozen sites. I got the license agreement on all but Slashdot, so I caught up on Slashdot news. (I could only read summaries and comments, of course.)

Is this some oddity of my configuration, or is this a back door in the EthoStream service?

February 11, 2006


Filed under: Uncategorized — Matthias Miller @ 8:38 pm

Slava Ivanyuk summarizes good design by saying that “good design keeps things intuitive for the user”, but then explains what that means. “As things move towards complexity they become less and less intuitive. As soon as they stop being intuitive and easy to use design is too complicated.”

Go read it.

Browser Quirks and Managing Dependencies

Filed under: Uncategorized — Matthias Miller @ 5:41 pm

Developing applications for multiple platforms is particularly difficult. When the platforms behave identically, it is easy. When the platforms diverge (as they inevitably will), the developer is caught in the middle and must somehow bridge the two worlds.

This is a big problem for web developers, who are dependant on the many different browser implementations. Even high-quality software ships with defects. The trouble with browsers, of course, is that they may be used long after newer versions have been released. Web developers need to support these browsers, either by re-implementing features or downgrading behavior.

Although it may seem that using libraries keeps you from reinventing the wheel, using libraries brings on its own share of challenges. And if developers choose to use third-party libraries to expedite the development, they are dependent not only on the browser but also on those libraries.

First, a library may have bugs. If you’re fortunate, when you encounter a bug in the library, you can simply send a test case to the developers and receive a fix promptly. If you’re less fortunate, you may be able to debug the problem yourself and submit a patch to be integrated into the source. If you are not fortunate at all (e.g. the developers disagree that it’s a bug or the vendor went bankrupt), you’re left with a buggy library that you must either patch with every subsequent release or that you must constantly work around to avoid its problems.

By using a library, you increase the size and complexity of your project. Libraries can consume substantial bandwidth, which is a concern in certain situations. A library is a large learning curve for new programmers. Every dependency on a library is barrier to sharing your code with other projects.

You enter an upgrade cycle for your libraries. Some developers are committed to backward compatible releases, and others simply are not. If not, you can spend a lot of time replacing calls to deprecated functions. Although each new release brings many bug fixes and new features, it likely brings new bugs. Each release can come at a significant cost.

Whether you choose to use a third-party library, the goal is to protect yourself from changes in browser behavior. And if you choose not to use a third-party library, you are likely to develop a library of your own, and likely one that is better suited to your needs. Take, for example, a web business application that I am helping to develop. Even in its infancy, its user interface requires large amounts of JavaScript (the business logic remains server-side). Although we have chosen not to use third-party libraries, we’re doing two things to protect us from browser dependencies.

First of all, we are localizing assumptions about the browser. Many browser differences can be solved by DOM sniffing, but certainly some cannot. For example, when a user modifies form controls and refreshes a page, Mozilla restores the form values immediately. Internet Explorer, however, does not restore them until the page has loaded. This difference cannot be detected by mere DOM sniffing. Instead of proliferating browser checks throughout our code, we chose to abstract this knowledge behind a function call.

Secondly, we are testing our assumptions about the browser. Although we could use a third-party solution such as Selenium or jsAssertUnit, we have chosen to build out our own lightweight unit testing framework. Whenever a new version of a browser is released or if we decide to target another browser, we can run these tests to validate the basic assumptions of the web application’s environment.

Even with our abstraction and unit testing, we spent a lot of time manually testing our application in the recent preview release of the Internet Explorer 7 beta. But we spent our time looking for new classes of problems, not perusing our source code trying to fix that assumption in a hundred different places.

That’s what it means to manage dependencies.

Create a free website or blog at WordPress.com.