Tablet PCs

I blame Microsoft

Martin L. Shoemaker — Wed, 01 Apr 2009 22:22:49 GMT

In a classic Dilbert strip, Tina the Tech Writer is forced to write docs for code that doesn’t exist yet. Her last line: “If you call our tech support, we’ll blame Microsoft.”

Works for me! I blame Microsoft for why I don’t have a new Lounge today. OK, so time spent job searching is a larger factor. But still, I’d rather blame Microsoft.

In particular, I blame Windows 7. Now by and large, I’m loving the Windows 7 beta. It’s a thousand little things I didn’t know I needed, but now I need. And it’s running amazingly well on my old Toshiba Portege M200. Soon I hope to test it on my Gateway, which has a lot more power.

But there’s one area where I’ve found a bug; and it’s a critical bug for the Lounge. In fact, it’s in the critical Lounge application: Windows Journal.

I love Windows Journal. It’s simple, it’s powerful, it’s free with Windows. You grab a Tablet PC pen, and you draw. That simple, and that powerful. Simple, because it just works like a pen and paper. Powerful, because even though it doesn’t have the drawing features of a higher-end paint package like Paint Shop Pro, it has two very powerful features:

You can print documents to it. Word docs, Excel spreadsheets, Web pages, whatever: print to Journal, and then you can draw on top of the “printed” document. I use this as a presenter: I print my Powerpoint slides to Journal, and then present from those. As I present, I can hand-write notes in answer to audience questions. This is the only way to present, in my opinion. (Actually, not quite the only way; but that’s an announcement I’m saving until I finish some code…)
You can do a text search of your hand-written notes. So not only can you write on your document, you can search for what you wrote. Again, this is great power for a presenter. (But again, look for an announcement soon…)

So I do love Journal. I call it the Killer Tablet PC App Microsoft Doesn’t Know They Have. Journal by itself is reason enough to have a Tablet PC, but Microsoft seldom seems to mention it. (A search for “Windows Journal” on Microsoft’s own site finds more hits for the Journal Viewer than for Journal itself; and Journal seems to have no specific page there, just a couple of “how to” articles.)

And I can’t draw the Lounge without Journal. Every episode, every panel, it’s all done in Journal.

And therein lies the problem: in Windows 7 beta, Journal is broken. When I open old episodes, some of the contents are drawn in the wrong place. Even worse, some aren’t. That means pieces of the episodes actually move around.

As an example, here’s Episode 32 as I drew it in Journal for Windows XP, then pasted into Paint Shop Pro for cropping and converting (click pictures for larger images):

Now it’s not high art, but it all looks like I intended it to look.

And here is how that page looks under Windows 7 beta Journal:

Notice the vertical stripe of missing Ink on the right. That’s bad. But it gets worse. Without me touching the image at all – all I did was switch to Paint Shop Pro to save the screen shot, switch to Live Writer to edit this post, and switch back – I get this:

I’m not sure I can describe all the things wrong with that image. Some parts of it have moved. Some parts haven’t: the panel borders are all drawn the same as the rest of the image, after all; and the nose of the Gremlin in panel 3 hasn’t moved at all. But the tail of the Gremlin has moved into panel 4!

Now a suggestion by Jennifer Marsman made me try an experiment; and her intuition is good: the Ink hasn’t actually moved, it’s just drawn in the wrong place! If I use the Journal selection tool and click in the image, I get this:

Notice how part of the Gremlin and passengers in panel 2 are really exactly where they belong; but they’re drawn to the right of where they belong. (Why only part? I can’t guess. I don’t know the internals of Journal. May be something to do with Grouping.)

Now Stacy Vicknair has asked if this bug is so bad that it stops me from drawing the Lounge? My answer is a definite maybe. See, I’m busy, and I’m lazy. If I draw something well enough once, I try to copy and paste it in other places where I need it. I’ve got 32 Episodes in, plus 3 Lounge-based conference talks and a Lounge book proposal. (Oops! Did I say that?) At this point, I probably draw less than half of each Episode. The rest is paste, resize, and edit. (I even wrote LoungeWorks, a set of Ink tools that give me power features not found in Journal: rotate, mirror, and scale.) But now, if I can’t reliably see where things are, it gets much harder to draw new Episodes. And with most of my time devoted to the job search, “harder” is not a feature for me right now.

