Clever Hamster

Hope for virtual papers: Times Reader

I'm in love with Times Reader 2.0, the New York Times on-line newspaper application (using Adobe AIR). It offers so much of what's great about printed paper, and it's always as fresh as the website (updates every five minutes). It's pure UX joy: simply gorgeous to look at, easy to read, compelling usefulness, usable offline, entertaining (crossword puzzles, multimedia), and seamlessly tied to live updates and archives. And less is more: its brevity (just today's content) and visual form factor keep it tight and manageable, compared to the NYT website.

So, the Times Reader has done the impossible: it's renewed my faith in future of virtual paper publications, after having been repulsed by countless PDF page-turners of various forms. For me, the experience feels very different from reading a website, one that's even worth (gasp) paying for.

Because of how my brain works, I'm irresistibly drawn to News in Pictures: an always changing slideshow of images with captions. I can scan through a hundred in minutes, always able to click through to the full story for any that call to me. For my very visual mind and chronic rushed state, this scanning strategy is a compelling way to browse the newspaper, coming away with a head full of thoughtful photography to ruminate on even when I don't have time to read every gem.

Simplifying browser jumping: Firefox's IE Tab

I've just installed Firefox's wildly popular IE Tab add-on, which promises to make my life easier! The problems:

• remembering to always open certain applications and sites in IE
• doing without functionality (such as Window Resizer) I have in Firefox only
• needing to quickly toggle a given URL between both browsers, for testing

The solution is this add-on that hosts Internet Explorer inside of Firefox and allows you to control which browser context is used for which site. (That is, open the site via FF, and it launches in the right browser; one right-click lets me toggle between browsers.) Sites I run in IE include several web conferencing tools, Outlook Web Access, and IE-only applications I document. Some tips:

• To jump to IE, right-click on a page and select View Page in IE Tab.
• To always make that jump, click on the IE icon down in the status bar and add the URL. By default, it will pick the subdomain, so, if you just want the page, you need to change it.
• Click on the Firefox icon in the status bar to switch the rendering engine or open in a new tab in IE.
• Use the Export option to transfer your settings among multiple machines.

List: On-demand book publishers

I've been using Lulu for several years now at work, as a production tool as much as a book printer: I upload manuals and coursebooks in Word format (produced from Author-it) and use Lulu to generate the print-ready PDFs of both contents and covers. While my company is moving closer to the holy grail of full on-demand manual publishing, there's still trepidation about whether this is the best option out there. So, while I have to justify Lulu in comparison to local printers, I'll also put out the many on-demand publishers who might offer better value propositions for different situations:

• Authorhouse
• Blurb
• Booklocker
• Booksurge
• Createspace
• iUniverse
• Lulu
• Trafford Publishing
• Wordclay
• Xlibris 

Several years ago, I got bids and proposals from Trafford Publishing (who have a division dedicated to on-demand technical manuals), but the model and level of automation/virtualization wasn't quite what I was after or could sell to my organization. I hope to find time to visit and review these other players in this exploding field.

List: On-demand book publishers

I've been using Lulu for several years now at work, as a production tool as much as a book printer: I upload manuals and coursebooks in Word format (produced from Author-it) and use Lulu to generate the print-ready PDFs of both contents and covers. While my company is moving closer to the holy grail of full on-demand manual publishing, there's still trepidation about whether this is the best option out there. So, while I have to justify Lulu in comparison to local printers, I'll also put out the many on-demand publishers who might offer better value propositions for different situations:

• Authorhouse
• Blurb
• Booklocker
• Booksurge
• Createspace
• iUniverse
• Lulu
• Trafford Publishing
• Wordclay
• Xlibris 

Several years ago, I got bids and proposals from Trafford Publishing (who have a division dedicated to on-demand technical manuals), but the model and level of automation/virtualization wasn't quite what I was after or could sell to my organization. I hope to find time to visit and review these other players in this exploding field.

Agile's natural disciplines

Working in 2-week iterations in agile scrum teams is surpassing all of my expectations; it's like sudden pain relief revealing the level of pain you've long grown tolerant of -- it's hard to measure while still immersed in it. Software methods come and software methods go, so I was stunned to see agile change everything about what we do, immediately and profoundly.

What has surprised me above all else is the set of disciplines that agile methodology both requires and inherently teaches. The list I sketched out for myself seems more like a Buddhist Eightfold Path teaching than anything very specific to software engineering:

1. Right focus: The iterations force us to narrow our attention to stories that can be absolutely completed in our tiny 2-week sprint. This gives us permission to ignore the crushing enormity of the backlog of wishes and to calm anxiety about the epics looming beyond, some of which bear the dead of prior expeditions. Agile lets us focus just on the next quarter mile of an unknowably long journey, our eyes on the snake in the path right now and our collective creativity focused on getting around it.
2. Right prioritization: The limitation of the short sprint forces us to negotiate with our product owner about  priority and relative benefit. Now that product owners believe that they will definitely receive the things that the team commits to build, they are more willing to make the hard choices and figure out what they really need first. Gone are the monolithic product plans in which every requirement listed holds equal urgency, with no guidance on how to trim it when (not if) the project buckles.
3. Right allocation: The agile teams are sacred resources, and members get pulled off of sprint work either by overtly reducing their capacity (which protects the success of the sprint) or by negotiating resource trades with the other entity that benefits. This dedication of individuals to the project they are sprinting on is something I've never seen before: always before, competing organizational urgencies (fire-fighting) trumped all project work, without practical adjustment of the project to keep it on track. We were always doomed before we began, and we knew it.
4. Right collaboration: It's not enough to put people onto teams and command them to collaborate: unless all team members are working on the same narrow deliverables at the same time, real collaboration is infrequent and underpowered. Agile sprints force everyone to be on the same page, even if they're not in the same room, and this shared work focus and their mutual dependency fosters collaboration across all disciplines.
5. Right accountability: Knowing that we're only days away from a public demonstration of our work has incomparable clarifying effect. We all know exactly what each of us has committed to contribute and achieve, and we all know that failure by any one of us casts failure across us all (because we cannot demonstrate any story that falls short of the Definition of Done).  The power of this foundation in integrity cannot be measured: we are known by our work and our word. No one can hide behind seniority or reputation any more.
   
6. Right stride: Agile teaches us to be honest about our abilities and limitations, and to work ever harder on practical task estimation, so that we can make good on our promises. No longer do we paper over poor planning with heroics and self-sacrifice, which breeds resentment and burnout; rather, agile teaches us to use velocity data to find our true, sustainable pace, as individuals and as a team.
   
7. Right speech: Core to Scrum is communication: both daily standups and day-long real-time conversations. In waterfall, project communication happens often in Word files, which is the slowest, heaviest, most inefficient approach. But more than talking, Scrum teaches the necessity to protest: we learn to speak up when we're not confident about tasks and stories, when a process isn't working, when we don't understand or agree. The interdependency of the team supports such honesty: the plane doesn't fly until we all get on board.
   
8. Right failure: That every sprint failure is met with calm analysis in the retrospective and immediate course adjustments changes utterly how we see mistakes. Now failures are subject matter for intensive learning and jet fuel for creative change. Small failures early on pay handsomely in disasters averted and new discoveries made. Lack of failure is suspect: it means teams are aiming way too low, staying safe and stuck.
   

One way to summarize these benefits is that agile restores trust: agile teaches and strengthens mutual trust and frees everyone to take risks, safe in the knowledge that the overall sprint series will end in success. Another way to boil it down is to say that agile, by its essential nature, rewards people for doing the right thing. And isn't that the foundation of enlightened animal training everywhere? ;-)

New Kindle to change college reading

The Kindle DX is coming.
It seems squarely focused on winning the collegiate market, with news of textbook publishing partnerships and deals with universities to distribute the new Kindles. The much larger screen and storage capacity seem exactly calculated to support the needs of textbook content, which typically include graphics, tables, and diagrams. Given that students hate having to buy textbooks, lug them around, see them go out of date, endure the mark-ups of others, and sell them back, I see this move as almost inevitable. The Kindle offers a dynamic reading experience, where students can highlight and bookmark as they go, hypertext around, and research terms and concepts on the fly. Add to that the fact that the Kindle can enlarge text for the visually impaired and can "read" material to you via headphones, and a much larger population is now served with the same publication (although Kindle supports true audiobook formats as well). I foresee lighter backpacks everywhere in the near future.

Update: Competitors are jumping into the market, so the horses are out of the gate!

InfoQ: Questioning personal "agility" (caffeine culture)

InfoQ's Agile section just posted a presentation that questions the reliance on caffeine in agile workplaces, that caffeine usage masks the fact that development tends to take place in very poor environments, in terms of amount of sleep, natural light, physical breaks, and daylight rhythms. Interestingly, studies show that introverts (the majority of developers) don't experience the performance improvements from caffeine that extroverts do. Check out "Spiders on drugs" -- from NASA research:

The Parthenon, in agile iterations

This past week of corporate SCRUM training with Bob Schatz took me from just reading about Agile with envy to actually trying out its principles -- albeit with marshmallows, and I'm not referring to his team-building marshmallow-and-spaghetti tower contest (which my team won, I'm proud to say). No, this was a real-world project: my third-grade daughter committed to building a model of the Parthenon out of marshmallows to complete her independent study project. Her teacher was worried for her -- with reason.

