Ian Oeschger is an information architect and software developer for IBM WebSphere Process Server. He used to work on Mozilla projects and help systems for Netscape. Also used to own a little bookstore with his wife. Now works out of his home in Wilmington, NC, and writes -- besides IBM stuff -- fiction, this developerWorks blog about information architecture and information development at IBM, and the occasional technical article or trade book.

Jython

Also this news about Django, a web framework that some say will be for Jython, upon which it is built, what Rails is to Ruby:

Django on Jython is "almost there" (theserverside.com)

Tim Bray has pointed out a note from Jim Baker: Django on Jython is almost there. It can run! There's still more work to do, as Mr. Baker points out, but Django is likely to serve Jython in the same way Rails serves JRuby: the "killer application" that allows people to adopt Jython without regret.

Taxing taxonomical differences

I'm combing my todo lists and acting on my action items, sharpening my pencils and buying ink jet cartridges and legal pads like everybody else. But I'm running into the wall of my own organizational inefficiencies as I go through my work areas and applications (Notes, Blackberry, web-based stuff, TODO lists, index cards) and attempt to categorize my projects and responsibilities. It strikes me that tags — as in bottom-up categories, informal ad-hoc taxonomies, folksonomies, whatever you want to call them — tend not to work very well to Organize Your Life. They work well at other things.

In fact, I'd propose the following contrasts (which are themselves, of course, the product of this febrile new year Org-mindedness):

Agile Development: Don't forget the documentation

An article on agile development and documentation, which we've (of course!) been discussing. Agile methodologies are known for concerning themselves less or not at all with documentation and the information development phase.

Eliminating documentation may speed software development, but it will create problems at the end as supporting groups try to figure out what the product actually does.

Content management versus authoring

We talk about CMS at IBM, too, about how we need it, how we need more of it, how much DITA should sit within a real CMS, and so forth. But I took from these early, nerd-side introductions to CMS a certain wariness for the genre, and an appreciation for the difference between "content management" and authoring. And the difference has to do with those forms, with the rules that are being built into editor: In my experience when people say CMS they are often referring to: a (very) light-weight, proscriptive editor, possibly rendered dynamically into forms by XML schema or other rules, sitting on top of fat storage system that may or may not require any human input before it "publishes" its collections. Content management systems are often extolled for their efficiency, for the amount of human intervention they can spare you if you just get them set up right (!), but they are rarely praised for the richness of the information the provide.

"Authoring" can mean a lot of things, but in this context it contrasts with content management by rendering more control to the author, by requiring an author (!), by requiring the author to know more and to decide more about how and for whom "the content" is going to be presented. It's low touch and high-touch, editors and authors. (And this is where wikis may be an exciting, loose-but-also-strict CMS/authoring hybrid-cousin?) It's ironic, because for me the word "editor" still connotes old school literary magnates like Wallace Shawn, but "editor" may be to the CMS world what "engineer" is to giant call centers, or what the place-name "Willow Creek Falls" is to an arid, chock-a-block, treeless housing subdivision. Our authoring systems at IBM give the author (and architects, and other participants) quite a lot of flexibility, a lot of control over the information. And though we sometimes complain that the flexibility of our authoring systems makes it difficult to automate or analyze or normalize or categorize our content, to get it all together, I don't think we'd want to trade this complexity for simply managing it all as content.

Categories : [   cms  |  information-development  ]

Oct 10 2007, 10:00:00 PM EDT Permalink

I heart Python

I can't think of something that's been more valuable to me as an information developer than having learned my way around Python. It's helped me do things as an information developer, of course — the efficiency you can get as an information developer when you take up text-processing, system administration, CGI, and other tools/needs is just incalculable, when you can automate and ignore some of that stuff and author instead. And that's to say nothing of how specifically well our XML-based authoring system, DITA, offers itself up to reports, parsing, transformation, and other processing.