I’m posting this in hopes of getting the attention of someone on the Journal team at Microsoft. I really want to use Windows 7, but I must have a working Journal for the Lounge. I’m not a fan of dual-booting, especially when my M200 has a rather small drive. I’ll dual boot if I have to; but I’d be happier to help Microsoft fix this. If anyone knows anyone on the Journal team, please pass the word: I’ll be happy to share the file that shows this bug, if that will help them to fix it.

I’ll also be happy to share another Journal file with an even more painful bug. Actually, I have multiple files with the same problem. They’re Web pages that I printed to Journal (XP) for later markup. If I try to open any of these in Win7 Journal, Journal hangs, and then Win7 terminates it. Worse: the recovery code “helpfully” tries to reopen that file next time I start Journal, and crashes again. Repeat, repeat, repeat, until I move the file so Journal can’t find it.

Journal team, I hope this helps! Contact me if you need more info. If you can’t figure out my email, you can always try @umlguy on Twitter.

Ulterior Motive Lounge Episode 32: Talking with Pilot

Martin L. Shoemaker — Wed, 04 Mar 2009 22:06:48 GMT

Continuing The Project that Time Forgot, a UML case study. (Click images for larger versions.)

On the surface, this Episode may seem almost social. Demented and sad, but social. But if you could join Hacker Girl, reading Geek Girl’s Tablet PC over her shoulder, you might see a different picture:

And you would also see this diagram:

You saw a conversation. Geek Girl hopes that Pilot saw a conversation. But she saw an interview, and a chance to capture and model requirements. Let’s review the notation here and discuss the diagram contents.

The ellipses are the use cases that a driver performs (indicated by the arrows from Driver to the use cases).
Dependencies (dashed arrows) with the <<include>> stereotype indicate that one use case includes another within at least one of its scenarios. So in order to Get Destination, the system must Scan GPS IDs.
The triangle-headed arrows (generalizations) indicate that one use case is a special case of another use case. So Contact Ops via GPS, Get Time from CIS, and Get Weather from CIS each has a special case that uses Voice Command; and each of those special cases is defective.

You might ask: “Why is Maintain Car in this diagram? Aren’t they modeling what the computer systems will do? Does the computer have any role in car maintenance?” And that’s a legitimate question. If the team were modeling the entire business, Maintain Car would certainly be a use case in the model; but why did Geek Girl include it in the system requirements model?

The answer is two-fold:

Pilot mentioned reflashing the engines, which is a computer-driven operation. As indicated in Geek Girl’s notes, it’s not clear at this time whether the Park’s computers are involved in reflashes or not. The reflashes may be done by dedicated tools that have no connection with Park systems; but it may be that the Park maintains records about the reflashes. Just in case, Geek Girl wanted to capture this.
And building on 1: it’s always best to capture whatever a user says, even if you’re not sure it’s relevant. You can always remove it later. The analyst’s first job is to listen and capture. Analysis and filtering comes later. Don’t filter while you’re listening, filter later!

But then you might ask: “Why did Geek Girl stop there? Why didn’t she include use cases like Fly Helicopter and Rebuild Diesel Ferry Engine?” The answer is that she ignored what I just said, and she filtered now. “Filter later” is a good guideline, but you do have to apply some measure of judgment. Certainly “Watch Your Language” doesn’t involve the computer system, so she knew she could ignore that. Fly Helicopter and Rebuild Diesel Ferry Engine are less clear; but there’s certainly a good reason for leaving them off this diagram: it’s a diagram of Driver use cases, and those aren’t Driver functions. Pilot does them, true; but when he does, he’s not acting in the Driver role. Because remember: actors are roles people or things can play, not the people themselves; and one person or thing may play multiple roles.

If you’re still uncomfortable with the distinction between Maintain Car and Rebuild Diesel Ferry Engine, good! Welcome to the world of requirements analysis! There are no hard and fast rules. There are no clear lines, only guidelines. You have to apply judgment; but as a general rule, err on the side of capturing more information, not less. Geek Girl captured a lot of notes on her Tablet PC, while converting the most clearly relevant ones into a diagram. After the interview, Geek Girl will find time to clean up and reorganize the diagrams, and perhaps rethink the contents.

