Finally, someone has developed web-based bug tracking software that works. It's simple, it's clean - heck, it's fun.

16bugs may be the best thing to happen to bug reports since, well, the invention of bug reports.

I often find myself wishing I could prove somehow that it's better to fill space in a web application with content than it is to fill space with graphic design, but I haven't yet had the opportunity to test this hypothesis.

Graphic design is incredibly important in an application, of course, but a lot of apps seem to waste a lot of space focusing on how things look. Some of the space is for navigational elements, some for interface widgets that provide access to other features, and so on, but in addition to this, "chrome" (the graphical elements that comprise a screen) can suck up quite a bit of space that could otherwise be used to display the very data the application is meant to manage.

Case in point:



Box.net is a great online file storage service. It looks nice, has a spacious, clean interface, and is very easy to use. There's very little risk of bumping into unneeded features when performing the major, everyday tasks in the tool, and if you do want to access these features, they're easy to get to. But Box uses a lot of space for its interface. What I want are the files I'm using Box to manage. I want less interface.



DropSend, on the other hand, minimizes chrome fairly well and leaves loads of room to display the files I'm using DropSend to manage.

Somehow, I know this is better. I know it's the right way to go. But I have no proof, so when I fight to minimize interface elements in favor of data, I have nothing to back it up but my own instincts.

If you happen know of a report or something that substantiates this claim, please be kind enough to share it. In the meantime, I'll continue believing what I believe.

Focus on the data, not the tool.

FeedShow, a web-based RSS reader, has made its beta debut but isn't exactly making waves in the interface department.

The Two-Panel Selector design pattern is used by both FeedShow and Bloglines, which means FeedShow hasn't done anything to improve the way RSS readers work since Bloglines made its debut. (This pattern uses one panel for the selection of objects and a second panel for the display of data, much like Windows Explorer.)





The Two-Panel Selector pattern is really effective in a lot of applications, but in both of these RSS reader applications, it translates to a fairly stodgy appearance. FeedShow does look a little nicer than Bloglines, but neither application is making any kind of statement with these designs. What's more is that FeedShow's use of the same style of interface as Bloglines means the first impression of any user already using Bloglines will likely be that FeedShow isn't offering anything new. Nothing here will improve the state of a typical RSS reading experience. The UI does not provide any incentive to switch. And as we all know, the cost of switching RSS readers is often pretty big. Many people using RSS readers have a ton of feeds listed, and no one really has the time or patience it takes to move all those feeds over to a new application without serious incentive.

I'm not against the use of this design pattern - it does make sense for an RSS reader. I just think FeedShow is going to have to do something better to win over Bloglines fans.

Many RSS readers make use of an Outlook-style, three-panel layout. Select a feed on the left, choose a post from a list on the top-right, and view the post in the lower-right.

What I'd really like to see is an RSS reader that emulates the Gmail interface. It's still a Two-Panel Selector pattern, but the use of the Inline Expand pattern for each individual post means every post is viewed in context of its position in the list (posts are generally sorted by date, so this makes sense), and it avoids splitting the view area into two panels, like the Outlook-style interface.



Now that would be sweet. Why Google didn't do this with their own reader, I have no idea.

Interesting piece about the benefits of removing the "www" from your URL.

Extending this, browser makers should really consider just changing the string that appears in the Address bar, regardless of the actual address. There's no reason to show users the "www" or the "http://" at all. Users don't need to know these things to see or use a web site. It's an implementation-model leftover that should be buried once and for all.

My wife tried to sign up for weekend delivery of the newspaper yesterday. She swung on over to azCentral.com, which handles subscription registrations for the paper in Arizona and filled out the long and grueling form. Part of the form told her that if her billing address was different than the delivery address, she needed to enter the delivery address.



Since the billing and delivery addresses are the same, she didn't bother filling this out. She got an error message.



Note the message in the first screenshot. "If your mailing or billing address is different from your delivery address, please provide the following information."