But Python has also helped me think about things, to understand what I work on. Especially how things are designed and developed, which is key in information development and IA. You write scripts to do little tasks for yourself, then you write larger scripts, and maybe you share them, or they do something for the department. Then, using the same environment, maybe even the same scripts, you start writing programs, creating classes and libraries, you start designing things. We've created a DITA build system with it, for example, that glues together a lot of moving parts very well. I've also used Python to prototype applications that may eventually be implemented in Java or some other language, and that's because at that early phase, when you just want to start understanding the problem, facility with some language and the sensibility of Python in particular are just so useful. It can even be used to "retrotype" application logic that you want to model and understand.

I love it! This is an area where Python excels as a hybrid of object-oriented languages and scripting, of (local) system administration and client-server web programming. I'm sure there are other languages that occupy this same space — I keep hearing about Groovy; I used Perl for a long time as well. But on top of everything else, Python is finding its way into WebSphere as a scripting interface to the process server, in the form of Jython, a Java-based version of Python that lets you examine and script Java classes at run-time in the same way you do Python libraries, that can be compile into Java classes.

Categories : [   development  |  information-development  |  python  ]

Sep 07 2007, 12:04:55 PM EDT Permalink

AT&T and the iPhone

Just spent the last couple of days on vacation down at Bald Head Island, swimming with non-proverbial sharks, drinking wine. The brother-in-law of our friends and hosts there, an executive at AT&T, says that the iPhone accounts for less than 1 percent of AT&T revenue (!). So much has been made about this Big Deal, about the exclusivity of a single iPhone carrier, it's funny to think about how marginal this is, money-wise.

Obviously, the bigger benefit for AT&T is the sex appeal, the alignment with Apple, for a carrier that is struggling not to seem like your father's giant, giant, slow-moving, boring, swallowing-other-cars-on-the-road Oldsmobile. (I actually like AT&T just fine, but there can be an inverse relation between size and sex appeal, particularly with the most important hipster-kiddie demographic. (Interesting paradox: You sorta need your carrier to be as big as possible, and integrative, and reliable...))

Categories : [   business  |  mobile  |  vacation  ]

Aug 23 2007, 04:50:53 PM EDT Permalink

Technometria: Enterprise Content Management

In this IT Conversations podcast, Technometria regulars talk about enterprise content management with John Newton, Documentum founder (?) and CTO of Alfresco, an open source content management system.

IT Conversations is good stuff.

Categories : [   content-management  |  opensource  |  podcast  ]

Aug 07 2007, 08:40:53 AM EDT Permalink

Golf's secret engine

As someone who doesn't play golf at all, I've struggled to understand the fascination. But now I think I know. I think I've seen something as I drive along the road that bisects the municipal golf course, where scores of golfers are out at all hours, in summer thunderstorms and near-dark, mostly standing around or lugging their big clubs over the green. There is a secret engine to golf-love, and it is that the game is extremely competitive, pitting one player directly against others, but totally serialized in its actual play. It's the psychological concept of the partial schedule brought into microscopic, maddening relief.

You cannot swing while your opponent swings, or even right after he swings. You do not swing back at her or block her put. You can't strike him while he languidly plots his put, though you'd like to. Between each hole there are long-ish periods where no one is playing at all, and golfers make it worse by getting into small little golf carts with one another and driving. You don't yell things at your opponent or taunt her; you can't practice or even prepare for your swing when the other golfers are teeing up. Instead—and this is the secret—you have to watch while your opponent waggles his hips and puts his thumb in the air, sites along his putter and rocks back and forth on his goofy, two-tone shoes. The waiting and watching is the thing! Adrenaline is coursing through your system, as it does in any good game, but it finds NO OUTLET. Rather, golfers are forced to stew in their own sport-hormonal juices and fecklessly regard adversaries—regard their competitive, can't-stop-me preening! Because there is a lot of preening in golf, it seems to me. The formalized waiting-around of the game has created this performative aspect to golf, whereby the dude who is "up" gets to take his time, waggle, turn his back to his opponents and positively milk the slow, serialized, synchronous-transaction torture of it.