What I learned in Agile training was the power of quick iterations, to fail quickly, diagnose why (retrospective), and adjust strategy for the next go (sprint planning). Far more effective than trying to think through all the implications, dependencies, and weaknesses of a theoretical design is to simply build it and test out your concepts (and show it to your customer), while there's still ample time to change. If the pot you're throwing is crooked on the wheel, Agile says to punch it down and begin again, applying what you've learned about centering the clay -- but a waterfall mentality urges you to salvage the crooked pot because you've already invested so much in it, which is the folly I've worked under throughout my professional life.

Here's what happened tonight: We sat down together with our materials and built simple prototypes to test her basic assumptions, such as that marshmallows should stack well (they don't), that linguini should offer enough building stability (not hardly), that sinking the linguini into the project base material will steady the columns (only somewhat), that crossbars of linguini through the marshmallows will stabilize the row of columns (they couldn't), that little marshmallows for the interior columns would be as easy to make as the larger ones (they weren't). That led us to tests with bamboo skewers that promise much better results. Off to the craft store tomorrow, for more materials to test.

So: several 10-minute interations saved us untold panic and despair had we kept planning away and stockpiling materials, expecting it to come together on that final weekend. By letting our iterative tests drive our design direction, we greatly lowered the risk of project failure: early design failures lead to design breakthroughs and success, just as they do in evolutionary systems. So, if you want to promote successful adaptations, best to have the lifecycle of a fruit fly (short iterations).

