Will you?

UPDATE: To make it easier to find this entry, I've added a link to it in the right sidebar, right under the links for my books and my classes.

West Michigan .NET User Group in Grand Rapids MI. April 17. Topic: Dee Jay: A Voice-Controlled Juke Box for Windows Vista.

Ann Arbor Day of .NET in Ann Arbor MI. May 5. Topic: Talking with Vista.

West Michigan Day of .NET in Grand Rapids MI. May 5. Topics: Do, Undo, Redo, Do Over: A Generics Command Pattern Implementation; Talking with Vista.

Huntsville New Technology User Group in Huntsville AL. September 11. Topic: Dee Jay: A Voice-Controlled Juke Box for Windows Vista.

UPDATE: To make it easier to find this entry, I've added a link to it in the right sidebar, right under the links for my books and my classes.

West Michigan .NET User Group in Grand Rapids MI. April 17. Topic: Dee Jay: A Voice-Controlled Juke Box for Windows Vista.

Ann Arbor Day of .NET in Ann Arbor MI. May 5. Topic: Talking with Vista.

West Michigan Day of .NET in Grand Rapids MI. May 5. Topics: Do, Undo, Redo, Do Over: A Generics Command Pattern Implementation; Talking with Vista.

Huntsville New Technology User Group in Huntsville AL. September 11. Topic: Dee Jay: A Voice-Controlled Juke Box for Windows Vista.

Will you?

The 21st Century Cocktail Napkin is a talk I presented to the Ann Arbor .NET Developers group on June 14. It's an example of a smart cocktail napkin application built using the Tablet PC API. In a a smart cocktail napkin application, you draw shapes as part of some design you'll share with other readers; but as you draw, the Tablet PC also recognizes and understands what you draw, and creates information behind the drawing. (For an example of a smart cocktail napkin application, you can start here.)

Now, thanks to Camtasia Studio, I have a recording of this presentation. And thanks to YouTube, I can now present it to you on-line:



And you can also download a ZIP file of the slides and the sample code.

Look for more recorded presentations soon. And if you're looking for an easy-to-use UML tool for Tablet PCs, check out Tablet UML.

Ink in 60 Seconds! is a talk I have presented to a number of user groups (some courtesy of INETA). It consists of a number of small little demos of Tablet PC programming, most written in 60 seconds or less.

Now, thanks to Camtasia Studio, I have a recording of this presentation from the Ann Arbor .NET Developers group on June 14, 2006. And thanks to YouTube, I can now present it to you on-line here. And you can also download a ZIP file of the slides and a cleaned-up version of the sample code.

One part of the video may need explanation. Part of the fun of this talk is the deadline: can I write that code in 60 seconds? And if not, I expect the audience to heckle and laugh. But just in case they need encouragement, I wrote a little tool called Egg Timer. When I launch it, it starts a 60-second clock; and if I don't stop it before the clock elapses, it will heckle me. So if you hear a strange computer voice at spots in the video, it means I ran out of time.

And for those who are curious: yes, my car is much better now.

Look for more recorded presentations soon! And if you're looking for an easy-to-use UML tool for Tablet PCs, check out Tablet UML.

Update: Here's an attempt to embed the video in this post:



Update: Fixed the link to the ZIP file. Thank you, )Stéphane Torres.

At a client's request, I've been porting my Tablet PC labs to VB.NET. In the process, I've learned some lessons that might be helpful to others who have to make this sort of a port. This is strictly programmer geek stuff, so I'm hiding it. The rest of you may prefer to look at the cute baby llama.

So one time, I showed a friend a Web site for a project I was working on. And he asked an interesting question:

Well, you're design guy right? Shouldn't you be writing a design document?

