LeeDumond.com

Dynamic Help Removed From Visual Studio 2010

Lee Dumond — Mon, 02 Nov 2009 03:52:00 GMT

Been going blind looking for the Dynamic Help window in the new VS 2010 Beta 2? Me too… until I learned this bit of bad news from a inside source.

Like many of you, I’ve been messing around with the Visual Studio 2010 Beta 2. VS 2010 contains a number of long-awaited IDE improvements, like multiple monitor support, new editing and design tools, and a cleaner, more responsive WPF-based interface.

So far, I’m loving all of it. Well, almost all of it.

I happen to be a huge fan of Visual Studio’s Dynamic Help feature. This is a window containing links to related Help topics based on where you are in the IDE.

In fact, I recently wrote a blog post explaining how to integrate exception handling into the development cycle. The process I presented in that post makes good use of this handy feature.

In previous versions of Visual Studio, I’ve always placed the Dynamic Help window to the right side in Auto-Hide mode, ready at a moment’s notice. However, when I went to set up VS 2010 in the same way, I noticed that the Dynamic Help window appeared to have been left off the Help menu.

"Okay, no big deal," I thought. It is beta software after all. You can't really complain if a beta appears a little half-baked, right?

Nevertheless, this was still disappointing to me. I was tempted to report this as a bug, but just didn’t feel like dealing with the massive vortex of suck that is Microsoft Connect. So instead, I did what most other malcontented developers do – I complained on Twitter.

A few hours later - much to my chagrin - I received the following reply:

Whaaaaaa? This made absolutely no sense to me. I figured it couldn’t be true… until I learned that Charles Christian is actually a Project Manager on the Visual Studio Help Experience Team. So, there you go. I guess if anyone would be in a position to know, he’d be the guy.

Sure enough, a quick visit to the MSDN seemed to confirm it. Check it out below – no link to 4.0 up there near the top.

It looks like Visual Studio 2010 will definitely take some getting used to – because of all the new features added, and for at least one that was taken away.

I’ve asked Charles to provide an explanation as to why Dynamic Help was removed. As soon as I get a reply, I’ll update this post. Stay tuned.

UPDATE: Charles' explanation appears below in the comments.

Dr. Explain Gives Your Software a Brain

Lee Dumond — Wed, 28 Oct 2009 13:11:00 GMT

Thorough, detailed, and up-to-date documentation is one of the keys to success for any software application. Dr. Explain makes it easy (almost too easy) to create and maintain CHM help files, web-based HTML documentation, and even printable manuals.

Ask any developer to name his or her least favorite development-related tasks, and there’s a good chance that “creating documentation” will appear very close to the the top of that list.

While writing docs may not be nearly as sexy as architecting or slinging code, it’s a critically important component to any successful software project. Skimpy, incomplete, or disorganized documentation is not only a major impediment to new user adoption, it reflects poorly on the rest of the application, and even on your company as a whole. Despite what you may have heard, people do RTFM. Your software’s help file is invariably the first place users turns for assistance; if they can’t make head or tails of it, your chances of converting that trial download to a cash sale just went down considerably.

On the other hand, well-documented software is easier to sell, easier for your customers to train new users on, and much easier for you to support. Thorough, detailed, up-to-date help is one of the keys to helping users be productive, and productive users are happy users.

Of course, documenting software is time-consuming and tedious, right? I used to think so too. That was until I discovered a solution that makes the entire process easier and quicker than I ever thought possible.

Help That Practically Writes Itself

Dr. Explain from Indigo Byte Systems is a software help authoring tool. It provides a powerful, intuitive user interface for composing a tree-navigable help system for Windows/WPF, Java, and Flash applications, as well as Web sites. From a single source file, it can export to CHM, HTML, and rich text format (RTF). This helps you maintain all of your docs in one place while keeping everything consistent and timely – whether you electronically distribute help with your application, host it online, or deliver printed copies in the box.

While Dr. Explain has all the features you’d expect from a comprehensive help authoring system, it does one special thing amazingly well, which in my mind places it head and shoulders above other offerings in this category. Dr. Explain takes the most difficult, time-consuming, and tedious part of the documentation process – the annotation of user interfaces – and totally automates it.

Yes, you read that right. Let the built-in object capture tool take a screenshot of any part of your application – from a simple dialog, to a full window, to a web form…

…and from there it analyzes the structure, finds all the significant GUI elements, and automatically creates numbered callouts for all of them!

It optionally allows you to associate a definable portion of the screenshot with each annotation, and displays it (along with the descriptive text you provide) at the bottom. This provides helpful visual cues to your readers, as you can see from the CHM output.

A screenshot of the HTML output shows how a consistent look and feel is maintained between the CHM and HTML output.

Providing guidance for all the different screens in your application lies at the heart of effective documentation. Even with the drawing tools provided by many authoring systems, this process can take hours, even days. By scaffolding screenshot-based help topics in mere minutes, Dr. Explain dramatically cuts the time required to accomplish this task. Capture the screenshot, add the necessary descriptive text to the automatically generated annotations, and you’re practically done.

But Wait, There’s More…

Despite its amazing screenshot annotation abilities, Dr. Explain is no one-trick pony. It facilitates many other help-building functions as well, including the integration of context-sensitive (F1) help directly into any application; navigation tree management; creation of keyword indexes; full-featured RTF text editing with Unicode support; templating, theme, and CSS support; and lots more. All of this is included in the $125 standard license.

For an additional $40, an “advanced license” is available which unlocks some very spiffy features, the slickest of which is the ability to have Dr. Explain automatically crawl the entire submenu structure of a Win32 application on one go:

Other advanced features include the ability to invoke the Dr. Explain engine from the command line; the creation of pop-up tooltips; and a tool to generate Google sitemaps from HTML help pages.

To learn more; feel free to avail yourself of any of the following handy resources:

Dr. Explain features overview
A six-minute YouTube video demonstrating Dr. Explain in action
The Dr. Explain user forum
Pricing and licensing options

Summary

Whether your goal is to sell more software, reduce the burden on your help desk staff, or simply to pave an easier path to adoption for your open-source project, producing and providing excellent help documentation is critically important. Dr. Explain is an incredibly useful tool for this purpose, especially if your help files rely heavily on UI illustrations. Its automatic annotation capabilities perform nearly flawlessly, and cut the time required to generate screenshot-based help topic by several orders of magnitude.

A trial version is available that you may use as long as you wish. Until you register, you’ll be limited to five help topics per project, and all screen captures will be watermarked. While obviously not suitable for production work, it’s more that enough to let you try out the many features for yourself.

At $125 for a single-user license, Dr. Explain could easily pay for itself several times over in the scope of a single project, merely based on the amount of time saved. For $165, the Advanced License unlocks additional features you’re sure to find useful as well.

Wrox Blogs Are Now Live!

Lee Dumond — Thu, 22 Oct 2009 14:25:00 GMT

