notes from 29,000 feet
On the ground Atlanta was dark and dreary, but as we emerged above the cloud layer the view was (and still is) breath-taking. The sun is nearly at the horizon (that is, the cloud-horizon), and the yellow-orange light plays beautifully across the "ripples" in the clouds. Baruch ma'aseh b'reishit (blessed is the source of creation), or words to that effect. (There actually is an appropriate blessing for situations like this, but I don't know what it is and my siddur is in the overhead compartment.)
If there was any doubt before now, I now know that the travel agent who booked my flights isn't touching my future travel. I'm too big for middle seats on airplanes. Sheesh. Fortunately, that was only for the Memphis-Atlanta leg. The flight from Atlanta to Pittsburgh is sparse enough that I wonder about choice of plane. How far in advance do they have to commit to the plane, I wonder? Do they even take purchased tickets into account, or do they just have heuristics about the source, destination, time of day, and day of week?
The conference was quite good, though not always what I
expected. The theme was "engineering quality" (for
documentation), so I hoped to come away with some
QA-related metrics and methodologies that I can apply to
our documentation. I was particularly looking for hints
for long-term maintenance of doc quality, as opposed
to the initial check of a new document; I recognize that
this is hard, because you can't exactly write regression
test suites for docs the way you can for code. I didn't
come away with a lot of ideas for that, but I did get
some ideas for the up-front QA, and there are some
interesting ideas out there that, over time, should make
"doing it right the first time" easier.
Surprisingly, there is a lot of interest in collaborative techniques, and we saw a demo of a tool that allows multiple people to work on a document simultaneously with all the right things happening. The document text is stored in a database, and the set of meta-data is rich -- so you always know who did what to which parts, and you can annotate the document in various ways. It immediately made me think of CoMotion (our company's product), of course, because while this tool was specifically about text, the idea of collaboratively developing work products is much bigger than that. I talked to a few folks about CoMotion and there seemed to be broad interest in knowing more about it. I think some of my coworkers should work up a paper submission for next year. (They aren't really all that interested in the implementation, so we could talk about usage without ruining any trade secrets.)
I also got some ideas that we can use in CoMotion. In particular, when we do get to the point of doing our online context-sensitive help (which I think we need to do, though I don't think there's budget for it), we should be using our own tool to manage it, not something like HtmlHelp. If we write our own integrated tool, users can augment the help, suggest re-organizations, create links, and otherwise adapt it to suit their needs. The "source" needs to live externally (in XML in my opinion), but that doesn't preclude a living project-specific copy in each application built on CoMotion. I need to think about this more.
On this trip I got some insight into some historical
halacha. On top of "basic kashrut", there is a body of
halacha (law) and minhag (community custom) around food
and gentiles. Some of this was, as I understand it,
specifically developed as a block to fraternization
-- the rabbis felt that if we couldn't eat with them
then we wouldn't let them lead us astray, including
into intermarriage.
Now we, in the 21st century, like to think we're smarter than that. And I think we mostly are, but seeing some of the food problems on this trip, I have new appreciation for the problem.
Some background first: The last time I went to a conference, I requested a kosher or vegetarian meal for the banquet. I was betting on vegetarian, but the conference organizers axtually went the extra distance and ordered a kosher meal, which I appreciate. Based on the price of the banquet, I assumed it would be a sit-down meal. In fact, not only was it a buffet, but it was one of those events where everyone mills around and no one actually sits much. So there I was, with a large box of food, unable to really mill much. It hindered my ability to socialize, and I felt awkward. People were staring at me (maybe not as many as I perceived), and I wasn't able to do the things these banquets are created for -- networking. A more extroverted person than I (and that's a large portion of the planet) would have been able to make it work, but I had trouble.
So this time I figured I'd just fend for myself. There had to be some vegetarian food (or fish), right?
According to the locals, the south doesn't really do vegetarian very well. And they interpret "fish" as catfish and shrimp, based on what I saw on dinner menus on other nights. While I found things to eat, it was a challenge. At the banquet I ate raw cheese (which a more strict person wouldn't have eaten; I don't have issues with rennet), potatoes, pickles, and bread (and dessert). The entrees were pork ribs and some sort of chicken-ham-cheese combo, and the vegetable was baked beans with pork. No salad, no actual vegetables, no fish. One other night I ate a salad for dinner (no entrees on the menu were kosher); another night I was lucky enough to find a black-bean tamale (which was really really good, by the way).
I have new appreciation for Jews trying to live in this environment. I was only there for four days; that's easy, relatively speaking.
Short takes:
Either the wireless card or its configuration for this laptop is broken. (So maybe the Pittsburgh airport does have wireless access after all.) Fortunately, the wired access worked fine, so I could access the net from my hotel room if not from the conference center.
FedEx sponsored a building ("FedEx Institute of Technology") at University of Memphis. (This is where the lab we toured on Monday is.) It was a little odd to hear people talking about "running over to FedEx" when they weren't talking about shipping packages. :-)
I didn't know that the idea of design patterns existed in (physical) architecture long before it existed in computer science. The relevant name here is Christopher Alexander.
Michael Priestley (from IBM in Toronto) looks really really familiar, and he thought the same about me. We were both at SIGDOC in 2000, but I don't think my memory is that good, and I don't think I did anyhthing to draw attention to myself there. (It was a larger conference, so it was easier to be invisible.) I wonder if I know him from somewhere else and, if so, where. I'll have to see what Google says about him. (I wonder if he'll be doing the same thing. :-) )
The attendance seemed to be about evenly divided between academics and industry folks. You could sometimes tell that they live in different worlds.