Surfing, which I do a lot of, has some aspects of this. Often there are so few waves or so few slots in the line-up that you end up watching your friends tear it up and trying to feel good for them as your testosterone melts the wax off your deck. But there isn't a sport where this watching-and-schadenfreude is so intimate, so constant and built into the structure of the game itself, and so protracted by the actual performers themselves. It's almost sadistic the way golfers are forced to wait around and watch their opponents—fully three-quarters of the players in a foursome are inert during game-play, and "game-play" in golf takes up no more than 10% of the time, as far as I can tell. At least in baseball, you're occasionally throwing someone out at home while he's sliding! Someone pitches a ball and another someone tries to hit that same ball, etc.

So you lose the golf game to a man whose back you've been glowering at for four hours, whose brisk, winning steps you've been trudging behind. And you swear you are going to get him next round, you promise yourself you'll occupy the winners-podium-before-the-game-is-done that is that the tee, where you'll waggle and harumph the wind, test the grips on your drivers for minutes before winding up.

Categories : [   sports  |  thinking  ]

Jul 11 2007, 07:52:29 AM EDT Permalink

Information builder

Taking the analogy to software development as far as it will go, ID organizations at IBM sometimes also include information builders, people whose role it is to actually assemble and deploy all the information being developed. Not every team has them, but every ID team has some need here, and sometimes (often?) the need warrants a dedicated builder. The role is meant to complement that of the information architect, whose job it is to design how the information should fit together, to create a build architecture as part of the overall information architecture: What Eclipse doc plugins are being produced? How do they relate? What other deliverables are there? How do these relate? Where and how is the source stored, and how is it built? How is information prepared for translation and integration? & cetera. But the two roles aren't always separated or even identified.

I was basically an information builder for our group before I was an information architect and may have been "promoted" out of my real aptitude (See Peter Principle). It can be an advantage to know how things fit together logically, technically, but it can also be a liability for an IA. You can be good at putting jigsaw puzzles together, at seeing the edges of the pieces and how they fit, but it can make you insensible to the picture of the cute puppy dog wearing the fireman's hat emerging underneath--even when the puzzle is done. Just a bunch of stuff you've assembled. As an information architect, you have to know and care about the content quite a lot--you have to want to see that puppy!