Wrox Press has added a blog site, featuring posts from authors and key staff, to its lineup of great programmer resources.

Just a quick post to let you all know that as of this week, the long-awaited Wrox Blogs are now live at the Wrox Press website. The next time you visit, be sure to note the prominent link on the home page menu.

There are only a few of us there right now, but that number is sure to grow as more of your favorite Wrox authors jump on board.

The guidelines that Wrox has given us in regards to content is pretty wide open, as long as the topics are programming-related, or related to our writing or editing activities. I hope to use my own little corner on the Wrox Blogs to supplement the material I’m publishing here, especially that having to do with Wrox stuff that I’m reading, writing, or editing.

If you’re a subscriber to LeeDumond.com (and if you are, I sincerely thank you), you might want to consider subscribing to the Wrox blog as well, to make sure you’re getting all the good stuff!

Subscribe to my Wrox Blog
Subscribe to all the Wrox Blogs

As I hope to be starting on a new book very soon, I’m sure I’ll have lots of cool things to write about. Stay tuned!

Integrating Exception Handling Into the Development Cycle

Lee Dumond — Wed, 14 Oct 2009 13:46:00 GMT

The time to start thinking about exception handling is right after you click File > New Project. Exception handling shouldn't be something you "tack-on" to an application after the fact. Here, I discuss a practical approach to incorporating exception handling into the normal code-writing process.

Recently, my friend Jef Claes wrote me via my contact page. In part, his inquiry reads:

In which part of the development cycle, do you have to start thinking about exception handling? How and when do you decide which exceptions to handle specifically, so they won't kill your whole page?

Geesh… I post a few articles and write a book about exception handling, and all of a sudden I’m Mr. Exception Guy. ;)

In all seriousness though, this is a great question. There are lots of resources out there that provide information about exception handling from a theoretical or academic point of view, but very few that present a practical approach to integrating exception handling into your day-to-day development cycle.

Here, I’d like to present my own general approach to exception handling.

Examine the Possibilities

I have written before about the importance of handling only specific exceptions. Of course, you can’t do that unless you know what exceptions could be thrown from your code. That means the first thing you should do is to discover which exceptions are possible.

How you do that depends on the framework or API you’re using. If you’re using the .NET Framework, the MSDN can tell you which exceptions might be thrown from any given method, constructor, property, event, or indexer.

Consider the following simple code, which writes a string of text to a text file. The string of text to write (txtEntry.Text), as well as a portion of the path value (txtPath.Text), is supplied by the user.

private void LogEntry()
{
   string workingDirectory = ConfigurationManager.AppSettings["directoryToLog"];

   if (!string.IsNullOrEmpty(workingDirectory))
   {
      string path = workingDirectory + txtPath.Text;

      using (StreamWriter writer = File.AppendText(path))
      {
         writer.WriteLine(DateTime.Now.ToString());
         writer.WriteLine("Entry: {0}", txtEntry.Text);
         writer.WriteLine("--------------------");
      }

      lblMessage.Text = "The entry " + txtEntry.Text + " was logged successfully.";
   }
   else
   {
      lblMessage.Text = "The required configuration setting is missing. The entry " + 
         txtEntry.Text + " was not logged.";
   }      
}

We can see the first call is to ConfigurationManager.AppSettings. If you place your cursor on the method in the IDE, the Dynamic Help window will show you a link to the method in the MSDN.

Clicking on this link will take you to the relevant MSDN page. The MSDN will show you any exceptions that could possibly be encountered from accessing this property.

Doing the same with the File.AppendText method yields the following result:

Finally, the WriteLine method shows the following:

As you can see, the Visual Studio IDE and accompanying documentation makes this pretty easy. Keep in mind that when you’re calling a third party API, your experience will definitely vary. A well-written API should include XML documentation that exposes via Intellisense any exceptions that could be thrown; and if you’re lucky, compiled documentation created by a tool such as Sandcastle. If not, you have to rely on whatever the API provides, or perhaps use Reflector to disassemble the binary.

Program Defensively

Now that we have a list of all the possible exceptions that can be thrown from our code, the next step is to determine which exceptions we can prevent, and which we can safely ignore.

In this case, we are supplying part of the path in the configuration file, and this branch of code only runs if that value is not null or empty. Therefore, we can be 100% certain that the argument we pass to File.AppendText will never be null. This lets us safely ignore ArgumentNullException from the File.AppendText method.

Next, we can employ defensive programming techniques to prevent most of the remaining exceptions that can be thrown from File.AppendText. By restricting and validating the user input, you can assure that the path supplied by the user can never be too long, contain invalid characters, or be in an invalid format. This relieves us from having to handle ArgumentException, PathTooLongException, or NotSupportedException. That leaves us two possible exceptions we might have to deal with.

Now, let’s consider the two exceptions that can be thrown from the TextWriter.WriteLine method. The first, ObjectDisposedException, can’t happen in this code because all of the WriteLine calls are made prior to closing the writer; so we’ll ignore it. The second, IOException, would normally be thrown in response to a disk or path error. Since we can’t prevent this from happening in code, this exception is a good candidate for handling.

Determine Which Exceptions To Handle

So far, we’ve taken two steps. First, we identified all possible exceptions. Second, we determined which exceptions can be either effectively prevented or safely ignored.

The remaining exceptions we have to worry about are:

ConfigurationErrorsException (from ConfigurationManager.AppSettings)
UnauthorizedAccessException (from File.AppendText)
DirectoryNotFoundException (from File.AppendText)
IOException (from writer.WriteLine)

Now, we must decide which of these we can and should handle, and why.

There are legitimate reasons for handling exceptions. Among these are:

Notifying the user, and if appropriate, allowing them to retry the operation
Wrapping the exception in a new exception, appending additional relevant detail
Wrapping a specific exception in a more general exception to prevent revealing sensitive details, such as exceptions thrown from a Web service
Using a finally block to clean up resources that might be abandoned if an exception occurs

In this simple example, notifying the user is probably sufficient.

private void LogEntry()
{
   string workingDirectory = null;

   try
   {
      workingDirectory = ConfigurationManager.AppSettings["directoryToLog"];
   }
   catch (ConfigurationErrorsException)
   {
      lblMessage.Text = "There was a problem accessing the configuration settings. The entry " +
                        txtEntry.Text + " was not logged.";
      return;
   }

   if (!string.IsNullOrEmpty(workingDirectory))
   {
      string path = string.Empty;

      try
      {
         path = workingDirectory + txtPath.Text;

         using (StreamWriter writer = File.AppendText(path))
         {
            writer.WriteLine(DateTime.Now.ToString());
            writer.WriteLine("Entry: {0}", txtEntry.Text);
            writer.WriteLine("--------------------");
         }

         lblMessage.Text = "The entry " + txtEntry.Text + " was logged successfully.";
      }
      catch (UnauthorizedAccessException)
      {
         lblMessage.Text = "You do not have the required permissions to access the path " +
                           path + " . The entry " + txtEntry.Text + " was not logged.";
      }
      catch (DirectoryNotFoundException)
      {
         lblMessage.Text = "Part of the path " + path + " was not found. The entry " +
                           txtEntry.Text + " was not logged.";
      }
      catch (IOException)
      {
         lblMessage.Text = "There was a problem accessing the path " + path + " . The entry " +
                           txtEntry.Text + " was not logged.";
      }
   }
   else
   {
      lblMessage.Text = "The required configuration setting is missing. The entry " + txtEntry.Text +
                        " was not logged.";
   }
}