I'll post photos when her project is done. :-)

UA2009: Documentation's changing world

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.

• Essential changes: [1] do standalone, topic-based authoring, [2] edit down the text (say it in 15 words!), [3] single-source aggressively, [4] slash production time.
• Radical changes: [1] abandon the TOC (no one reads top-down), [2] abandon task help (conceptual only), [3] move to non-textual communication: graphics, videos, animation, [4] support collaboration (users prefer peers to manuals, see wikis as legitimate), [5] publish to YouTube, podcast, tweet.
• References:
  • http://www.newsweek.com/id/106554
  • http://www.theatlantic.com/doc/200807/google
  • http://nz.youtube.com/watch?v=dGCJ46vyR9o
  • http://shifthappens.wikispaces.com
  • http://user-assistance.blogspot.com
  • http://www.commoncraft.com
  • http://www.gerrymcgovern.com/nt/2008/nt-2008-07-14-selfish.htm

David Novick (UT El Paso), in his presentation "Research on Help", echoed the alarm with results of new studies of user behavior. Most user frustration came from newbie errors, complexity, delay, and awkward UIs. Their study of college-educated users struggling to learn a required application showed this:

• Users generally use Help very little, and they use printed documentation almost not at all 
• Majority succeeded without the Help: sought help from others, and self-taught from trial and error
• Users waste a lot of time with ineffective workarounds
• Tutorials did increase use of Help
• Users want examples, scenarios
• Users performed worse with age, and they were aware of their own ability level
• Use of Help itself did not generally improve task performance

UA2009: Embedded user assistance (help in context)

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.

He recommends using whatever field-level help is possible, such as examples, guidance, and Help links posed as questions or tips. Help icons (question marks) are not the best visual device, given that users resist requesting "Help". Prefer any solution that keeps users from leaving the context of the page or having to take action (such as roll over or click) to see the guidance. Best practice for linking to external Help is to link brief guidance to a truncated preview of extended guidance, which links out to the full Help text, without calling it such.

More radically, he urges us to implement a Help pane within the UI itself, either as permanent screen real estate or as a collapsible area. This content should focus on high-value user questions, to keep them from getting stuck or making errors. This Help pane, if rendered using AJAX, could be easily set up to accept user comments and ratings and, more importantly, to be editable from the UI itself -- such that developers and writers can collaboratively create embedded Help in place in real time, with no external processing or off-line production. The pane could be made read-only when shipped, or whatever the use case indicates.

In both scenarios, the content should be stored in the application's resource files, which is important for many reasons:

• supports application modularity (add a new module, and its resource files and thus its embedded Help comes with)
• supports localization (third parties have the source they need for translation/customization)
• supports third-party development (external developers can add their own embedded Help without special source/kits)
• supports just-in-time updates and zero production time.

Should that content be needed for external references or training, simple scripts could write out the contents of those resource files. The presentation slides include source code for the AJAX implementation described.

The separate panel discussion on embedded UA detailed more requirements:

• Embedded UA must be [1] directly relevant to the needs of users, [2] highly selective, [3] very concise, and [4] very compelling 
• Writers must change roles: [1] get in the code: edit resource files for error messages, tooltip text, field names, etc., [2] help with usability testing, [3] guide UX, [4] manage/edit collaborating authors

Resources:

• "What is the Technical Writer’s Role in Interface Design?" http://www.idratherbewriting.com/2008/12/14/bogo-vatovec-technical-write...
• Usability Professionals Association: http://www.upassoc.org
• Interaction Design Association: http://www.ixda.org
• Information Architecture Institute: http://www.iainstitute.org
• "10 Most Common Misconceptions about User Experience Design" http://mashable.com/2009/01/09/user-experience-design
• "A definition of user experience" http://www.fatdux.com/blog/2009/01/10/a-definition-of-user-experience