Slashdot

Gary Gygax, July 27, 1938 - March 4, 2008

This is an odd one for me -- depending on how you look at it, I was in the RPG world for many years, but not of it, or of it, but not in it. Most of my friends are gamers, some of them quite hardcore for years. When I was a teenager, I wrote a paper RPG. (In retrospect, it seems as though what I was reaching for -- completely independently of anything, since I didn't know the people involved and they didn't know me, and there was a lapse of several years involved -- was what someone else eventually wrote as Vampire: The Masquerade, although what I came up with was closer to GURPS and, admittedly, ultimately unplayable. At least I got class credit for it.) I had a front-page entry in the Daily Illuminator (under the name of the person whose e-mail I was borrowing at the time, since I didn't have one of my own -- scroll down to October 2). I even owned a set of dice. (I've since given them away.)

However... Aside from a few abortive attempts at LARPing in the mid-90s, I've never actually played a pen-and-paper RPG.

However again, if it hadn't been for the RPG culture, in which I was at least an interested bystander if not an out-and-out participant, I never would have become the (geeky-but-at-home-with-it) person I am today.

So I owe one to Gary Gygax. Thanks, man. I've never even played your game, but you still changed my life.

Here's where you guys come in.

The Back Story: I've not done a lot of in-program help integrations, because I've usually been working with people who know how to do it. None of the programmers here do, and I don't either.

We're looking to streamline our help integration process for in-program, window-level help. The way we would like to do this is to have the developers assign Map IDs in the code right from the outset in the development process, before the help is written. However, doing so would mean that any map file I get from them will not include topic titles. Is this a problem?

(The advantage is that by using this system I could go through the application screen by screen during the testing phase and determine which screens do not have associated help topics.)

As of now, I can create a .h file in RoboHelp and import it into the project file, but if there are no topic titles specified, I can't see any of the Map IDs in RoboHelp's Edit Map IDs window.

If we can in fact implement this system, what does the developer need to give me (that will actually work)? What should the file content look like? Do any of you actually know?

When you live in a place where the car rules, and car drivers think they're the High Royalty of Turd Island, and you don't drive yourself, you very quickly develop a Traffic Glare. The Traffic Glare, patent pending, is a comprehensive form of non-verbal facial and kinesic communication (consisting partially of extended eye contact, and partially of appropriate facial/physical expression) which clearly notifies menacing drivers that...

...you know they have seen you.

...you have memorised their license plate.

...you are carrying a concealed death ray on your person, and are not afraid to use it if they try anything hinky.

...and further, after having used it, you will file charges against their smoking remains.


Today I had a superlative Traffic Glare. I think it kept me from getting run over at least once...

(...and friends.)