In Episode 28, The UML Guy adopted a convention of indicating defects via notes on diagrams, as in this earlier diagram of Driver Use Cases:

Harlan Ellison once observed that a lot of dumb behavior can be traced back to the phrase, “It seemed like a good idea at the time.” Well, Geek Girl has decided that The UML Guy’s good idea at the time is a bad idea going forward. Not that the notes are a bad practice: they clearly indicate the defect, and diagram readers can easily see what the defect is. If your goal is printable diagrams which stand on their own, this might be a good practice.

But it has some weaknesses:

As we find a lot more defects, the diagrams will get cluttered, and it will get harder and harder to arrange the diagrams legibly.
We have to do extra work to show the defect on additional diagrams.
Printable diagrams aren’t your goal, or shouldn’t be, in my opinion. To quote myself:

The Model Rule

We saw The Model Rule in chapter 1; but it bears repeating. To use UML effectively, you should never be simply drawing pretty pictures; you should always be editing an underlying model, using the pretty pictures as your user interface. Thus, the model should contain more information than is displayed in any one diagram; and information in one diagram should not explicitly contradict information in another diagram. Information that is found in one diagram but not in another should not be considered a contradiction. Rather, this simply indicates that the former diagram displays more detail than the latter. Details may be omitted from a given diagram to make it more comprehensible.

But how do you keep these diagrams consistent with each other? How do you maintain the underlying model? This is where a good modeling tool proves its worth: a good modeling tool will maintain the model as you create and edit your diagrams. If you are not using some sort of modeling tool, this very mechanical burden will fall on you, rather than on the machine. That’s a poor division of labor: brains should do brain work and machines should do mechanical work. If you do the mechanical work, you will do it imprecisely and inefficiently, and you’ll have no time for brain work. I urge you to investigate and use one of the many UML tools available. A list of UML tools can be found in Appendix B.

And building on The Model Rule, defect notes on the diagram don’t let your model and your tool help you in managing the defects. As an example, Enterprise Architect from Sparx Systems allows us to add detailed requirements information to each element of the model. Here’s a sample screen shot:

And then you can create a requirements report that lists the defects, as in this snippet:

Launch Car Information System
Satus: Proposed	Priority:	Difficulty:
Phase: 1.0	Version: 1.0
Defect #1: Startup is delayed.

That’s a lot of power to give up just for the minor benefit of notes on the diagrams. (There’s a lot more power in Enterprise Architect reports than I’ve shown here; and if that’s not enough, EA is an incredibly powerful automation environment. You can build add-ins for it, and also build automation clients that control your EA models. I have one in the works that lets you directly create EA models from Microsoft Word 2007 and Microsoft Office 2007. When I first started using EA, I said, “This is a great UML tool for the price!” Today, I know better: Enterprise Architect is a great UML tool for any price!)

So in place of defect notes on the diagram, Geek Girl prefers to note the defects in the model, as above; and then use a stereotype to show that the use case has a defect. I think that’s a better practice, even if it’s a bit tool-specific. It makes it easier to add the additional use cases that Pilot described in this Episode (omitting the domain objects so we can focus on the use cases and defects). And for me, The Model Rule is more important than printable diagrams, by a long shot.

And as for the last item in Geek Girl’s notes: yes, why is H.G. so hostile? That must wait for an upcoming Episode…

The 21st Century Cocktail Napkin presentation is now available on-line!

Martin L. Shoemaker — Sat, 15 Nov 2008 22:18:24 GMT

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.

The Ink in 60 Seconds presentation is now available on-line!

Martin L. Shoemaker — Sat, 15 Nov 2008 22:17:13 GMT

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.

Tablet PCs

I blame Microsoft

Ulterior Motive Lounge Episode 32: Talking with Pilot

The Model Rule

Launch Car Information System

The 21st Century Cocktail Napkin presentation is now available on-line!

The Ink in 60 Seconds presentation is now available on-line!