Note that we’re tailoring the message sent back to the UI to be as informative as possible, without using the original Message property from the handled exception. While the Message property is quite useful for logging and debugging purposes, I generally find it’s not a good idea to pass a framework-generated exception message to your end users. For one, they often tend to be rather cryptic to non-developers. More importantly, it’s possible they could contain sensitive information. While the .NET Framework itself is pretty good at not revealing sensitive information in Message, you’ll find that many third-party APIs are not nearly as conscientious in this regard.

Also note that the order in which you handle exceptions can be important. Here we’re handling DirectoryNotFoundException before IOException. This is because DirectoryNotFoundException is a derived type of IOException, and derived types should always be handled first.

Do or Do Not. There is No Try.

If you can’t successfully handle an exception in code, it is best to let the application fail as quickly as possible.

I can hear some of you now: “What? Are you suggesting that we should let our applications fail?”

The answer is yes… that is, in fact, exactly what I am suggesting.

Part of handling exceptions successfully is facing the fact that you cannot successfully handle everything. Remember, an exception being thrown means your application has already crashed. Sometimes it is possible to handle the exception, giving the application a chance to recover or to retry the operation. Quite often though, you will encounter exceptions for which no sensible handling strategy exists, in which case catching the exception is totally pointless. Only catch exceptions which you are prepared to handle; otherwise let them go.

If you catch exceptions which you subsequently do not handle – usually through the use of general catch blocks – you merely postpone the inevitable. Allowing an application to continue in the face of an unhandled exception is not only wasteful, it’s dangerous. Values might be corrupted. Resources might be left in an unstable or unknown state. This is exactly why exceptions are thrown in the first place – to prevent a program from continuing under these conditions. If you can somehow correct or recover from the condition, then fine. If you cannot, then failing quickly is the best option.

Fail Gracefully

The fact is that in a production application, you never truly let any exception remain “unhandled” in a technical sense – the real question is not whether to handle exceptions, but where to handle them.

What I’m saying here is that you need to make absolutely sure you have a global exception handling mechanism in place. In a Windows application, that usually means handling the AppDomain.CurrentDomain.UnhandledException event. In an ASP.NET application, it means handling the HttpApplication.Error event, either manually or via the built-in ASP.NET default exception handler. This “last-chance” global handler lets you provide a friendly user experience when unrecoverable errors occur, as well as a central location from which to log exceptions that weren’t handled by your code.

Of course, once an exception reaches your global exception handler, it means execution has stopped and your application has failed. That happens – and as we’ve learned, sometimes there’s nothing you can do about it. But there’s no reason your application can’t fail gracefully.

Summary

In this post, I’ve outlined a series of steps you can use to sensibly and effectively integrate exception handling into the development cycle. These can be summarized as follows:

Use the available documentation to discover which exceptions are possible.
Determine which exceptions you can safely ignore, based on current state.
Where possible, use defensive programming techniques to prevent exceptions from being thrown.
Determine which of the remaining exceptions you should handle, and develop a strategy for doing so.
Allow any exceptions you cannot completely handle in code to propagate to your default exception handler.

This, in a nutshell, pretty much sums up how I approach exception handling as I write code. Hopefully, you’ll find this useful in your day-to-day routine as well.

Questions? Constructive criticism? Suggestions for improvement? Please let me know what you think in the comments below.

ASP.NET Profiles in Web Application Projects

Lee Dumond — Thu, 08 Oct 2009 11:45:00 GMT

Accessing ASP.NET profiles from a web application project is remarkably easy once you know how. Here’s how it’s done, along with a fully working implementation that you can download.

Earlier this year, I blogged about how to create a strongly-typed Profile that could be accessed from a class library. In response to popular demand, today I’m presenting a similar (but more substantial) example geared specifically toward accessing profiles in web application projects.

There are plenty of blog posts that talk about this, but unfortunately very few that show how to do it. Most of them instead refer to this relatively obscure add-in for Visual Studio 2005 (apparently. you’re out of luck if you’re using Visual Studio 2008). However, the good news is you don’t need a third party add-in or build task for this, as implementing this functionality yourself is not difficult at all.

If you’re reading this, I’ll assume you’re aware of the differences between an ASP.NET web site and a web application, so I won’t go into the various differences in great detail (feel free to consult the MSDN for more information). For our purposes, it’s just important to understand that in a web application project, there is no ProfileCommon class or Page.Profile property to work with, as we’re accustomed to seeing in web site projects – hence the problem.

Web site projects accomplish this bit of magic through dynamic compilation – essentially creating the needed objects at runtime, “on the fly” as it were. In effect we will be doing the exact same thing, but the old-fashioned way – with a simple hand-written proxy class.

Writing a Profile Proxy Class

Let’s assume for the sake of discussion that we have several bits of user information we want to store in profile.

first name
last name
date of birth
gender
the user’s time zone
the user’s preferred culture

Now, we could store these as separate value types, but in practice I find it easier to group related properties together in a class. So let’s create a class Personal to store the first four properties, and a class Preferences to store the time zone and culture. Make sure to decorate these classes with the [Serializable] attribute.

namespace LD.Sample.BLL
{
   using System;

   [Serializable]
   public class Personal
   {
      public string FirstName { get; set; }

      public string LastName { get; set; }

      public DateTime DateOfBirth { get; set; }

      public Gender Gender { get; set; }
   }
}

namespace LD.Sample.BLL
{
   using System;

   [Serializable]
   public class Preferences
   {
      public string TimeZone { get; set; }
      
      public string Culture { get; set; }
   }
}

Next, we’ll write a class that will define the profile we want, incorporating the two custom types shown above as properties. This class will inherit ProfileBase . Let’s call it CustomProfile.

namespace LD.Sample.BLL
{
   using System.Web;
   using System.Web.Profile;

   public class CustomProfile : ProfileBase
   {
      public Personal Personal
      {
         get { return (Personal) GetPropertyValue("Personal"); }
      }

      public Preferences Preferences
      {
         get { return (Preferences) GetPropertyValue("Preferences"); }
      }

      /// <summary>
      /// Get the profile of the currently logged-on user.
      /// </summary>      
      public static CustomProfile GetProfile()
      {
         return (CustomProfile) HttpContext.Current.Profile;
      }