And what I suddenly realized was unclear was that the Web site was a design document. It was just a design document of a very different sort. It was basically a step one design document, serving as a way to put the ideas in a concrete form for discussion. The team kinda knew what the product should do, but not every last detail yet. Some team members were ready to jump in and start coding right away, and just call it Agile Development if we needed to justify the work. Instead we said, "Wait a minute. We have a vision, but no details. If we don't explore what some of the users will demand from the system, we won't design the architecture to accommodate them properly. So before we can write a line of code, we need to explore what a range of users need. Then we can design an extensible architecture that should support most of those needs. And then we can jump in and start coding." So the Web site was, in part, a format for exploring what different sorts of users would want, by telling stories of how they would use the system. And since the system was intended to be marketed to users who could use those same stories as a way to envision using the system themselves, it made sense to document those stories in a marketing-oriented Web site. But marketing-oriented or not, the Web site still served a purpose as a design document.

Now my friend would never be so rigid and unimaginative as to say that the Web site wasn't a design document; but I have met people who are so wedded to hidebound procedures that they would have argued exactly that, just because it didn't conform to some formally defined design document template or fit into some formally defined design methodology. And that reminded me of Kipling:

"There are nine and sixty ways of constructing tribal lays,
"And-every-single-one-of-them-is-right!"

Design is a heuristic problem, meaning that there are techniques that can lead to a solution, but no single guaranteed and inviolable path to a solution. Quoting from Wikipedia:

In computer science, a heuristic is a technique designed to solve a problem that ignores whether the solution can be proven to be correct, but which usually produces a good solution or solves a simpler problem that contains or intersects with the solution of the more complex problem.

Note the word "usually" in that description. Some heuristics are better than others, but none can be proven to be right, especially not in the general case.

There are many ways to design, because design is really just a means of communicating and refining your ideas. Different people communicate better in different fashions. Some people are more visual, and some or more verbal. Some are more instinctive, and some are more methodical. Some are more detailed, and some have a broader view. And so there's no one right way to communicate a design to other team members and stakeholders. The only "right" approach is multiple approaches, to ensure that you cover the same material in different ways to gain different perspectives.

As an example, some people love written design docs, and just can't see any benefit in design diagrams. Others believe in making excruciatingly detailed UML diagrams, and sometimes see those as "complete" designs. Now I'm pretty fanatical about using UML for my designs; but when I teach UML, I always point out that neither text nor pictures is sufficient. You need both. Different people and different teams will emphasize one over the other, but you need both.

That doesn't mean that there aren't better ways and worse ways to design. I would never consider a marketing-oriented Web site to be a complete design, just a step in building the design. But when we built that Web site, we were definitely participating in a design effort. Because...

"There are nine and sixty ways of constructing tribal lays,
"And-every-single-one-of-them-is-right!"

It's a little late to announce this — particularly since the class is full — but it's worth mentioning for future reference. The Richard Hale Shaw Group is presenting our Visual Studio Team System class at the Microsoft Technology Center in Waltham, MA, with me as lead instructor.

We're also trying to find another chance for me to present Ink in 60 Seconds while I'm there.

It's a little late to announce this — particularly since the class is full — but it's worth mentioning for future reference. The Richard Hale Shaw Group is presenting our Visual Studio Team System class at the Microsoft Technology Center in Waltham, MA, with me as lead instructor.

We're also trying to find another chance for me to present Ink in 60 Seconds while I'm there.

It's a little late to announce this — particularly since the class is full — but it's worth mentioning for future reference. The Richard Hale Shaw Group is presenting our Visual Studio Team System class at the Microsoft Technology Center in Waltham, MA, with me as lead instructor.

We're also trying to find another chance for me to present Ink in 60 Seconds while I'm there.

This is a little late, because I've been doing post travel stuff, and then getting ready for the new VSTS class coming up. To the fine folks in Montreal, I say: Pardonnez-moi, svp, mes amis!

