Corporate tool choice: Why products beat tools every time.

Are you like me at all? Every time I see a "GoTo my PC" or "GoTo Meeting" commercial, I grind my teeth. These "hot new" technologies for Windows have been standard fare on UNIX for over 20 years, and yet UNIX is still viewed as unusable by many corporate types.

As a long-long term computer programmer and tech geek, I had always assumed that the reason that hacker-born tools don't get wide acceptance in corporate environments was because they didn't have salesmen schmoozing the VP into making badly informed policy decisions. This attitude is widespread among my kind, and, well, we're completely wrong.


I have one word for you, Joel: Bootstrapping.


Our geek-myopia is a product of our personal evolution: most of us learned under the wing of someone else. A teacher, guru, or just another geek learned something we thought was cool, and we learned it through conversations and one-on-one teaching..

Life in the dozens-to-hundreds scale

I'll fall back on a simile: the massive success of World of Warcraft. A prior game, Dark Age of Camelot, had better and more scalable PvP, more realistic rendering, and better in-game economics years before WoW even hit alpha testing. Despite that, WoW became an immediate hit. It emptied DAoC's servers almost overnight, with a product that was less "deep" and less stable.

How did they do that?

One difference was a single wart in WoW's graphical environment: the exclamation points hanging over questgiver's heads. They totally "broke the metaphor" of the virtual world, but they gave new users a very good idea where to click first. At that time in DAoC's visual environment, other players, inert NPCs and questgiver NPCs were almost indistinguishable, so there were no cues as to what to do/click first. Chasing after avatars that were players and trying to click on them was both very challenging, and yielded nothing anyway. (Clicking on a player didn't do anything) It was easy to get frustrated.

Further, WoW had extensive beginner quests where the dialogues led the new users through most of the basic parts of the game. The fact was that a new user completely unfamiliar with WoW could become a padawan in a matter of minutes. Not so in DAoC, where things as basic as the "r to reply" key were undocumented and you ended up using "/send blackhawk This conversation interface is really inconvenient" for ages until someone told you about the "reply" key.

If you had been given the task: "Get 80 people in your company to 10th level this Saturday", it would have been nearly hopeless in DAoC, and almost trivial in WoW.

The self-taught path is vital

When you're trying to get a corporation (think dozens or even hundreds of programmers) to use a new tool, there just isn't enough time to chat with all of them and bring them up to speed. A typical tool switch has to be pretty much complete in a week or so. In order to even approach this capability, the product absolutely must have a smooth, bulletproof, and thorough new-user bootstrapping experience. A man page, some screenshots, and an HTML monograph from the designer just aren't good enough to bring 50 people onto a new platform in a week, and that is really what large organizations require. It's not that they want it. They can't actually don't have more resources to throw at the switch and still keep their existing products working.


Many know the expression For want of a nail, the kingdom was lost.

I saw this in perfect detail today as I tried to get started using Eclipse. I saw Eclipse for the first time years ago in version 0.0.0.0.0.0.1 or thereabouts. I knew it was an IDE, I knew it was by-hackers-for-hackers and it was supposed to fill a similar space to Visual-Blarg from Microsoft.

Here's a tick-tock of my experience:

1. I install eclipse with "sudo apt-get install ..." onto my Ubuntu-10 desktop. It nicely adds a "Programming" submenu to "Applications", and places itself in that.
2. I start it up- and wait. For a distressingly long time, actually, before even the splash page appears.
3. It prompts me to pick a workspace directory before it will let me go any farther. This is clunky. It's essentially asking a configuration question before you can even get to the "help" screen to ask what you're doing. By analogy: DAoC used to make you choose the stats for your character before it told you what they did. Both are examples of cart-before-the-noobie processes.
4. It gives me a bigger splash screen with some icons. The upper-left one is marked "Overview". I click on it, which brings up a (very nice) Overview screen with a link "Workbench Basics". I click on that.
5. There is another long-ish pause while the help browser appears in another window. It's long enough that I click on the link a couple more times to make sure I did it right.
6. The help facility window appears, and everything goes to hell. Look at the next three screenshots, as I click on the links:

The "characters are cut off on the left edge" looked to me like bad HTML "div" formatting, so I blew it off and clicked on "Getting Started", then "Basic Tutorial"

Here I waited, and waited, for whatever video or content was supposed to come up next. Nothing. I clicked  backwards and forwards. I even used the (almost invisibly tiny) arrows in the upper right toolbar. The forward (right) arrow did nothing. No error, but no action. Weird that it wouldn't be greyed-out out if it did nothing, so I waited for a media player to pop up or something. Nothing. I tried clicking on the next entry (Concepts) but that obviously took me "too far". Well past the "Basic Tutorial" anyway.

After a long and frustrating series of clicks backward and forward, etc., I gave up and punted: I Googled "Eclipse Basic Tutorial" and found this page at UPenn: Getting Started with Eclipse which includes the useful tidbit:

This opens up and you can click on Basic tutorial, which is a link that opens a page that says "Basic tutorial" and little else.

Then it goes on to talk about "plusses" and clicking on them to open things up. I looked all over the image above for anything resembling a plus... no dice.

Status at this point in time: I'm at a dead stop trying to get to the "Basic Tutorial", with nothing obvious left to try. Even the Google search confirmed my problem but didn't give me a solution.

I assure you that at this point, anyone, anywhere, that is trying to make plans to bring 50 developers to a new platform like Eclipse will mentally up the cost in time and money by a factor of 5-10, which will essentially knock it out of contention.

And it's all because of a stupid help-screen UI issue... a horizontal scrollbar that defaults to a center position:

This seemingly minor glitch has hidden the "magic plus signs" which are the only possible route to the basic tutorial.

There are a variety of things that could be done to solve this:

1. Fix the help utility UI so it doesn't do that by default. Text missing ON THE RIGHT of the screen will get people looking for a scrollbar
2. Rework the minute upper-right scrollbar so that the buttons that do nothing are greyed/stippled and the "Show in Table of Contents" button (which is a hidden back-path to the magic plusses) is among the things people might click
3. Override the scrollbar's initial setting from the command line or environment.
4. Add a "Next Section" link (as occur in almost all of the other help segments) in the "Basic Tutorial" Page.

Items 1 and 2 are the essence of the sorts of things that should be simple, fast, and clean in open source software environments such as produce the help utility.

Items 3 and 4 are completely under Eclipse's control, and would be totally obvious... if the developers had detected the problem in the first place by watching someone new walk through the bootstrap process.

Lessons Learned

If "the good news" was that it wasn't an absence of salespeople, "the bad news" may be just as frustrating: Your bootstrap process is absolutely essential to your adoption in larger environments.

Hitting a hard-stop in your forward progress when you're familiar with a tool and trust it is a completely different thing than hitting a hard-stop trying to find your way to the tutorial. The former will result in a user experimenting, Googling, and chatting their way to a solution. The latter will get hands thrown in the air, and a return to the known-to-work alternative, regardless of how much worse it is.

As a programmer, I know that finding these kinds of things takes easily 20% as much time as is spent creating, testing, and polishing the tools in the first place, maybe even more, and I am loathe to spend that kind of time. But without that time getting spent, the tool might as well not exist as far as larger organizations are concerned.

Just something I noticed.