      /// <summary>
      /// Gets the profile of a specific user.
      /// </summary>
      /// <param name="userName">The user name of the user whose profile you want to retrieve.</param>
      public static CustomProfile GetProfile(string userName)
      {
         return (CustomProfile) Create(userName);
      }
   }
}

Note that I’ve also included two overloaded static GetProfile methods. GetProfile() lets us obtain the profile of the current user, while GetProfile(string userName) lets us get the profile of a specific user (for administrative purposes, or when creating a new member, for example).

One more thing – and this is very important – we need to define the provider in web.config.

<profile defaultProvider="LD.SampleWAP.ProfileProvider" inherits="LD.Sample.BLL.CustomProfile">
<providers>
   <add name="LD.SampleWAP.ProfileProvider"
   type="System.Web.Profile.SqlProfileProvider"
   applicationName="/"
   connectionStringName="LocalSqlServer"/>
</providers>

You’ll see that our provider is of type System.Web.Profile.SqlProfileProvider. Of course, this assumes that the database to which this is pointing has been configured with the schema required to support SqlProfileProvider.

Also note the inherits attribute in <profile>. This is what tells the provider where to obtain the profile properties – in our case, from the CustomProfile class. When you do this, you do not want to define the properties declaratively in web.config, as you would in a website project. If you do, you’ll get a System.Configuration.ConfigurationException, informing you that the profile property has already been defined.

Usage

And that, believe it or not, is all there is to setting up a strongly-typed profile for use in a web application project. Now, let’s take a look at how you can use this newly-implemented goodness.

Here is some code that shows setting profile values for the currently logged-on user.

CustomProfile profile = CustomProfile.GetProfile();

profile.Personal.FirstName = "Tami";
profile.Personal.LastName = "Gharst";
profile.Personal.DateOfBirth = new DateTime(1972, 7, 10);
profile.Personal.Gender = Gender.Female;
profile.Preferences.TimeZone = "W. Europe Standard Time";
profile.Preferences.Culture = "de-DE";

profile.Save();

Here is some code that shows setting profile values for a specific user with the user name “Lee”.

CustomProfile profile = CustomProfile.GetProfile("Lee");

profile.Personal.FirstName = "Lee";
profile.Personal.LastName = "Dumond";
profile.Personal.DateOfBirth = new DateTime(1961, 10, 9);
profile.Personal.Gender = Gender.Male;
profile.Preferences.TimeZone = "Central Standard Time";
profile.Preferences.Culture = "en-US";

profile.Save();

If you like, you can make this even simpler by adding a Profile property to the page you’re working with – or even better, inherit your pages from a base type and add it there, so it’s available to all of your pages. This lets you set and retrieve profile properties with the familiar ASP.NET web site syntax.

// set profile properties

Profile.Personal.FirstName = "Lee";
Profile.Personal.LastName = "Dumond";
Profile.Personal.DateOfBirth = new DateTime(1961, 10, 9);
Profile.Personal.Gender = Gender.Male;
Profile.Preferences.TimeZone = "Central Standard Time";
Profile.Preferences.Culture = "en-US";

Profile.Save();

// display profile properties

lblDisplay.Text =
   string.Format(
      "User {0} had a real name of {1} {2}, was born on {3}, lives in the {4} time zone, and has a preferred culture of {5}.",
      Profile.UserName, 
      Profile.Personal.FirstName, 
      Profile.Personal.LastName,
      Profile.Personal.DateOfBirth.ToShortDateString(),
      Profile.Preferences.TimeZone,
      Profile.Preferences.Culture);

Sample Application

As I mentioned, I’ve included a downloadable web application solution that demonstrates web application profiles in action. When you run it, you’ll be greeted by the following screen:

There are screens that let you display a profile, edit a profile, and create a new one.

Examining the source code, along with the preceding explanation, should make understanding these concepts a snap.

I hope this helps the next time you find yourself needing access to profile properties from a web application!

Download sample code: WebApplicationProfileSample.zip

One Year Later – What I’ve Learned About Blogging

Lee Dumond — Thu, 01 Oct 2009 13:00:00 GMT

Today marks the one year anniversary since I started this blog. That being the case, I guess it’s time for the obligatory blogiversary retrospective.

October 1, 2008 was the day I arrived rather late and somewhat grudgingly to the blogosphere. One year later, I can honestly say that starting a blog was the best thing I’ve ever done for my career. My only regret is that I didn’t do it a whole lot sooner.

A year ago, I found myself in a somewhat awkward position. As a developer, I had welcomed and fully embraced the Web 2.0 concept; but as a user, not so much. The whole MySpace craze totally passed me by. I didn’t have a Facebook page (still holding out on that one), nor a Twitter account (I finally got one this past May). Social networking was just not my thing, thank you very much, and up until then I had been perfectly fine with that. But I was now starting to realize that the lack of interaction with the rest of the development community at large was holding me back.

Blogging was something I wanted to try. But whenever I gave the idea any serious consideration, I found it much easier to come up with reasons why starting a blog was just a bad idea.

What if I can’t think of anything to write about? The web is littered with the dusty, desiccated remnants of broken blogger dreams – good folks who I’m sure had the best of intentions, but just ran out of stuff to say.

What if nobody cares? In many ways, the blogosphere is like a college frat party – obnoxious, kind of smelly, and entirely too loud. What would be the point of shouting over the din if no one is listening?

What if I don’t have the time, patience, and dedication it takes? To me, starting a blog meant I was taking on a responsibility – to myself, and to my readers. I knew I would have to approach this thing like I do everything else – all in, or not at all. I set myself a goal of one post per week, which I hoped wasn’t too unreasonable given my already-overflowing schedule.

What if I’m just not smart enough? The fear of being wrong is probably the number one reason I hesitated for so long. I was afraid that by publishing a blog, I would discover how truly ignorant I really was. Worse yet, I would be broadcasting that fact to the entire world in the process! It’s one thing to be stupid, but nobody wants to look stupid – especially in front of their peers.

What I’ve Learned

Running this blog has been a wonderful learning experience. The past year has granted me a good deal more perspective – on the blogging process, on the developer community, and on myself as a human being. It’s been both frustrating and rewarding, discouraging and enlightening, in ways I never imagined. It has taken sacrifice, and brought pleasure and joy; both in great measure.

So, were my initial trepidations justified? In some cases, they were. In case you’re wondering, here’s how it’s all turned out so far.

I have more things to write about than I’ll ever have time to get to. Looking back, it’s hard to believe now that this was ever a concern – quite frankly, once the ball got rolling, ideas started hitting me on the head like seagull shit at a French-fry factory. Software development is such a vast, all-encompassing field that I don’t see how it’s possible to run out of topics. For every blog post I actually publish, there are probably half a dozen others that won’t ever leave the confines of my brain, simply for lack of time. I believe if you are curious, open to learning new things, and try to remain aware of developments in your chosen field, coming up with blog post ideas should be the least of your problems.