So on Wednesday night in Montreal, I gave my presentation to GUMSNET: Ink in 60 Seconds. Despite my rather hideous attempt to apologize in French for not being able to speak French, they were most gracious hosts. (And darn it! I rehearsed that apology over a dozen times on the trip, until I had it down pat; and then I fell apart when I actually had to give it. Here's what I meant to say: Bon soir, monsieurs! Mon nom est Martin L. Shoemaker, et je ne comprends pas le français. Pardon, si vous plais. Je suis un debutante en français. Mais mon Tablet PC comprend le français!)

I got caught in a lot of Montreal traffic, and also had to fight to find parking in Centre-ville, so I was just a bit late. And then my machine had to reboot. But we finally got rolling, and I started writing little Tablet PC demos, with a 60 second clock running. There were occasional laughs at my expense when I missed the 60 second mark; but on the other hand, many of the demos were done in under 30 seconds. The Tablet PC API is just that powerful. By the time we were done, we were drawing pictures, editing them, erasing them, saving them, loading them, and exporting them as images. We were also drawing shapes that the Tablet PC recognized and identified. We were converting handwriting to text, in both English and French. And we even wrote some text by hand and then had the Tablet PC speak it out loud. We finished with ten ideas for great Tablet PC apps just waiting to be written. I hope that I inspired someone in the audience to go write one.

There was one hang-up in the presentation; and I promised the good folks from GUMSNET that I would blog about it, including what I learned afterward. Late in the presentation — right about the time I tried to do handwriting recognition, when I needed really good ink collection — my wonderful Gateway CX200X Tablet PC started exhibiting dead spots that were strangely reminiscent of the bad old days of Toshiba. The dead zones weren't as consistent, but they were irritating. And they always seemed to be right where I was writing text en français to try to show off the multi-lingual power of the Tablet PC. The audience was forgiving for this, but they did insist on knowing the answer when I learned it. Well, here's what I think I have learned. I noticed that the pen seemed to behave better when I held it at different angles; and then I remembered that when we broke for dinner, I dropped the pen. And as far as I can recall, there were no dead zones before the break, only after. I suspected that maybe I had jammed something in the pen tip; and with a little experimentation, I found that rotating the pen around its axis or relative to the screen could sometimes make the dead zone go away. Suspecting a pen problem rather than a screen problem, I pulled out my spare pen. And I have had no dead zone problems since.

All in all, Montreal was a delightful place to visit, and I hope to return some day when I have a little more time to visit. And the folks at GUMSNET were a great audience. I ran about 40 minutes over time (gee, there's a surprise); and they were all alert and attentive right to the end. We would probably have stayed longer, but the Microsoft employee who was keeping the facility open for us wanted to go home!

Of course, Richard would have my hide if I didn't mention that Ink in 60 Seconds is the opening segment of our Tablet PC Programming Workshop, where you can learn all this and much, much more about building your own Tablet PC applications. In the class, you won't just watch: you'll build a full-featured Tablet PC application yourself, and learn the Tablet PC from the inside. I hope we'll be adding a public Tablet PC class to our schedule first, but you can always bring us to your site.

So why aren't you writing Tablet PC applications with .NET yet?

Do you think it's too difficult? Do you think you're too busy to learn the Tablet PC API? Well, I say you're wrong.

Or do you just not see what sort of Tablet PC app you might build? Do you think that there's no great Tablet PC applications out there for you? Well, I say you're wrong again.

And I'm so sure you're wrong, I'm going to prove it to you at the Groupe d'utilisateurs de l'archutecture Microsft .Net de Montreal by building some simple little Tablet PC samples — samples you can easily adapt into your own applications — each written in under 60 seconds. (Note: In order to meet that time limit, I'll be writing these in C#, the language I know best. Every single one of these demos could be written in 60 seconds in VB.NET, but only by a better VB programmer than me!)

Then after each sample is running, I'll explain to you what I did, how I did it, and how you might expand on it. Some of the samples I'll build include:

• 60 Seconds to Ink: Capturing Ink in a window in your application.


• 60 Seconds to Ink Anywhere: Capturing Ink in any window in your application.


• 60 Seconds to Programmatic Ink: Adding Strokes programmatically to an Ink surface.


• 60 Seconds to Saving Ink: Saving your drawings.


• 60 Seconds to Loading Ink: Loading your drawings.


• 60 Seconds to Saving Some Ink: Saving part of a drawing.


• 60 Seconds to Loading Some Ink: Loading a drawing into an existing drawing.


• 60 Seconds to Exporting Ink: Savinging your drawings as images you can share with non-Tablet PC users.


• 60 Seconds to Selecting, Moving, and Resizing: Manipulating the Ink that you draw.


• 60 Seconds to Erasing: Erasing the Ink that you draw.


• 60 Seconds to Drawing Attributes: Drawing with multiple colors, transparent Ink, and different shapes and sizes of pens.


• 60 Seconds to Clipboarding: Really simple Ink clipboard functionality — and why it doesn't work!


• 60 Seconds to Simple Handwriting Recognition: Simple handwriting in a form.


• 60 Secondes au Français: Identification d'écriture en français.


• 60 Seconds to More Handwriting Recognition: Handwriting recognition mixed with typing.


• 60 Seconds to Handwriting Recognition Anywhere: Handwriting recognition from any Ink surface.


• 60 Secondes à Plus Français: Plus d'identification d'écriture en français.


• 60 Seconds to Text-to-Speech: A simple talking application.

And just in case those samples don't inspire you to devise a great new Tablet PC application, I'll finish the presentation by spending 60 seconds (probably more) describing each of ten different killer Tablet PC applications that I'm just too busy to write myself, but which I think somebody should be writing.

So fasten your seat belts. This is gonna be one heck of a fast ride!

And no, I'm not doing this talk just for the free pizza from INETA and the free trip to Montreal. I certainly hope that some of the attendees are so excited that they'll want to take our Tablet PC Programming workshop, where we'll go places you just can't reach in 60 seconds.

OK, let me first acknowledge right up front: this project is eminently impractical. For one thing, there’s the price: replacing a paper process with at least four Origamis (plus other support hardware) is just a bit pricey. And for another thing, many of the target end users are just a bit suspicious of and even opposed to technological solutions. They think the paper processes are working just fine, thank you very much. (Though as someone who occasionally has to process their paperwork, let me tell you: it ain’t easy, and often their handwriting and habits complicate my job.)

Still, inspired by Epee Bill, I had this vision. And I really do think it would be a vast improvement over the paper processes, if people would accept it. Just imagine...

Mr. Vesper stands beside the fencing strip. In his hands is an Origami: somewhat heavier than the clipboard he once would have carried, but not much larger. On the Origami screen are the names of two fencers. He calls them: "Up next. Mr. Smith. Mr. Bolakowski." The fencers enter the strip, Smith on the right and Bolakowski on the left, and hook up to their wires. Then they present their weapons to Mr. Vesper. He tests each one, and then with his finger makes two "check" gestures on the Origami to indicate that the weapons passed inspection.

Mr. Vesper returns to the sideline and calls out: "Fencers ready..." The combatants assume their en garde positions. "Fence!" The wireless microphone he wears picks up this command and starts the fencing clock, as the fencers approach each other. (If Mr. Vesper preferred not to wear the mike, he could also start the clock by pressing a button on the Origami.) The fencers engage. Beat, beat, beat, feint, attempted parry, disengage, lunge! The scoring box lights up with one light, and Mr. Vesper calls "Halt!" Ideally, the scoring box automatically stopped the fencing clock; but since most scoring boxes aren’t capable of that, Mr. Vesper can also stop the clock via voice or button. Mr. Vesper calls the action, and then records a touch left by making a downstroke gesture in a box near Mr. Bolakowski’s name. The Origami acknowledges by announcing, "Touch, Bolakowski. Score is 1, 0." Meanwhile, the Origami uses WiFi to update the tournament server; and then the server posts the results live to the tournament’s Web site. One of the tournament workers is also wandering around between the strips, using another Origami to record live video and stream it to the server and from there to the site. Fencers and fans from all over the world can follow the tournament in real time. A tournament monitor near the bout table shows the live results. It has a touch screen (in fact, it’s really a larger Tablet PC device being used as a kiosk) so that spectators and fencers can navigate to different pages and check current standings. (This will, I hope, keep them from coming to the bout table and distracting us from our work by asking, "So if I win my next bout, who will I face after that?" Or "So is this an A tournament?" [Like I know how to answer that.] On the other hand, this system will do so much of my work, so I may have time for questions.)

Mr. Vesper repeats, "Fencers ready... Fence," and the clock and the action start again. Thrust, retreat, thrust, retreat, ballestra-lunge! And the scoring box lights up with one white light. Off target. Mr. Vesper calls the action and records the off target by making a downstroke in a different box (colored white to match the white off-target light). The Origami announces, "Off target, Bolakowski. Score is 1, 0."

"Fencers ready... Fence!" Taking a more aggressive tact, Mr. Bolakowski almost immediately leaps into a fleche. But his timing is off, and he ends up colliding with Mr. Smith. Mr. Vesper calls, "Halt! Red card." And he makes a downstroke in a third box (colored red for penalties). The Origami needs more information, so it pops up a list of possible reasons for the penalty, and Mr. Vesper checks the one that says, "Corps a corps." The Origami announces, "Red card. Bolakowski. Score is 1, 1."

Chastened, Mr. Bolakowski falls back into a more defensive mode. He and Mr. Smith trade thrusts and parries and occasional points back and forth, but the action slows. Eventually, the fencing clock runs out, and the Origami announces, "Time." Mr. Vesper calls halt, and then says, "Victory to Mr. Bolakowski, 4-3." The Origami has already figured this out for itself; but since no result is official until a director confirms it, the Origami presents the results to him. He makes a check gesture, and the official results are sent to the server and the Web. Immediately his Origami screen displays the next bout, and he calls it out: "Fencing, Emerson, Jones." Mr. Jones is not immediately available for some reason, so the Origami begins a countdown clock. If he doesn’t arrive in time, he’ll forfeit.

When the last pool bout of the event is complete, the server immediately produces a seed page and also an elimination table. It also pushes the list of elimination bouts out to the directors’ Origamis. The software on the Origamis knows that these are elimination bouts, so it changes the way it keeps time: elimination bouts run to 15 points, and are stopped every three minutes for a one minute break.

Now again, I know this is impractical, probably for more reasons than I have identified. (Flashing blades and computer equipment may be a bad combination.) And while I do think Microsoft could be interested in unusual showcases for their devices as a way to get publicity, I’m not sure that getting involved with fencing is the way to do it, at least not in America: in a country where competitive hot dog eating is actually broadcast on ESPN, fencing can’t get any air time. But boy, would I love to see it in operation! And I could write practically this whole system by myself, without a whole lot of work; and I could teach a team how to write it in under a week. I just have no confidence I’ll ever persuade anyone to let me. But I can dream...

Of course, there are other sports that could make good showcases. I’m thinking that the American biggies – football, basketball, and baseball – would make poor showcases. The fields of play are too large, and officials are too distant from the action, so no one would ever see the Origamis. So that hints at what would make a good showcase sport: one with a smaller playing field, with probably only a small number of participants (two, or maybe four), and where the officials are fairly close to the action so that the Origami will be in the camera shot quite often.

Tennis, anyone?

UPDATE: Fixed the score, thanks to Epee Bill.

...but Microsoft says it so much better here. As some reports have hinted, Origami devices (now known as "Ultra-Mobile PCs") are small, light, highly portable Tablet PCs.

And for developers, there's a lot more on Ultra-Mobile PCs here.

And of course, if you want to learn how to write programs for UMPCs (boy, is that an ugly abbreviation, or what?), I would like to suggest that you start with our Tablet PC Programming Workshop. (If your organization plans to deploy a large number of UMPCs, Microsoft's SSP program recommends our course.)

UPDATE: Epee Bill (famed member of the Ann Arbor Dueling Society) asks:

And if I asked you, "Why do I want one of these and no a PDA?" what would you say?

Well, Bill, I'm not sure that my answer will make any difference to you, because you're a Mac guy. But I'll give you the answer anyway. Does the PDA run Word? Excel? Outlook? Internet Explorer? Windows media player? A wide range of PC games? MapPoint? And pretty much all of your Windows software?

Does the PDA play DVDs? A UMPC will, though I expect you'll have to plug in an external DVD player on most of them, and probably a power cord. DVD playing should use a lot of battery power.

And while I'm at it, does the PDA run Tablet UML? Or OneNote? Or Journal? Or the Franklin Planner software? Or GoBinder? Or any other Tablet PC software?

See, you're a Mac guy, so you don't have any Windows software; but a lot of people do. For them, this may be a good alternative to a high-end PDA. (Low-end PDAs will still be a lot cheaper.)

And wait until we see new applications built on the power of ultra-mobile connectivity and power. I have some ideas on those, but not enough time to present them right now.

Never would I have guessed that a presentation on the architecture of handwriting recognition systems would be a source of great hilarity. At the Microsoft Mobile Platforms Division Partner Briefing, Jay Pittman has us rolling in the aisles. Some examples.

"So you write 'dictionary', but the recognizer comes up with 'dictum'. So we let the user select the 'um' and rewrite it. But we have to do that in context of the first part. Otherwise, Bill Gates tries this, and he writes 'ionary', and the system looks it up in the dictionary and finds the first matching word, 'ion'. And then Bill Gates uses... 'colorful' language."

"I never imagined when I was planning my career that some day Bill Gates would pay me to look up dirty words in the dictionary."

"So we have to mark certain words as being in the dictionary, but being 'restricted'. That means that, when the recognizer can't recognize something but the F-word looks like a possible match, we still don't put it in the match list. We have to put it in the dictionary, or else when someone types it, it will show up as a misspelling. Then someone will write a letter to the editor: 'Microsoft doesn't know the F-word.' But that doesn't mean they want it showing up in the suggested word list. That way, we'll get letters from Senators. Or Archbishops. (Audience laughs.) It has happened."

"KKOMO: That means 'Krispy Kreme's Outside My Office'. It makes you very popular here at Microsoft."

"We don't pre-announce things... usually because we don't know!"

Mr. Pittman is one funny speaker!

On a more serious, business note: at this briefing, Microsoft announced that the Richard Hale Shaw Group is now their official partner for developer training for enterprise Tablet customers. If you're not quite large enough to be one of their enterprise customers, you can get the same training directly from us.

UPDATE: "We also get asked about Klingon text recognition. The answer's still no."

UPDATE: Fixed a dumb spelling error.

Somewhat belatedly continuing the story of my visit to the Cosmosphere...



This is the harness that carried Enos, the first chimpanzee to orbit the Earth.









At the Cosmosphere, they have a LM mock-up where you can get quite close (closer than I got in Huntsville).





You can also get pretty close to their lunar rover.



Here's a sort of diorama of two Apollo Lunar suits in front of a lunar rover.



This is a docking probe, used to connect two spacecraft together. In all my reading, I had never known how these worked. Looking at the probe close up, I could get a little better view of how collapsing the "arms" inside the probe would trigger the docking latches. There's still something I'm missing, but it made more sense after I saw this.





Here are a couple of views inside a LM trainer.







Here are three views of the Apollo 13 Command Module, Odyssey.



Here's an unfortunately fuzzy shot of a fuel cell like the one that exploded during the Apollo 13 mission.



Here's Odyssey's heat shield, after it has done its work of keeping the crew safe from reentry heat.





Here's a mockup of the Soviet Lunokhod lunar probe.











This is a long string of pictures from an Apollo-Soyuz mock-up.



This is the lab where they perform restoration on the artifacts.

Well, that's enough for now. With luck, I'll have pictures of three more Command Modules in the next two weeks. Details later.

Due to a very large number of business opportunities coming up, including a can't-miss training opportunity in the Seattle area, we have decided to postpone our Tablet PC Programming BootCamp in Boston. Details when we learn more.

I was looking forward to that class, but there just wasn't time to get properly prepared for it and attend the new training that opened up and prepare for other classes and conferences and finish up my book. I'm burning the candle at all three ends as it is. So it's better to postpone and do it right than to try for the unattainable and disappoint the students.

As a consolation prize for me missing the class, I'll have to settle for being home for this. Darn!

And hey, if you want to see a really, really powerful Tablet PC in action, just join us when we reschedule the class!

This one's pretty vague, because I've never studied chemistry after high school; but I know that chemical diagrams are easy to draw by hand, and hard to create in a typical word processor or graphics package. So Chem Pad would allow a chemist to draw the diagram by hand; and then the app would apply chemical knowledge to create a cleaned-up, ready-for-publication version of the diagram. Chem Pad should run as a stand-alone app that can svae the diagrams or copy them to the clipboard; and it should also run as an MS Word add-in that can automatically insert the images into the text.

Chem Pad could also do things such as calculating the molecular wait of the diagram as drawn, automatically adding valence numbers, and maybe even identifying flaws in the diagram. And since there are high-end chemical visualization tools out there, Chem Pad should export to their file formats. There's probably a lot more that it should do; but I'm not a chemist, so I can't think what that might be. If you can, I can teach you how to write Chem Pad.

Here's a variation on TacMap, one which was hinted at in that nugget. You let players use the pen to sketch out orders for movement and attacks and other actions in a turn-based strategy game. The player could draw various shapes on a particular unit to represent various actions, such as digging in, fortifying, building, planting, etc. The player could also draw paths for units to follow. And then the user could also switch modes (perhaps via the pen's barrel button, or perhaps even by voice command) to order units to attack particular targets. And the player should be able to click or tap on a unit to open a status window for that unit.

There's a lot more that a game like this should have: a good story line, compelling music, and great graphics. I'm not a game programmer, so I don't know how many other things you should add. But if you do, I can teach you how to write the pen and voice controls.

(For some sad reason, I keep getting an image of John Madden and his electronic whiteboard, and imagining that being animated. But I suspect that X's and O's just aren't good enough for today's graphics-obsessed gamer. Still, the TacMap game idea could work for a football game as well, if you supplied better graphics and sound.)

UPDATE: Oops! I forgot to mention that Tracking Systems is an extremely simple example of a Tablet PC game. It's not great, but it should get you thinking.

Here's a Tablet PC gold nugget for any military programmers out there: TacMap, a tactical map for battle planning and evaluation. This app would allow a commander to use a simple pen to draw and update a battle map, either for planning an upcoming battle or for plotting observations and movements for a battle in progress.

TacMap should allow drawing or importing of maps, as well as of units and sets of units. A commander should be able to draw new enemy units as they're discovered, and should be able to drag and drop units to reflect plans or observations. The commander should be able to tap or click a unit to pop up a detail window to add status information and issue orders. (If you're really ambitious, you could even allow the commander to open a communications channel to friendly units by way of the detail window.)

The commander should also be able to modify the map on the fly, drawing in obstacles, hazards, and other terrain features as the battlefield changes.

For battle planning purposes, you might even allow units to be animated. The commander could sketch out a path for each unit to follow, and could also and time marks to indicate when a given unit is expected to reach a given point. The commander could also designate fire arcs and fire rates or other instructions. Meanwhile, another commander playing the role of the enemy could plot out likely tactics for opposing units. Then the map could be animated, so that the command staff could watch the plans play out and look for possible problems.

That's a start. I've never been in the military, and I'm not a tactician, so I can't envision everything TacMap should do. But if you can, I can teach you how to write it.

I forgot about this nugget; and it's one you may want to consider as part of building this or one of these. The idea would be that, rather than just building a custom Smart Blueprint app, you would build a framework that allows you to plug symbol sets into a basic map drawing component. The map drawing piece would support drawing and dimensioning frames or layouts, and maybe importing of existing maps; and the plug-in API would let you design symbol grammars and attach them to data and meaning behind the diagram. This would be a lot of work to do for one Smart Blueprint app, but it would make further Smart Blueprint apps a lot easier.

And you know what I have to say next: I can teach you how to write that framework.

OK, this isn't an original idea by any means, but it's still a good one: the Tablet PC allows for the simplest, most natural way to compose music on the computer. I know because it has already been done: see the Tablet PC Music Composition Tool, written by Andrew Forsberg, Loring Holden, Timothy Miller, and Robert Zeleznik of Brown University. When I put this in the hands of a musician, he or she immediately knows how to use it. You just draw musical notes on staves, exactly like composers do on staff paper; and then you press Play, and the music plays in one or two of a wide range of synthesized musical instruments. Their eyes light up, and they say, "I want one!"

But after they play with it a while longer, their eyes droop, and they say, "Let me know when it's finished." The Composition Tool is interesting, but incomplete. It was written as a grad school programming project and an entry in a Tablet PC programming contest, not as a commercial product. And after waiting for three years for the excellent team from Brown to finish the job, it looks like they're just not interested. That leaves the way clear for somebody else to do the work, only better. Here are some ways to do even better than the Composition Tool:

• While I really like the Composition Tool, it's imprecise. It's easy to put a note in the wrong place. And as we'll see below, that's a hard mistake to fix. I know that a Tablet PC app can be more precise than this, so precision will just take some testing and tuning.


• It needs those fundamental editing features that all users want in a document editor: Undo, Redo, Cut, Copy, and Paste.


• It needs the ability to select and edit a note. You should be able to drag it and drop it to a different value on the scale.


• It should support the pen eraser, where available.


• It only supports two staves and two instruments. That number should be variable.


• It should support more notations, such as guitar chords and drum notation.


• It should support recording the music as audio files and probably MIDI files.


• It should allow the composer to add lyrics.


• It needs a print function. The print function should be able to produce both a master score and individual instrument scores.

That's a start. There should probably also be smarter musical transformations, such as "Transpose this section up an octave" or "Fix this section so that the key signature is correct." I would give you even more suggestions; but my high school musical training never really got that far, so I'm no sort of expert in the music domain. But if you are, I can teach you how to write a Sheet Music app, so you can hear the musicians say, "I want one!"

Our second gold nugget builds upon our first. The Electrician's Note Pad is one example of a category we can call Smart Blueprints: applications where a user draws a building plan or a property map, and then adds symbols that the app assigns particular meanings to. Here are some obvious variations:

• Carpenter's Note Pad. The same idea, but with carpentry symbols.


• Plumber's Note Pad. The same idea, but with plumbing symbols.


• Heating and Cooling Note Pad. The same idea, but with HVAC symbols.


• Decorator's Note Pad. The same idea, but with interior design symbols.


• Landscaper's Note Pad. The same idea, but with landscaping symbols.


• Architect's Note Pad. Similar to the other Note Pads described above, but with an important twist: the architect can change symbol sets, switching from electrical view to plumbing to heating, etc., as the architect tries to capture various views of the building. Each view should appear in a "layer" within the diagram; and the architect should be able to show or hide layers as needed.

Given the original idea, these were all easy to imagine. Still, there are opportunities there for someone or some team with the right domain expertise. I'm not that person; but if you are, I can teach you how to write these apps.

Moved to the top because it's marketing, ya know? It doesn't make sense to let your marketing messages scroll off the cliff...

OK, I've been announcing this for a little while now, but now it's official: registration is now open for our Tablet PC Programming BootCamp - Nov 1-4, 2005, in Boston. From the registration page:

• This course personally taught by Martin L. Shoemaker, author of Tablet UML (the UML program you don’t have to learn!)


• When: Nov 1-4 (Tuesday-Friday), 2005, 9am-7pm


• Where: Microsoft's Boston offices in Waltham, MA


• Where to stay: Hotels and Travel Info.


• Course Description and Outline for this Class Details...


• This is a HANDS-ON class: you’ll need to bring a Tablet PC configured as detailed below.


• It’s a BootCamp: 9-10hrs a day, and you’ll have Homework to do


• You’ll receive 200+ pages of labs, 100+ pages of slides, and all code samples built in-class — and a copy of Tablet UML!


• Personal attention from Martin L. Shoemaker


• The best darn Tablet PC training around!


• Seating is limited to 15 students: register today!

I hope to see you there!

UPDATE: Like all Richard Hale Shaw Group classes, this one is also available at your site. You can train a busy development team all at once, and save money in the process! Contact Richard for details.

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.