Skip to content, navigation.
Have run across a couple of cool screencasts lately that thought I'd share here.
Hey, we've just recently wrapped up a set of doc deliverables for an OpenSolaris Student Pack that is going to be distributed at various campus events this fall (back-to-school special :-). The student pack has an updated Live CD and an accompanying DVD. The DVD includes the VirtualBox installers for Linux, Windows, and Mac, and a pre-configured 2008.05 OpenSolaris virtual disk image (VDI) that is ready to go. The VDI includes a bunch of developer tools / environments, so it eliminates the need to go looking for these packages. This has got to be the simplest, most straightforward, and lowest cost way to get OpenSolaris running, so hopefully, students will give it a whirl.
Oh, and the accompanying docs on the DVD include the specific instructions necessary to install VirtualBox from the DVD and configure it to use the VDI. (Wish I'd had this when I started. :-) The docs also feature an admin guide targeting the laptop user. This doc has been conspicuous by its absence, but now that we've got a baseline, we'll develop it a bit more and provide with the November OpenSolaris release. There is also a nice set of developer docs to help the student get going with OpenSolaris, Web Stack, DTrace, SQUID, and NetBeans. I'm anxious to get these into students' hands and get folks looking at OpenSolaris.
I've just recently returned from a nice get-away to the U.K., Germany, and Switzerland. While there, I traveled almost exclusively via bus, train, and subway. Those are such reliable and affordable means of transportation; we don't really have much that compares with them here in the States.
Winding my way around London via the tube, I had a little epiphany: the London Underground map is one of the greatest pieces of user documentation ever assembled.
(To be fair, am not sure if the London Underground came before the Paris Metro, cause I think it is equally simple to read and get around.) In a city of many millions of people with thousands of combinations of connections to get you from point A to point B, the tube map is an incredible model of simplicity of information design. Zones, lines, stops, transfer points...it's all easy enough to comprehend that my daughter could easily map out routes for our various expeditions throughout the city. Ah, if only computer software were this digestible :-)
I recently read Lou Ordorica's very informative Social F/X blog on driving community participation via design. One of the really intriguing things Lou has done is create sdnshare -- a digg-like forum for contributing info and tech tips with a built-in rating page for content . (For the inspiration, see www.digg.com.) This got me thinking about digg....
Now personally, I've become a bit disenchanted with digg. I never did the analysis, but came to believe there were a handful of keywords in a title that could guarantee high number of diggs. But digg is interesting in identifying market interest or a constituency (and the relative size of that constituency) around some topic. On face value, I think people make an implicit connection between a high number of diggs and the value or merit or goodness of that content. However, that's a little misleading because at some number of diggs, everybody follows the link just because it's what everyone else is doing. It's kind of like when a crowd huddles on a sidewalk; if you're walking by, you'll stop out of curiosity to see what everybody else is looking at, just because.
I think rather than placing a merit value on the content, the number of diggs really suggests the size of the market interested in the topic (modulo that case where people are just gawking on the sidewalk...interested enough to look, but not really engaged). (The truth is, there is some very fine content posted on digg with only a few diggs, but there just isn't a big enough constituency to drive it to the top of the digg list.)
Now, all that said, I think Lou's idea for using digg-like ratings on content is an intriguing way to build community around some of our technical content. It is something of a rating system (although, as I've said, I'm cautious about reading too much into that). I think the more telling information we could derive from the results is who's doing what. A high or low number of "thumbs up" for a particular piece of content does say something about the size of market for that information.
In discussion with some of our community members, have heard that the Sun doc set represents the "crown jewels" of technical information. And I heard this "crown jewels" quote not long after chatting at CommunityOne with folks who were clearly in awe of the wealth and breadth of technical information produced and provided by Sun. So, all-in-all, I think that speaks volumes about the competency and wherewithal of the Sun doc teams. (Plus, they can write killer haikus.) Now, as a company diving into the open source swimming pool, I think we're in a unique position vis-a-vis other open source distributors who rely pretty much solely on the community to produce their technical documentation. We've got these crown jewels as our basis. Seems to me, the trick moving forward is to keep them polished (i.e., accurate, up-to-date, and easy to access) while adding gems from the community. In my mind, I see these as a bunch of small, focussed topics (how-tos, cookbook recipes) that the community experiences in depth and breadth greater than any given doc team can anticipate or accommodate. The trick, I think, is to make the barrier of entry low so it's painless to donate those gems to the collection.
I got a chance to chat with Karsen after his presentation and he elaborated a bit. He pointed out that they originally started with a structured framework (albeit, lightweight) for doc contributions, and the level of contribution was pretty modest. Once they moved to wikis, the level of contribution skyrocketed. He mentioned that they then exported from wiki to structured format. (They used MoinMoin Wiki engine).
This sounded like an interesting approach to both cultivating community involvement and munging unstructured content into a structured format that could [presumably] be leveraged like you would expect a structured document.
He did confess that the structured output was crude, but still, sounds like an approach that warrants further investigation.
I worked at Sun previously between 1993-1997. I worked at the Rocky Mountain Technology Center doing system administration and installation docs. I had some great experiences and opportunities there, not least of which was to co-author a couple of books:
I've also worked in the past to encourage other writers and engineers to become authors. To that end, I used my relationships with the folks at Prentice Hall to help turn burgeoning writers with good ideas into published authors.Now, I'm back at Sun to try to replace Michelle Olson as the community manager for the OpenSolaris documentation community. (Michelle, I'm not saying you have big feet, but your shoes are obviously going to be hard to fill.) That said, I'm willing to take a shot at it. I hope to carry on the fine work Michelle has done to date and to look for ways to grow and expand the OpenSolaris documentation community. Of course, I'll need your help in doing that, so I look forward to the exchange of ideas here on how to take that community forward.
This blog copyright 2009 by Alan McClellan