Nobody cares, and that’s okay. As a blogger, I think the sooner you come to grips with this, the better – nobody cares what you have to say. You aren’t changing the world. You aren’t curing cancer. Hell, you’re not even curing toe fungus. If you never wrote another post, the world would keep on turning and people would keep on living their lives like you never even existed.

If you can get your head around that fact, and keep on writing anyway, then you have a shot at becoming a successful* blogger.

It’s a lot of work, but it’s worth it. How much of a time commitment is really involved? There’s a lot of variation here – some posts take an hour, others take days – but I’d say on average, a decent blog post takes me about four hours to write. That’s not a trivial consideration. I have been posting about once a week this far, which is about two full work weeks a year. Something has to give. For me, it’s meant fewer long bike rides, less watching TV, and in some cases less time with friends and family. If you run a blog, how much of a sacrifice you’re willing to make is up to you; just be aware that you will have to make one.

What I don’t know could fill a bus. I have found blogging a very humbling experience. If I could sum up what I’ve learned about myself through blogging in one sentence, it would be this: I know a hell of a lot less about software development than I ever realized.

In fact, with each passing day, the amount of stuff I know I don’t know seems to increase. That may not sound like progress, but actually it is. As former Defense Secretary Donald Rumsfeld once said:

… as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know.

This is a concept so stupid, it’s brilliant. I don’t think I could sum it up any better.

The Meaning of Success

*In blogging, like in any activity, determining whether you’re “successful” depends on exactly how you define success.

Am I a successful blogger like Jeff Atwood is a successful blogger, or like Scott Hanselman is a successful blogger? Of course not. I harbor no delusions in this regard, current or future. Sure, I’ve built a pretty loyal subscriber base and I’m getting good traffic; and yes, I’m proud of that. Subscriber counts and traffic are certainly valid ways to measure success, but they aren’t the only way.

How about community recognition? I see that Jurgen Appelo recently published this quarter’s Top 200 Blogs for Developers list. Am I unsuccessful because I didn’t appear on it? I don’t think so, though I vow to keep trying (you hear that, Jurgen? ;) Despite that, a few of my posts have garnered a good deal of attention, and that’s pretty awesome. The validation of your peers is another valid way to measure success – but again, it’s not the only way.

If the efforts I’ve made on this blog can be considered successful in any sense, it is this:

Today is October 1, 2009 -- exactly one year later – and I’m still at it.

Happy Blogiversary to me. ;)

Orphans at the Bookstore

Lee Dumond — Mon, 28 Sep 2009 19:32:00 GMT

What do the companies who publish technical books – and the authors who write them – really owe their readers?

It’s rare to find an instance in which you pay good money for software, and are subsequently unable to find any kind of support whatsoever.

We’re not talking about freeware or open-source here (you can’t rightfully demand much handholding if you’re not paying for the product). No, we’re talking commercial software from well-established companies. If you’ve laid your money down, you rightfully expect the company to provide a modicum of support. If they don’t provide access to real live humans via telephone (fewer and fewer companies do these days), at least there’s an email address or support forum, often supplemented by a FAQ, knowledgebase, or wiki of some kind. Most of the time, that’s more than you need to get a question answered.

Software companies have to support the products they sell. Developers are expected to support the software they write.

So, why don’t technical publishers and authors feel obligated to support their own books?

If you’re like me, you’ve probably spent a pretty decent chunk of change on tech books, so you know what I’m talking about. Of course, there’s always the pretty sales page with a synopsis, table of contents, a place to download errata or sample code – and oh yes, that big shiny “Buy Now” button. But far too often, publishers provide no medium with which to provide meaningful feedback, to interact with the author(s), or to even ask a simple question pertaining to the book’s content.

It is unfathomable to me that, in an industry that relies so heavily on repeat business, publishers and authors have such little grasp on the concept of providing “service after the sale.”

To be fair, some publishers do take the extra step. Both Manning and Wrox, for example, publish online forums for the titles they sell. This goes a long way toward letting readers help other readers; sometimes, even mini-communities are formed. Unfortunately, neither company compels the authors themselves to participate or contribute. Other publishers seem to rely on the authors to “support” the book themselves – by supplying a link to an author’s blog, for example. Sometimes these authors oblige, though the level of enthusiasm, dedication, and responsiveness varies greatly. Sometimes, they don’t bother at all.

I suspect the reason publishers don’t obligate the authors to answer questions about their own books is a financial one. During my years as a contributing editor at Recording Magazine, authors were paid by the article. An email address was printed at the end of every piece, and most articles solicited a number of follow up questions from readers. Though the publisher forwarded these questions to the author, it was made abundantly clear that they were in no way obligated to answer them, because the company would not pay them extra to do so.

The stuff I’ve written for Wrox has solicited a fair number of questions, many of which come through the contact page of my blog. Wrox doesn’t pay me to answer them – but I do anyway, out of sheer pride and a sense of obligation to my readers. However, it’s painfully clear that many authors feel no such obligation. Once the advance is spent, the final draft is turned in, and the royalty checks start coming, they seem all too willing to put the project behind them. They just don’t feel as though the owe their readers anything.

What Can You Do? What Should You Do?

Given the current economic climate, asking publishers to shell out more dough probably won’t get us very far. But, depending on where you stand in the technical book food chain, you can play an active role.

If you’re a reader:

Reward publishers who provide opportunities to interact with authors and other readers, by making this part of your purchasing decision.
Favor authors who actively participate in publisher-provided forums.
Favor authors who supply supplemental or ancillary book material on their personal blogs.
Support authors who encourage feedback and are responsive to reader questions.

If you’re a publisher:

Provide an forum for readers to interact with editors, authors, and other readers.
Ask authors in advance if they intend to voluntarily support the book post-publication, and how they plan to do that. Make authors put this in writing as part of the book proposal.
Encourage authors to treat their work as a living, breathing project, and give them the means to help them do so.

If you’re an author:

Writing a book is like having a baby. Remember that the “construction phase” – difficult though it may be – is only the beginning.
Understand that technical books undergo a “life cycle” after they are published, and that the first few months after it hits the streets are the most critical. Actively engaging and interacting with readers early in this life cycle will pay off once the market for your book matures.
Seek out the places your book is being discussed – on the publisher’s website, on Amazon, on Twitter, and in the personal blogs of your readers. Remember, readers won’t always come directly to you with their thoughts, comments, and questions, but they will have them.
If you’ve published a sample application with your book, consider hosting your code in a online repository such as CodePlex. Encourage readers to submit bug reports and suggestions for improvements, and solicit their help in maintaining the codebase.
Keep the book alive on your own blog! If you’ve identified a pain-point readers are having, a particular section that bears further explanation, or an assertion that’s being challenged, put up a post about it. Justify the decisions you’ve made and the conclusions you’ve drawn, and be open-minded to reader comments expressing other points of view.
Think of your own bottom line! If you aren’t proud enough of your work to support it for any other reason, do it because it will help sell more books.

