Another central message of the Software User Assistance 2009 conference was that DITA (created and donated by IBM) offers a useful open-source standard for structuring and managing documentation, perhaps more for its tool support than for its inherent merits. Several presenters who had issues with its information typing nevertheless used it because of tool support.

One of the central messages of the Software User Assistance 2009 conference was that Help must move into the UI itself (embedded user assistance).

Scott DeLoach (ClickStart), in his presentation "Best Practices for Embedded User Assistance", said the goal to fix Help is to [1] HIDE in plain sight, [2] PREDICT questions, [3] PREVENT problems, and [4] SEDUCE users into opening the Help they need. Research shows that [1] users simply won't ask for help, [2] they don't perceive embedded help as Help, and [3] they do use embedded help, so it has strong ROI.

The Software User Assistance 2009 conference in Seattle explored deeply how the entire field is changing and how our deliverables and methods can and must change.

Tony Self, in his presentation "What if the reader can't read?", sounded the alarm about changes in our users. Beyond the worsening literacy of the emerging workforce, the general increase in reader impatience is dooming traditional documentation. The Akami study (2006) showed that 75% of people would not go back to a site that took more than 4 seconds to load, where only a few years earlier it was 8 seconds. Given that 4 seconds is about 15 words read, it doesn't bode well for textual deliverables. Other studies show that web reading not only degrades our ability to read thoroughly, but it changes how we think and consume information. Increasingly, we're power browsers, not readers. What to do? Given our readers' move towards skimming information horizontally, reading snippets of text from different sources rather than in-depth, vertical reading, we need to change what we deliver.

Jakob Nielsen's Alertbox post, Write for Reuse, argues for changing how we write to accommodate the well-researched fact that users will discover and approach a given page in a myriad of ways. The critical importance of how we word titles and headings is part of it, but I was caught by his argument to craft the opening text carefully, as users read only this in many cases, to judge whether this is the right page to answer their question/problem. I realized that I do this myself (read the intro quickly to evaluate the merit of staying on the page).

The sessions are posted for the 2008 Nonprofit Software Development Summit, which is November 17-19 in Oakland, California:

http://devsummit08.aspirationtech.org/index.php?title=Sessions_List

It's an interesting window into what developers at nonprofits are excited about. Technical training is focusing on Joomla!, Drupal, CiviCRM, and Ruby on Rails.  Documentation topics are focusing on FLOSS Manuals and book sprints.

Here's an easy, free, cross-platform solution for grabbing screenshots of web content: Screengrab, a Firefox add-on. It includes a great feature once found only in high-end tools: It can capture an entire page/frame, including the portions that fall below the scroll. After you install Screengrab, you see an icon down in your status bar:

The problem: Our trainer had a MacBook and no connector to use our projector, and she couldn't use our Windows-based conferencing software. 

The solution: Yuuguu. It works on Windows, MacOS, and Linux, and with IE, Firefox, and Safari. Only the host needs to install anything; participants simply browse to the meeting URL and enter the correct pin to join in -- a fabulous feature, as I didn't have admin rights on the computer in our meeting room. If I were able to install Yuuguu, we could have gotten control of the web conference and shared our desktop, for full collaborative work. 

Last night, Ragan Haggard of Sun Microsystems told STC Austin about his journey producing documentation for OpenDS (an open source product) using only wikis. From the myriad available, they picked a wiki -- JSPwiki -- that met their key requirements (still in active development , syntax, rich text, content control); however, not even the best-in-class commercial wiki, Confluence, could offer the Section 508 (accessibility) and commercial quality PDF book output they still need. (He hadn't heard of FLOSS manuals, although that's still not the holy grail.)

Sounds like a steal: Austin Technology Council is presenting its annual Austin InnoTech (Business & Technology Innovation Conference & Expo) on October 16 this year; it's all but free ($35 gets you into all keynotes, exhibits, and sessions). There are also discounts for groups of 3 or more. Location is the Austin Convention Center. Check out the Software track. You can also browse last year's presentations.

I'm working my way through an e-learning course through DSA (the Course Developer Workshop), which is giving me the opportunity to analyze how they're delivering e-learning. What I'm finding rather surprised me:

• They use reference-based training: the reference material to be used on the job is delivered in a binder, along with the course elements (objectives, examples, exercises, summaries).
• The course is advanced by a slideshow, which the instructor drives throughout the multi-day course.
• The course was delivered as instructor-led training, which was audio-recorded.
• The 3-day course was divided into 6 lessons with 4 video segments, all hosted on their site (no CDs or downloads).
• The live-course audio was edited down, stripping out all student questions, discussion periods, and dead time for students to complete tasks.
• The trimmed audio was laid on top of the slideshow, as if the instructor were narrating it in real time. (This was probably the trickiest part.)
• The slideshow was enhanced with circles, markup, and highlighting, such as the instructor would do.
• The slideshow added pauses, with "Click to continue" buttons, when exercises were to be completed first.

So, the experience is that the e-learning student follows along very much like a classroom student, glancing between binder and slideshow, completing exercises, and following the instructor's voice. At the end of each lesson, e-learning students complete and email homework to a designated instructor. Instead of 3 days, students have 30 days of server access, during which to finish the course. The video segments must be completed or else homework assignments will be missed. Course completion includes testing some of the output with a volunteer subject; when I get that far, I'll know how well that works, compared to a live class.