SIGs
And there were industry folk. The ones who had the smarts to realize that they could connect with a whole bunch of academic types and get some really good exposure or ideas/feedback for their product/service/company/widget. In fact one of the keynote speeches was delivered by a then-VP of AOL (don't know where she is now, and I don't recall her name) who had made the jump from an academic institution.
Judging from my recollection of the conference setup, and from what you've said, I think it would be fair to say that ACM supplies general guidelines for the conference, but a lot of feedback doesn't get transmitted from host to host. SIGUCCS even had transition meetings (at the conference, natch) where the next host committee can sit down with the current host committee and trade notes, but there were still problems.
I did learn a lot. And I was able to make really good use of it, too.
Sounds like you had a similar experience. Glad you had a good time!
Re: SIGs
Yup. And it works both ways, too. I met someone at this conference who is probably very interested in doing research based on us. Hard to tell if it'll go anywhere, of course, but that could be nifty. (One of the results of our product is that users invent new ways to share information on the fly, and new patterns of usage evolve. This is one of the things I think we need to submit a paper on for next year. We have people who have closely observed our users in the field for months; they've learned a lot and could share some of it. We're industry folks, not academics, so we're less concerned with what can be learned about underlying theory than about practical results, but that's critical to other folks.)
By the way, SIGDOC had a meeting on Sunday (before the conference) that, I'm told, included a fair bit of transitional stuff for next year. Next year's chair gave a presentation on the last day about his plans for next year. So at at least that level, transitional stuff is happening within SIGDOC. Interactions with other SIGs seem to be more ad-hoc.
Re: SIGs
My institution hosted the conference many years ago, before I even started working there, that was widely regarded as one of the best in institutional memory. (Pun not intended, but I'll take it.) Somehow, that feat has not been easily replicated.
Now, why would you hold a transitional meeting for the next conference before you've received feedback on the current one? You'd think that determining the good and bad and the hows and whys after the fact might be a good thing to pass on. You'd also figure that as time went on, this information might get compiled into a living document. That would certainly make things easier for hosts, hosts-elect, those who are thinking about hosting, conference weenies, and so on.
Ironically, you'd think that would be obvious to those involved, even tangentially, with information systems, but especially with those who specialize in documentation. I'm sensing a certain amount of meta-introspection failure here. The documentarians have failed to document themselves. Oh well.
Google is NOT a verb!
Re: Google is NOT a verb!
Not yet, anyway. Give it time. (You'll note that I didn't use it as a verb.)
He's pretty involved with that aspect of the industry, isn't he?
Yup. The presentation he gave at SIGDOC was on DITA, which sounds like something I need to learn more about. Think object-oriented XML, kind of.
Re: Google is NOT a verb!
Nope. Not gonna. :)
*prepare yourself for a soapbox tirade*
I'm a systems and support guy. No programming at all. I stopped with PASCAL in my college daze, and have since forgotten most of it. I learned about 4 HTML codes in the early 90s to put up a "Hello World!" webpage because it was cutting edge at the time to even have a personal webpage. Like PASCAL, I've forgotten at least 3 of those codes. I even try to avoid macros and scripts unless absolutely necessary or amazingly useful.
As far as I'm concerned, my job is to make the bug-ridden crap that most programmers produce fit into the business operations model while trying to avoid the converse. Sadly, my view tends to be marginalized. Organizations sometimes don't realize that the software is a tool. It should be used to enhance efficiency, not control processes. When an entity falls prey to the "Everything looks like a nail" syndrome, productivity actually drops, and it can be difficult and expensive to correct. Make the software fit the job, not the other way around.
Hmm. I didn't realize how high this box was. :)
Long story longer: I'm not a programmer and don't play one on TV.
For the record: It's more important for people in my function to be able to communicate to the programmer(s) what features we do and do not need, and to identify, replicate and report bug or problems, than it is to write code. Anyway, I don't have the right combination of psychodynamic flaws that produces good code.
Re: Google is NOT a verb!
What XML, and DITA, do is allow you to apply semantics to content. Properly used, they make it easier for you to get what you need, not harder.
For example, given a body of technical documentation, DITA would allow me to explicitly label the conceptual discussions, the step-by-step instructions, the examples, the known bugs, the required and optional parameters, and so on. With the right tools, crawling through that would be a lot easier than scanning text (HTML, book, or whatever) looking for the parts that you're after.
So far what I've said is true of XML in general. What DITA adds is explicit relationships. So I can, for example, define something called "topic", which has a title and a body. Then I define a "task" sub-entity, which has everything from "topic" and pre-conditions and post-conditions and ordered steps. I also define a "comamnd reference page", which replaces the "title" inherited from "topic" with the command name, has everything else from "topic", and adds a command name, required arguments, optional arguments, return values, and error conditions. Maybe I have a specific sub-type of "comamnd reference page", which covers administrator commands and adds a "required privileges" element. And so on. Then, when I'm actually writing, say, a command-reference page, I've got explicit labels for each of these things and if I leave out something required, the processor will complain and make me fix it.
While this certainly has the potential to become overly geekified, as some uses of XML do, I preliminarily think that it's a useful approach.
Make the software fit the job, not the other way around.
I agree.
Re: Google is NOT a verb!
To bastardize Billy Joel, "It's still programming to me." :)
Hm. "When computers can be programmed in correct English, the programmers won't be able to use English correctly." See other comments to this post.
Re: Google is NOT a verb!
Re: Google is NOT a verb!
I get that a lot. :)
OK, so let me get this strait. DITA is used to document X (nominally programs) by providing semantec context for the X or the use of X so that you don't miss any parts of the documentation?
That's still programming. It's just that now instead of writing executable code, you're writing executable documentation. I don't see this as a huge leap forward. :p
Re: Google is NOT a verb!
Re: Google is TOO a verb!
-- Dagonell
Re: Google is TOO a verb!
Re: Google is NOT a verb!
"Google" is a proper noun comprising both a company and a product name (the product being both the database and the search tool.) One uses Google to search for information. One uses Altavista or Lycos or WebCrawler or DejaView or Oracle to search for information. Using "google" as a replacement for "search", especially when not referring to searching Google itself, is simply bad english.
Go into a large university library (if you can get in) and ask to google their non-digital special collections archive. You'd be lucky if they don't execute you on the spot.
*This post interrupted at this point by a phone call from Karen on an unrelated topic*
Yes, languages do change. I get that and have no problem. And yes, I am a purist, but that's only because I'm tired of not being able to communicate with other people who are lazier than I am, or less educated than I am, or simply don't think the same way I do, because we're both speaking English, just not the same English.
Great. Now I'm grumpy. :)
Re: Google is NOT a verb!
Actually, mostly when I hear people say "let's google that..." they mean they are going to use Google. So by your definition that's just fine then. ;)
only because I'm tired of not being able to communicate with other people who are lazier than I am, or less educated than I am, or simply don't think the same way I do, because we're both speaking English, just not the same English.
I'm actually fairly certain that you can communicate just fine with someone who says they're going to google something or who asks for a kleenex when they mean tissue, or who says they're going to xerox something when they mean photocopy. The point of language is to communicate ideas. If someone said give me a kleenex and you didn't understand them, it wouldn't be because they were lazy or stupid, it'd be because they said "kleenex" in swahili.
Re: Google is NOT a verb!
I'm not bothered by part-of-speech transitions when they are effective communication. Often, though, they're either cumbersome or confusing. Consider most business-speak. I also have a problem with "coffee my tables"; is it so hard to say "check in on"? It's not really inaccurate, I'd bet, because if you show up with a pot of table somebody is going to ask for more Coke and you're going to have to do something about it.
no subject
Jews in the South
For the most part, I don't think they do. I'm not sure if there aren't Jews because the south doesn't do fish/vegetarian well, or if the south doesn't do these things because there aren't Jews.
I learned IN HIGH SCHOOL that there are Jews living in America. I learned this because I dated a guy who had just moved down from New York and was surprised not to find any Jews.
And they interpret "fish" as catfish and shrimp, based on what I saw on dinner menus on other nights.
Of course not. There's crab as well ;-)
Re: Jews in the South
Probably some of each, but I'd bet mostly the former. Jews are a small portion of the population (though sometimes a vocal one :-) ); no one who wasn't already inclined to be somewhat open to change is going to adapt something as basic as cuisine to satisfy a small minority.
I learned IN HIGH SCHOOL that there are Jews living in America.
Having grown up north of the Mason-Dixon line I knew about them earlier, but I still didn't knowingly meet any until college. (Small town, very Christian.)