You wouldn’t think of buying a car, a refrigerator, or a piece of software without the promise of some kind of support if you need it, would you? Yet for some reason, we do this all the time when buying technical books, seemingly without hesitation.

Think about that the next time you’re about to carry your new-found tome to the cash register, or click that big shiny Buy Now button. Otherwise, the book you’re purchasing may barely be worth the paper it’s printed on.

Chocolate Salty Bools

Lee Dumond — Tue, 22 Sep 2009 22:42:00 GMT

A couple of Boolean-related anti-patterns, and what to do about them.

You’ve probably noticed a lot of bloggers use their platform to vent their frustrations. This is one of those posts.

I happen to be working on a brownfield application that manages a repair shop for motorcycles. I don’t mind telling you that this particular application is a deep, dark shade of brown, and I don’t mean because it just came back from Disney World.

Modeling a business process like this often involves tracking the current state of various domain objects. The code here uses enumerations to express those states, which is a good thing. Enumerations are much more expressive than integers, far more type-safe than magic strings, and can help eliminate a lot of messy switch statements and such from your code. But one of the issues with this app is that it’s full of two-valued enumerations, like this:

namespace RepairShop
{
   public enum ServiceStatus
   {
      InService,
      ServiceComplete
   }
}

Upon first glance, this makes sense. The repair status of a motorcycle can have two states. When you take in a broken one, you mark it “InService”. When you finish fixing it, you mark it “ServiceComplete”.

public class Motorcycle
{
   public ServiceStatus ServiceStatus { get; set; }
   public string TagNumber { get; set; }

   public void TakeInForService()
   {
      this.ServiceStatus = ServiceStatus.InService;
      this.Update();
   }
   
   public void MarkServiceComplete()
   {
      this.ServiceStatus = ServiceStatus.ServiceComplete;
      this.Update();
   }

   public void Update()
   {
      MotorcycleData.Update(this);
   }      
}

Oooo, That Smell

Looking at several of these enumerations, something didn’t seem quite right. It was then I realized something – two-valued enumerations are a code smell. I’ve never seen this in any code smell list I’ve ever read, but it definitely needs to be included.

A little bit of refactoring lets us simplify things, and eliminate the enumeration type from the codebase altogether.

public class Motorcycle
{
   public bool ServiceStatus { get; set; }
   public string TagNumber { get; set; }

   public void TakeInForService()
   {
      this.ServiceStatus = true;
      this.Update();
   }
   
   public void MarkServiceComplete()
   {
      this.ServiceStatus = false;
      this.Update();
   }

   public void Update()
   {
      MotorcycleData.Update(this);
   }      
}

The simple fact is that when any property has two and only two states, that property can always be typed as a Boolean. In or Out. On or Off. Black or White. If you’ve only got two choices, why not use a perfectly good, built-in two-valued type instead of making up a new one?

He Who Smelt It, Dealt It

But hold on a minute – this refactoring isn’t quite done. When examining the value of ServiceStatus in a Motorcycle object, one might naturally assume that ServiceStatus = true means “it’s bring worked on” and ServiceStatus = false means “it’s done.” However, this isn’t totally obvious, or even semantically meaningful. This leads us to another new code smell: Boolean Jeopardy.

Why “Boolean Jeopardy?” That’s because Boolean values are either true or false; and semantically speaking, true and false are responses to a yes-or-no question. Therefore, anything of type Boolean should always be named in the form of a question – more specifically, a binary (yes-or-no) question.

public class Motorcycle
{
   public bool IsInService { get; set; }
   public string TagNumber { get; set; }

   public void TakeInForService()
   {
      this.IsInService = true;
      this.Update();
   }
   
   public void MarkServiceComplete()
   {
      this.IsInService = false;
      this.Update();
   }

   public void Update()
   {
      MotorcycleData.Update(this);
   }      
}

You should apply this naming rule to anything that’s a Boolean: including fields, properties, bool-returning methods, even bit columns in database tables. A good way to do this is to try to start with the word ‘Is’ for booleans that apply to single entities, and ‘Are’ for collections.

internal class CookieProgram
{
   private static void Main()
   {
      IList<Cookie> cookies = Cookie.GetCookieBatch();

      if (AreCookiesDone(cookies))
      {
         RemoveFromOven(cookies);
      }
   }

   private static bool AreCookiesDone(IEnumerable<Cookie> cookies)
   {
      foreach (Cookie cookie in cookies)
      {
         if (!cookie.IsDone)
         {
            return false;
         }
      }

      return true;
   }

   private static void RemoveFromOven(IEnumerable<Cookie> cookies)
   {
      // blah blah blah
   }
}

Get the Funk Out

Okay, so we’ve identified a couple of Boolean-related whiffs, and come up with a couple of associated refactorings.

I call the first one Two-Valued Enumeration. Enumerations are very handy, but can be tricky to deal with in code, and can lead to unnecessary complexity when overused. Any two-valued enumeration can and should be expressed as a Boolean, which is a built-in, dual-valued primitive type. To eradicate this smell, apply the Replace Two-Valued Enumeration With Boolean refactoring.

When you do that, pay attention to the name you give your new Boolean, lest you end up with the Boolean Jeopardy smell. Since the values that a Boolean can hold are true or false, the names of Boolean entities (fields, properties, methods, database columns, and so forth) carry more semantic meaning when they appear in the form of a question. Apply the Rename Boolean As Binary Question refactoring to any offenders you find.

Happy refactoring, and thanks for letting me vent.

It’s a Self, Self, Self Serve World

Lee Dumond — Fri, 18 Sep 2009 17:37:00 GMT

How and why today’s companies boost productivity by using technology to tap a vast reserve of willing, free labor – you.

I’ll never forget the first time I got fired.

I was a kid in Portland, Maine, working as a gas station attendant. (Remember gas station attendants? Probably not, unless you’re over 35.)

Anyway, after a long and arduous ten-hour shift standing in the rain and sucking fumes, I balanced my “cash drawer” (which was in reality the pockets of my jeans) and came up 50 cents short. Fifty cents. I had pumped nearly 2,000 gallons of gas that day, but that didn’t matter. In the eyes of my boss, fifty cents short was fifty cents too much.

The rule at this place was simple – if your cash didn’t balance out, you were gone, period. The company who owned this station ran several dozen other stations just like it, and I guess they figured that two bits here and two bits there might eventually, somehow, add up to real money.

It was a few years later that this company installed self-serve automated pumps in all of their stations, and fired every attendant in their employ. No more attendant wages. No more of the associated worker’s comp premiums, unemployment premiums, or matching FICA payments.