A friend of mine sent me this big long e-mail about "yak-shaving," which in this case involved wanting to do something with a piece of software, discovering that it wanted access to a particular library he didn't have, trying to find, and then trying to install the library, just to get back to the original task. He mentioned what I noticed ages ago, which is that a lot of open-source stuff doesn't always include everything you need to get the software up and running, I think in part because the developer(s) assume you already have it (they're funny like that).

That got me thinking about a lot of the crap I've seen both in OSS projects and in proprietary projects -- I have to say, proprietary software has definitely got the drop on OSS in terms of including everything (hell, the other day I got an e-mail with a link to Acrobat Reader download in it, just in case you wanted to grab a linked PDF, and were the last person on earth still without a PDF reader, case in point). And I thought a lot of these problems reflect a lack of basic design knowledge on the part of most software developers.

By "design" I mean "visual, textual, and informational rhetoric," rather than "how to put together a program in a way that works and makes sense."

That got me thinking...

"Every CS programme should include a course on design fundamentals, tailored to the specific wants and needs of software development. I should write a syllabus for a course like that, and post it five or six different places, so the meme gets out..."

So, uh, if you were developing a postsecondary (2nd year+ university or third-year college) course on design fundamentals for software developers, what would you include?

What I'd propose would look something like this:

• Unit 1: Introduction, What Is Design and Why Do You Care?
  
• Unit 2: Audience (User) Analysis: Who are your users? What are their wants and needs? What can you assume about them? What shouldn't you assume about them?; Bias; How to find out
  
• Unit 3: Information architecture and management for code, UI, and documentation
  
• Unit 4: Documentation: Commenting and in-code documentation; User and peripheral documentation; Web documentation; documentation design
  
• Unit 5: UI Design Issues: Consistency (ordered lists, menus, workalikes, labels, navigation controls, buttons), Layout, feature placement
  
• Unit 6: International Issues in Design: Design for translation, localisation, language bias, interface bloopers, Basic English
  
• Unit 7: Metaphorics, Analogy, and Software Design: Introduction to metaphorics, metaphorics and user analysis, metaphorics and assumptions, critical analysis. Assignment: Critique an application using metaphorics principles learned in class (instructor approved topic), 15%.
  
• Unit 8: Troubleshooting Design Problems Before they Happen: Avoiding common problems (yak-shaving, inconsistencies, typos, the Comprehensible Only If Known problem), user acceptance testing with a design focus. Assignment: Using the application from the last assignment, devise a simple testing scenario to evaluate a design feature. 10%
  
• Final Assignment: Subject to instructor approval of the application/critique, prepare a critique of a well-known application using at least three of the principles discussed in the course. Max. length 3500 words, 35%, include screenshots.

Note: I know that's only 70% of the total mark accounted for; I'm assuming 10% attendance and 20% in 5% five-finger exercises, or a midterm exam or something...

____
Interface Blooper Example: I still remember from grad school, doing an analysis of Netscape as it appeared in four different languages, and finding that in German, what was then the "Guide" button in English was "Guide" in the German version as well. A quick trip to the English-German dictionary showed why -- according to that dictionary, anyway, the standard German word for "Guide" is "Fuhrer." *headdesk*

I can hear Eth's feet whistling as he descends from 30 000 feet to jump all over me for that, but I'm just reporting what that particular dictionary said, and obviously it was of some concern, since they'd left the button untranslated (as far as we could tell).

I have a friend who is possibly the world's most intelligent schoolbus driver. He is, literally, one of these mind-blowing geniuses (in fact, he once was asked to go to a research university in the US so they could recalibrate an intelligence test for people with freakishly high IQs); driving a bus is just what he does for a living.

He has a lot of unusual hobbies, however, like foiling abductions, becoming an official Friend of the Court in the Province of Ontario, and now, conducting a barefoot epidemiology.

You see, a while back he noticed that he was seeing a lot of people at work who were wearing those distinctive "melanoma bandages," indicating that they'd either had biopsies or lesions/suspicious spots removed. He started counting. He figured out that in six months, he'd seen 110 people in the office at his workplace, and of that 110 people, he'd observed 11 wearing melanoma bandages.

According to Health Canada, aggregate incidence statistics for the population he would be looking at (generally between age 30 and 65), are 18.28 per 100 000 (mean data), or 0.1828 percent.

Process Note: To derive these figures, I took the incidence data per 100 000 in the tables on that web page, selected for the cohort between 30 and 65, and then took the mean of the data. Afterwards, I divided the incidence rate per 100 000 by 1000 to obtain the incidence rate as a percentage. Please feel free to critique my math or my methodology, since although I'm not completely ignorant of statistics (it's the one branch of math I can do reasonably well), I will not claim to have even average math chops.

No matter which way you want to slice and dice those numbers, statistically speaking, they're adding up. My friend is now working with an epidemiologist with the federal government who specialises in cancer clusters. (He likes that she's a postdoc or another form of newly-minted PhD.).

To fill in a bit more of the background detail, there are environmental factors at work. Most of the people who drive schoolbuses in this area are otherwise rather outdoorsy (as Ed says, "You have to like the outdoors to drive a bus, since you're in it so much.") -- they're often farmers who are supplementing their income; most of them are men (who have a slightly higher melanoma rate to begin with, especially on the upper body), and most are between 30 and 65, as I mentioned.

As Ed remarked, "If any other profession showed this kind of a cancer cluster, they'd regulate the hell out of it." Well, maybe they will, now that they know about it. (I'm not so sure it's directly professionally-related, but we'll see what happens.)

We already know that melanoma rates are going up, likely because of a combination of 60 years of collective tan-fetish and the thinning of the ozone layer. However, I'm writing this to make (yet again) a plea that people be mindful and pay attention to trends that they might notice around them. Who knows what you might find out? As Yogi Berra was once credited with saying, "You can learn a lot just by observing." (People mock him for it, but it's actually quite profound, if you think about it.)

I mentioned the story to Rustin, and he said, "You really should write this up as a journal entry. You really are the IGCU*, because you see this stuff, and you notice it; your blog entries have the potential to make a lot of people aware of stuff long before it hits the news." I do think things like this are quite significant in a number of different ways. I also think it's important to chronicle them and disseminate the information so other people can learn and contribute.


_____
* For "Inter Geek Communications Unit," which, as he says, is because I function as kind of a nexus between a whole bunch of (groups of) geeks, and pass information through. Not only that, but I'm a huge clearinghouse of information myself. I just wish more people would tap into the resources I have available...