Steve McConnell wrote a great software development book, Professional Software Development. (Actually, in my opinion, Steve McConnell has written more great software development books than anyone I know, save perhaps Martin Fowler.) But before Steve wrote Professional Software Development, he wrote an earlier version called After the Gold Rush. The central metaphor there was that early in a gold rush, many people can get rich by picking up nuggets that are just waiting to be found; but that after those are gone, people can only succeeed by planning, building infrastructure, and working with more discipline to dig out the more difficult and hidden treasures. And he said that software development had moved past the gold rush stage, where great ideas were just waiting to be discovered. Newer advances will require a lot more effort to bring to fruition.

But that's in general. There are still niches where great ideas are just waiting for someone to make them happen. And one of those niches is Tablet PC applications. I contend that some really powerful Tablet PC apps are just waiting for the right developer with the right domain expertise and Tablet PC programming skills to open up a whole new market.

And since I'm hoping to teach you Tablet PC programming, I figure one way to get you interested is to throw out ideas of how you might strike gold with a Tablet PC app...

This first gold nugget comes courtesy of my friend Tom Lavey. He and his partner Charlie own L & M Precision Machine, Inc., of Pinckney, MI. (If you need high quality short runs of production turned small parts up to 1.625 inches in diameter, I highly recommend their work. And full disclosure: I'm their Web designer and administrator. But that's a volunteer position, so I don't have a stake in their work. I just think they do great work!) When I was trying to explain to Tom why Tablet PCs are so cool, he immediately envisioned my second-favorite example of a great Tablet PC app (right after Tablet UML). Loosely paraphrased, here's what he said:

So last week, we had the electrician come in to give us a quote on wiring up the shop. He took out a yellow legal pad, and he drew out a sketch of the layout. Then he asked us where the machines and equipment were going to go, and he drew in conduit, junctions, outlets, etc. And then when we were all done, he said, "OK. Let me take this back to the office, and I'll have a quote for you in three to five days.

Now if he had a Tablet PC, you're saying he could draw the same picture; but when he drew conduit or a junction or an outlet, the computer would know what he meant. It wouldn't be just lines, it would have meaning. And when he was all done, he could push a button, and out would pop an estimate. Is that about right?

And Tom was exactly right. (And yes, I'm still annoyed that a machinist saw this great example, and beat this programmer to the idea. Serves me right for having smart friends...)

Now let's flesh out Tom's idea a little bit:

• The electrician would start by drawing the building layout. For this, he'll need basic sketching capabilities, including various pens and colors, selection and erasing, the whole gamut of standard sketching tools.


• In addition to sketching, though, he'll need dimensioning. He should be able to tap or click a line in the layout and enter information about the wall length. He may also need to be able to add comments. For example, he may want to indicate the material a wall is made from, so that he knows how hard it will be to drill holes or snake conduit.


• The app should automatically clean and straighten lines, but the electrician should be able to turn this feature off.


• For drawing conduit and junctions, etc., the system should define a shape grammar, where particular symbols correspond to particular types of electrical equipment. As much as possible, the shape grammar should duplicate the notation the electrician is already using; but since I don't know that notation, I can't predict what compromises will be needed.


• The electrician should be able to click or tap a symbol and pop up a detail window. This should let him do things like indicate conduit length, make notes, and select from a list of alternatives (different types of junction boxes, etc.).


• There should be a database behind the app, providing the various alternatives that can appear in the detail window. Ideally, this should include latest pricing, and even live update via the Web (wireless, of course).


• The electrician should also be able to just sketch and just write notes, without any recognition. This lets him draw and write things the programmer never expected.


• There should be a Prepare Quote button. This should pop up a form that prompts the electrician to fill in any details he overlooked, and to make any choices of equipment type that he hasn't identified yet. When he answers all the questions and adds in any other charges he can foresee, the system will produce a quote. He can also email it to the client and to the home office.


• The app should let the electrician define business rules with regards to the quote. For example, some businesses may prefer not to give the client a preliminary quote until supervisors back at the office have approved it.

That's a start. I'm sure there's more this app should do; but I'm not an electrician, I don't know the domain, and so I can't define it better. But if you can, I can teach you how to write it.

Presented free of charge (and also without support, just so we're clear up front): Tracking Systems, a game for the Tablet PC.

Now let me repeat that up front, more clearly: Tracking Systems will only run on true Tablet PCs running Microsoft Windows XP, Tablet PC edition, and upgraded to version 1.7 of the Tablet PC API. If you try to run it on anything else, it's not going to work. End of discussion.

Tracking Systems hearks back to space defense games from the early age of video games: alien saucers fly over your city, dropping bombs; and it's your job to destroy saucers and defend the city. But there's a twist: you use your Tablet PC pen to draw your defenses.

• In one mode, you can draw torpedoes. Simply draw a stroke, and a torpedo will launch. The size and power of the torpedo varies with the length of the stroke. The speed of the torpedo is based on how fast you drew it.


• In the second mode, you can draw shields. Any stroke you draw becomes a full strength shield. When a bomb hits a shield anywhere along its length, the whole shield weakens, until it's eliminated.

You can change modes in two ways: you can press the Torpedoes or Shields buttons; or if your Tablet PC pen has a barrel switch, you can hold that down to draw shields, and release it to draw torpedoes.

Here's a screen capture from a game of Tracking Systems:



Tracking Systems is far from a commercial game. For one thing, it's rather crude and unpolished (a lot like the games that inspired it, in fact). And it can get sluggish when there are a lot of saucers and missiles in the air, since I haven't put any work into multithreading or other optimization techniques.

But as a demonstration of Tablet PC programming techniques, Tracking Systems has a lot to offer:

• It responds to Stroke events, in order to draw torpedoes and shields.


• It reads Stroke properties to determine the size of each torpedo.


• It manipulates Stroke properties to change Stroke color to indicate shield strength.


• It manually adds Stroke objects to the Ink surface to create the saucers and buildings and bombs and torpedoes.


• It manually removes Stroke objects when items are destroyed.


• It manually moves Stroke objects as items move on the screen.

And if you want to learn these and other Tablet PC programming techniques, and if you want to write your own great Tablet PC applications, then I have to recommend our Tablet PC Programming BootCamp in Boston.

A visitor to my Tablet UML Web site asks:

What's the big deal with allowing this [i.e., Tablet UML] to run with a mouse and keyboard?

Sure it would be great if I had a Tablet PC to get the full benefit, but in the mean time, you can still recognize my mouse drawings (as if I had drawn them with a pen) and convert them into models.

That's a very interesting question: if the pen substitutes for the mouse, why doesn't Tablet PC software work without a Tablet PC? It's an interesting question, because it gets to the heart of what is often not understood about the Tablet PC. So I'm reproducing my answer here.

Tablet UML is written with the Tablet PC API. Until Microsoft merges that into the mainline OS (rumored to be around 2007), it will only run on Tablet PCs.

I've thought about replacing the Tablet API calls; but they do so much of the work for me. It would be like starting over again, on a very much larger project. If you study the Tablet API, you'll find that it is very much more than just a pen that acts like a mouse. The Tablet API does 90% of the recognition work for me, and then I just have to UML meaning to what it recognizes. Without that capability, I would have to write all that recognition code myself, which would be far more work than I can handle.

As I've written before: a Tablet PC is more than just a laptop with a pen.

And if you want to learn more about why a Tablet PC is more than just a laptop with a pen, and if you want to write your own great Tablet PC applications, then I have to recommend our Tablet PC Programming BootCamp in Boston.

As an author, it's always nice when someone says they enjoyed your book.

Nice? Heck, it's incredible.

But last night at CMAP, Dr. Osama A. Morad, Ph.D. gave me a compliment I will not soon forget. Upon meeting me, the first thing he said was, "Hello, Martin. I read your book. How's Sandy?" And then he told me how much he appreciated the dedication to my book, reproduced here:

To Dad, for teaching me how to work.
To Mother, for teaching me how to think.
To Sandy, for teaching me how to be me.

I can't speak for other authors, but I worked hard on that dedication, to get it to say exactly what I wanted to say about the three biggest influences in my life. For Dr. Morad to recognize that was really special, and is the nicest of the many nice things that readers have said to me. (He also asked some other good questions about the book, proving that he did indeed get farther than the dedication.)

Sandy's not in my book (computers don't need feeding or walking or grooming, so they don't interest her); but like everything I do, Sandy's all throughout my book. I'm the person I am because she helped me to open up to the world on a personal level. Before I met her, I was a geek. Because I got to know her, I'm a geek who knows how to relate to people and reach out to them and communicate with them a lot better. Growing up, I was an introvert by nature. I still have a self-image of an introvert; but I also know that self-image is inaccurate, because my whole job now is about standing up in front of students and conference attendees and trying to share ideas with them. And an awful lot of that I learned through interacting with her. Sandy is comfortable in many different social situations and groups; and because she drew me into them with her, I became more at ease with them.

That's just one of the many ways Sandy makes me feel somehow more me (if that makes any sense), but it's the one that's most relevant to the book and to my teaching and speaking.

And there's one other way in which Sandy was key to the book: my sample project for the book (and for my UML classes) is an information management system for a high-end pet kennel. Everything I know about pet kennel management comes from Sandy's years in that business.

So I really have to thank Dr. Morad for the kind words, and the chance to acknowledge a little more fully Sandy's role in creating the book.