Productivity swelled. The company literally saved millions, which they eagerly pocketed as profit. And guess what? They never came up short on a shift again, either.

Did these automated pumps eliminate the actual task of getting the gasoline out of the ground and into the cars? Of course not. But now, the station was able to demand that customers do that. Oh sure, some were reluctant at first. But as soon as they realized that every station in town was jumping on the self-serve bandwagon (hey, gas station owners are no dummies), the options were pretty clear – open your own petroleum refinery, take the bus, or learn to deal with the indignity of being coerced into service as a lowly part-time pump jockey. Suck fumes or walk, pal.

Little did we know that self-service gasoline was only the tip of the iceberg.

The first automated pumps were expensive and s – l – o - w, communicating at 300 baud over regular lines leased from the local telephone company. But like all technology, pumps became much cheaper, much faster, and much more capable. Running a station became more profitable than ever. More and more stations opened, and larger stations soon became the norm.

The Great Productivity Myth

It was not long before other industries sat up and took notice.

Today’s businesses aren’t saddled with the burden of massively expensive hardware and dog-slow data transmission. PCs are practically disposable, servers are dirt cheap, and bandwidth is now a commodity. This revolution in hardware, combined with the big ol’ Inter-tubes and the technologies that run on it – the World Wide Web, email, and the rest – is allowing enterprises of all kinds, from the airlines to your local grocery store, do what the gas stations did.

They too have enjoyed unprecedented gains in productivity. If you asked their accountants how, they’d tell you they did it the old-fashioned way – by reducing costs. From an financial point of view, that's technically correct. But from a societal point of view, true costs are not being reduced at all, but merely shifted off the books – a macroeconomic sleight-of-hand that places inputs outside the purview of the enterprise.

In any capitalistic endeavor, the most expensive input by far is labor. Here in the US and elsewhere throughout the developed world, the cost of labor per dollar’s worth of output is dropping precipitously. Is this because there’s less work to be done? Or is it because true labor costs aren’t being accounted for?

Think of it this way – if I pay a high-school kid to put my gas into your car, that’s a cost to me. If I get you to do it, it’s not. The gas is still getting into the car, but this way, nowhere on my books do I have to account for that fact. See how that works?

Artificial Artificial Intelligence

With each passing year, American consumers are becoming increasingly pressed into a form of consumption-based indentured servitude, made possible by cheap hardware, cheap connectivity, and cheap, ubiquitous Internet access, and businesses are reaping the benefits.

Twenty years ago, if you had an issue with your bank account, you’d ask a teller. Today, you are instructed on how to find that information yourself; in fact, many banks now charge a fee to even speak to a human teller. Fifteen years ago, most people wouldn’t have dreamed of booking their own airline flight. Today, not only are we expected to book our own travel as a matter of course, we print our own itineraries and our own boarding passes, and check our own bags, too. Grocery stores with manual checkouts are served by one casher per terminal. In those now installing self-serve checkouts, a cashier handles six terminals. May God help you if the sticker falls off your banana.

In the tech world, not all that long ago, it was just assumed that knowledgeable, competent technical support was never more than a phone call away. Today, if you are fortunate, the company you’re dealing with may offer a support “package” – one that requires you to pay for the privilege of speaking to a human, and pay even more if you want to assure that human speaks the same language as you. Free technical support has now been pushed entirely online, to be found in the form of incomprehensible wikis, outdated FAQs, esoteric so-called “knowledge” bases, or online forums where customers are not only required to help themselves, but are encouraged to devote their spare time helping each other, perhaps predicated on the belief that when frustrated users find themselves in the same boat, they will attempt to row together.

The Web has turned us into our own bankers, our own travel agents, and our own support desks. It has turned investors into their own brokers, students into their own teachers, and patients into their own doctors. While many of us continue to perceive the Web as a communications/entertainment/social networking medium, many businesses clearly see it as something else – a means of leveraging a motivated, compliant, highly scalable workforce on-demand; in effect, a giant Mechanical Turk.

I’m certainly not saying that this is all bad. Like most people, I enjoy the convenience of being able to check my bank balance online, for example. That is what the Web is good at – pushing data around. That is, in fact, the only thing the Web is good at. If you can take a problem and accurately express in terms of a simple data transaction, then that’s a good Web application.

The problem lies in how organizations are attempting to shove increasingly complex domains into this simple exchange-of-data paradigm. Consider, for example, the fast-growing trend among colleges and universities toward self-service education – supplanting the traditional classroom lecture with online “instruction.” Standardized, cookie-cutter lesson plans allow the use of lower-paid, less qualified faculty. More students can be registered per session. There are fewer facilities to maintain, and no classroom to heat or light. The school then uses the “convenience factor” to justify exacting an additional “technology fee.”

In this scenario, the university wins, but the students lose. That's because online instruction is an imperfect, incomplete model of the real-time, physical, face-to-face interaction that normally takes place between students and teachers, and among students themselves. Forums, chat rooms, and email are merely tools used to emulate the organic nature of a real classroom. In this case, the exchange of data simply cannot truly replicate the exchange of knowledge, or of ideas, or of service; but can only serve as a dim digital approximation thereof.

Pay No Attention to the Man Behind the Curtain

In a world where institutions of all kinds have long ago squeezed every penny out of the supply chain, those institutions are being compelled to automate more and more of their processes in order to boost productivity, which brings us to the real issue – the inexact and imperfect art of modeling complex “meat-world” business processes and transactions in software. Since all software can do is manipulate data, the success of a given solution lies in how well it models its problem domain as data.

When it comes to checking my bank balance or transferring funds, the Web is great. That’s a pretty simple transaction; one that can be expressed perfectly in terms of ones and zeros.

However, with more complex processes such as educating our students, as we’ve just seen, technological models often fall short.

And in those frequent situations when a piece of the domain puzzle can’t be modeled inside the system at all (think gas pumps here), it then falls upon the actor in that particular use case (read: you) to provide the missing “functionality.”

Futurists once told us that “smart machines” would one day open up a utopian world of decadent leisure, but that's not happening. Let's not kid ourselves. We’ve seen the future, in which the old dreams of artificial intelligence are being replaced by a new reality in which “intelligent” systems use thier own users as actual components in the application.

Welcome ladies and gentlemen, to the super-duper, ultra-convenient, self, self, self serve world. It appears we have truly found the ghost in the machine, and it is us.

Balsamiq – It’s Not Just For Salad Anymore

Lee Dumond — Fri, 04 Sep 2009 19:51:00 GMT

A true balsamic vinegar – the traditional, top-shelf, aged for 12 years stuff – is highly prized by foodies all over the world. Balsamiq Mockups, while it doesn’t taste nearly as good on salad, is quickly becoming just as invaluable to developers, designers, PMs, and anyone else involved in the creation of software. Here’s why.