(In fact, you have to care about "content" so much that you do not refer to it as "content", which is an ugly word that people outside of ID sometimes condescendingly use to describe ID efforts, as if the form were the main thing and the content merely some fungible, necessary afterthought -- and I'm getting an image now of agency web developers in cop glasses and Vinnie Barbarino wristbands standing around a whiteboard full of some convoluted interface saying, "And we'll just drop the content in...here (pointing) when it's ready." And then saying "Let's do this.")

Content blindness on the part of information builders is easy to understand, given how much "form" there is to concentrate on and manipulate instead: The markup language, the tools, the storage, the general organization, the deliverable outputs -- that's what builders are supposed to think about! This is how the roles of information builder and information architect differ, principally -- when they're separated at all. An information architect's sense of the build architecture and its make-up should inflect but not overwhelm his or her understanding of the information itself, its usability and its users, its organization. A builder can nut out on the builds and the wizzy tools completely. Our team has just hired an information builder to take over responsibilities I've had for a long time, and it's "freed" me to do more "pure" IA, but it's giving me some vertigo as well, and I find myself reaching around sort of compulsively for little jigsaw pieces to fit together.

Categories : [   information-development  |  tools  ]

Jul 06 2007, 10:49:35 AM EDT Permalink

Terrapass

My wife and I just renewed the terrapasses for our cars for another year. My cousin dismisses it as liberal guilt reduction. Maybe it is! Last year we read about this "brilliant attempt to use capitalism to fight global warming" (Der Spiegel) using carbon emissions offsets and were, like many people, already feeling bad about how much time we spend in our cars. TerraPass lets you calculate the carbon emissions of your vehicle based on its make and model, its year, how much you drive, and then remove the equivalent amount of carbon emissions from the world by buying offsets on the Chicago Climate Exchange, the US's only "cap and trade" market for carbon, in which big players like Cargill, Motorola, and Ford Motor Company are already participating.

The press about TerraPass and other "cap and trade" plans has been mixed—some of these schemes are not structured to actually curb emissions from the participants in any significant way, but attract a lot of participation anyway because they relieve guilt so effectively, make you feel sanctimonious, and because cap and trade programs got such a good rep when they quickly removed acid rain as a major threat to the environment, twenty years ago now. "Additionality" is the phrase coined in the Kyoto protocol talks to describe the ability of market-based solutions to actually cap pollution: You have to do a very good job of measuring market participants' emissions, find out how difficult it is for them to make incremental changes (if it's too easy, then "capping" doesn't bring about enough additional reduction), and then have the participants trade emissions credits in a market whose overall cap—which has to slide around according to the number and polluting footprint of the participants, as I understand it—succeeds at curbing the total amount of carbon output. Costs thirty or forty bucks to zero out your vehicle's emissions, and of course TerraPass uses all sorts of third-party checks and balances, auditing and certification.

Now they have TerraPasses for your home and for plane flights as well—bands like the Rolling Stones, the Dixie Chicks, and Coldplay are buying up all the offsets for their tours, and Governor Arnold is offsetting his private jet trips (abc.com), which just underlines one of the main criticisms of carbon caps like TerraPass, which is that they can make you indifferent or complacent about more direct means of reducing emissions, like not driving Hummers. :-/

Categories : [   environment  ]

Jul 03 2007, 09:00:38 AM EDT Permalink

The M-commerce baby pool

I've just signed up for Park-by-Phone, which is working at Wrightsville Beach near our home and may make summer parking there a little easier—or at least pleasantly geekier.

You register yourself and your cell phone number with the company over the web, get a little pass to put on your dashboard, then simply enter the lot number from your phone to get the charges debited to your account. Nice because you can "feed the meter" from the beach or wherever.

Also signed my little phone up for flipMail, a service of teleflip.com that bridges SMS and STMP so you can get select emails on your cell phone. I have a Blackberry, but I don't have it hooked up to the work BES servers, nor do I have plain old email arriving there. This case, where you specify a couple of contacts whose emails you want sent to your phone, which you can do in a sort of ad-hoc way, setting up alerts, like, for friends or for other emails you're waiting for or, is kind of nice. Low-touch. I think that teleflip started just as this geeky, altruistic SMTP-2-SMS site; at least that's how I came to know about: Read something from the guy who started it: He just wanted this feature for himself (i.e., the ability to send text messages to his phone from the web) and realized how easy it would be to provide this to everyone. Now, it looks like Teleflip is forming a business model—the monetizable, other way 'round, which cellphone companies get a nice premium for, and hold as close to their chests as they can—which I think is perfectly cool, and which I've already made myself a patron of.

I'm in the baby pool of M-Commerce, mobile commerce enabled by technologies like NFC and GPS. Heard a good overview of M-Commerce and its possibilities in a New York Times Tech Talk podcast interview with Gerhard Romen, head of Near Field Communications Market Development for Nokia. Use your cellphone as your wallet. Big Mac wrappers loaded with nutritional data are already standing by to take your call (in Japan)! Podcast host also mentioned IBM's own Next Five in Five, five innovations that will change your life in the next five years. (PDF), at least two of which have you using your cell phone.

Categories : [   mobile  |  tools  ]

Jun 22 2007, 09:14:09 AM EDT Permalink

Really simple services ("RSS")

Really simple syndication (RSS). It's like that dream you're awakened from moments too early. You have a vision of how all the pieces snap into place, how everything is finally resolved, and you're floating in 98.7 degree ether and harvesting information like a whale eats krill and then you wake up and you've tied your pajama bottoms to a book jacket with dental floss and you've forgotten not only what gets wired together but why. What, in my waking life, needs to be "aggregated", what more integration do I need?

When claims about the revolutionary and game-changing nature of RSS are not explicit they are implied. They are now embedded in the breathless and unabated claims about Web 2.0 and about the internet itself. Syndication is what puts the "2.0" in Web 2.0, if anything does. It is the technological means for all this collaboration.

And I drink the kool-aid. I am awakened all the time from these dental floss dreams. Jon Udell, one technologist whose kool-aid I really enjoy, has been talking about lightweight integration and services for a long time now, since way back when Netscape, where I used to work, created RSS in its nascent, feckless form, RDF Site Summary (see RSS). Back then, users didn't see into RSS the way they do now, they didn't get it, and maybe that's because there wasn't enough information around to syndicate! You read the newspaper for your news and you went to Yahoo! for your "hyperlinks" and why on earth would you want to wire those together in some way?

Now, people "get" RSS all too easily, it seems to me. And yet I think there is more getting than using. Even those who are most rhapsodic about RSS's integrative potential (and I may be one of these) do not consummate their relationship with RSS the way they suggest it might be consummated. Like, I use bloglines and I get all excited because I can put today's weather in as one of my feeds, and then I can get some events from the local bookstore, but then I wake up and I just say, Who cares? It's just another web page. And I get the XML part too -- you have this information being published in a format that makes it maximally consumable, consumable however you want; and I build little programs that consume feeds and do little things with them, but then even about that I just say, Who cares? What's the weather like outside right now?

The most recent reformulation of RSS that I'm aware of is this idea of "really simple services" and a "bus" for such services being purveyed by Gent Hito and his company RSSbus.com (and here again: me...kool-aid...glug-glug-glug...). As part of his Interviews with Innovators series, Jon Udell has a podcast interview with Hito about his platform for consuming and producing these services, which are expressed as RSS data. Their conversation ranges into related technologies, like Yahoo pipes, and even service integration of the kind that IBM makes available. The RSSBus software, in desktop or server flavor, consumes RSS and makes data available and manipulable uniformly -- spreadsheets and other corporate data, netflix new releases, chat messages, ftp sessions, eventful and other calendar items, and anything else you can build a connector for using their APIs. Don't wake me!

alphaWorks: IBM User Interface Help System

IBM User Interface Help System Built on Eclipse

This Eclipse-based application is designed to help Java™ developers create online help systems that can be easily browsed and searched and that can run on many different operating systems or across a network. A Java developer can use this technology to create a help system that can be launched from a Help menu or Help button in the application. The created help system can be used to create a "Documentation CD" of browsable and searchable content. The help system can also be run on a server so that the content can be accessed by client machines and so that it is viewable and searchable in the client browsers.

DITA World API lookup

DITA World, an index of DITA resources, has this great DITA reference lookup system using gotAPI.com

DITA Storm: Browser-Based DITA XML Editor

One of the things we talk a lot about in information development is the need to get well-structured documentation from upstream, from our development organizations and other groups whose work we track, organize, and document.

We have DITA, this great XML language for authoring, and have been largely successful at creating an authoring system, but it has us spending quite a lot of time converting other stuff before we can incorporate it within our larger information set. We've wished for and had specific occasion for needing some kind of light-weight, wizzy-ish (WYSIWYG) DITA editor we could make available to non-ID collaborators, and now it looks like there's a third-party solution out there (and this is further testament to DITA's increasingly broad reach): DITA Storm. I'm looking it now casually and may have more to say soon. It's a browser-based, AJAX-y, fancy forms, DITA editor that hides (if you want) the markup and infrastructural complexities of the DITA files into which your input is stored.