Balsamiq Mockups is the flagship product from startup ISV Balsamiq Studios. The desktop version (which I’m reviewing here) runs on any platform supported by Adobe Air, including Windows, Mac, and Linux (yes, finally, an Adobe Air application that’s not a Twitter client – go figure). There are also plug-in versions available that integrate with popular wiki and bug-tracking tools such as Confluence, JIRA, XWiki, and FogBugz. A online, subscription-based version is reportedly in the works as well.

What’s the Problem?

This is the point where most reviewers would drag out the elaborate dog-and-pony show, but I’d prefer not to waste time better spent ~~abusing~~ evaluating the demo on your own. Rather than delve too deeply into all the little tricks Balsamiq can do, let’s consider for a moment the problem it is intended to solve.

Pretend if you will you’re a software developer (if you’re reading this, that shouldn’t be too much of a stretch, right?) and you’re meeting with a few client reps to toss around some early prototype ideas for an application. You (or someone from your design team) have labored long and hard to put together a few slick-looking layouts, hoping to impress.

You hook your laptop to the conference room projector, fire it up, hit F12, and…

Developer (you): Here’s an initial idea of what we thought should be included on the home page…

Client1: Oooh – what shade of green is that? I don’t like that green background at all. Who said we were going with green?

Developer: We don’t have to go with green. Keep in mind, this is just a sample. The important thing is to focus on the elements in general at this point.

Client2: Our old site had small, boring-looking buttons. I like that you’re using image buttons, but those are still much too small.

Developer: Bigger image buttons. Got it.

Client2: Can we see what a larger image button would look like there at the bottom?

Developer: Well, not right this minute. We don’t have any larger images prepared, but I’ll make a note of that for the next meeting.

Client1: What color are the image buttons going to be? They can’t be red, especially with that green background.

Developer: As I said before, the colors aren’t really that important for the time being. We’re just trying to get an idea of…

Client3: Speaking for myself, I’d say this is right on the mark. Looks pretty much finished to me. Maybe a couple of small tweaks here and there. Do you think we can go live with this by the end of the week?

Developer: No no no, this isn’t even close to being done. I know it may look complete, but…

Client1: Sorry. I’m trying to focus here, but I just can’t get past that green background. Can we tone it down a bit? Maybe a drab olive would be nice.

Sound familiar?

As far as you’re concerned, the UI is just another piece of the software construction puzzle. But oftentimes, to the people who are signing the checks, the UI is the software. It is the piece of that puzzle they have the firmest grasp on, and thus is the aspect of the project over which they will want to exercise the most control. And because so much of the client’s focus is on the UI, a finished-looking front-end can easily give the impression that your mockup has actual code behind it, and is “practically done.”

The beauty of Balsamiq Mockups is that it’s a “wireframing” tool that intentionally uses hand-drawn UI elements. It’s quick-and-dirty, rough, and definitely lo-fi, and with good reason.

These mockups make it abundantly clear at which point you are in the development process. Nobody gets too hung up on pretty (or not so pretty) colors, shapes, or sizes, which lets stakeholders focus on functionality rather than looks. And the first-draft, “we just threw this together quickly” vibe encourages feedback – people will feel freer to offer criticism at this point, where they might be more reluctant to do so with something that looks like someone slaved over it for days. What’s more, you haven’t written a single line of code, or wasted a single minute of developer productivity creating fancy prototypes that will eventually find themselves consigned to the dustbin.

On many past projects, I’ve tried to create the same effect with pencil and paper. Unfortunately, I happen to be so artistically challenged that drawing even straight lines is tough for me, which means I end up going through a lot more erasers than pencils. Using Balsamiq feels like drawing. Balsamiq is just as fast as drawing (for me, it’s actually much faster). But since it’s digital, you can tweak, rearrange, and erase to your heart’s content.

While Balsamiq Mockups is a great tool for getting a lot of ideas down on “paper” quickly and cheaply, it really shines as a collaborative tool. Because the program is so responsive and simple to use, you can work on designs right in front of the client in real time. Can you make that button bigger? Done. Move that column? Done. How would the menu look on the left side instead of the top? There you go. It’s child’s-play-easy to iterate over a design in the course of a meeting, where PMs, designers, developers – and yes, even clients – can all throw in their two cents. Mockups can be exported as PNG images and shared or emailed, or coupled with online file-sharing tools for remote collaboration scenarios.

Besides the 75 ready-to-use controls that come with the application…

…you can create and add your own images – everything from custom controls specific to your project, to image-based backgrounds, entire layouts, and even screenshots of existing applications.

A Nit Or Two

You may be asking “can I export mockups to HTML, MXML, XAML, Ruby, etc.?” The answer is no… and yes. The program doesn’t offer native export capabilities to any other format than PNG. However, it cleverly leverages an open, well-documented file format (a variant of XML they’ve dubbed BMML) that lets third-parties (or even you, if you’re feeling froggy) provide such features. One such example is Napkee, which lets you turn your wireframes into fully-functioning HTML/CSS or Adobe Flex prototypes. Obviously, these third parties have employees who like to eat and have become accustomed to sleeping indoors, so these extensions will cost you a bit of extra scratch if you need them.

For the time being at least, users cannot add elements directly to the UI library, although the image import feature will suffice in most cases. Balsamiq includes a “sketch-ize” command that can wireframe imported images, imparting on them the same look and feel as the rest of the application.

Also, there’s no “Mockups Viewer” application which would allow the sharing of sets of linked prototypes with stakeholders who don’t have Mockups installed. This does inhibit collaboration to some degree; though once Balsamiq get the Mockups web version up and running, this should become a non-issue. No pricing for the web version has yet been announced, though I’ve heard rumors that peg it in the $12-or-so per month range (again, just rumors – please don’t hold them to it just because I said so).

One more thing – as you might have been able to tell from the screenshots above, Balsamiq makes heavy use of the Comic Sans font on Windows and Linux (Mercifully, Mac users get the Chalkboard font on OSX). I probably don’t have to tell you how much some people hate Comic Sans. Fortunately, the desktop version lets you swap out Comic Sans MS for any font on your system. If you do this, you’ll want to check out some hand-drawn alternatives, as not to lose Balsamiq’s low-fidelity GUI goodness.

Summary

If you’re still reading this, I have to ask: why? Check out the quick 3 minute introduction video, try the interactive Flash demo, download and install the demo version, or dispense with the formalities and just buy the damn thing for only $79 – that’s coffee money compared to what we spend on other tools that aren’t nearly as useful as this one. And while you’re at it, check out MockupsToGo, a user-contributed collection of UI components from which you can download additional controls or share those you’ve created.

I don’t review or endorse very many tools on this blog, but Balsamiq Mockups has become a must-have application in my development process, and one I feel confident in recommending. It’s a fantastic product from a great little company, that addresses a significant issue that almost all development and design teams have, and solves it beautifully. When it comes to developer tools, you can’t ask for much more than that.