Tag Archives: wiki

STC2008 – Mining Web 2.0 Content for Enterprise Gold

Most definitions of Web 2. 0 are illustrative, but Michael Priestly prefers text.

He’ll pick 2 core Web 2.0 concepts for today’s talk – wikis and mashups to discuss, but there’s also blogs, tagging, social networking that could also be mined.

Wiki’s problems
Content is unstructured, you don’t know if it contains the elements of, say, a tutorial, because there’s no validation.
Content is non-standard
Content is tangled – links are easy, but selecting just a subset of wiki content results in broken links.

Problems with mashups – sources of content are standards, can’t share mashup definitions

Sum of it all – wikis don’t mash well.
You just get faster creation of silo’d content, faster creation of redundant content, faster creation of more content that you can’t reuse.
So true – “If we want others to collaborate with us on content, we usually make them use our tool.”

Scenarios he has done or is doing at IBM:
Create DITA, publish to wiki

Create DITA, feed to wiki-make those DITA pages non-editable. Example: tech support database when answer eventually moves into product docs with stamp of approval
Example: One Laptop Per Child working on collecting Wikipedia articles out of DITA to let teachers make custom curriculum that small, lightweight, portable.

Create DITA, migrate to wiki (with roundtrip in mind). Migrate to DITA is more difficult because of version history tracking.
Throw away formerly semantic content, unfortunately. Funny comparison to archeology dig – why did our predecessors bold this text? It must have had some meaning? About something? Here, the example is porting previous releases’ scenarios.

Create wiki, publish to DITA – wiki redirects edit actions to the CMS, which houses DITA, then republishes the DITA XML to wikitext using an XSLT transform. Invision is doing something like this where you edit the wiki page in a DITA editor, store it back to DITA, publish it to the wiki page. Also Web Works Publisher will publish source to wiki text (although I don’t know about getting back to DITA).

Or: native DITA wiki: portable content – move content in and out

with standardized sources, you can dependably point a tool at a wiki and get reliable source.
with added semantics, ou could make customizable travel guides in PDF format from Google maps, travel sites, combined together.

Common source for multiple wikis based on: audience, products, or platforms
This scenario provides a forum for comments on source (this is basically what Lisa Dyer is doing at Lombardi software).

When they engaged with the community while creating the content, there was a lot more activity – people wanted to “watch’ the superstars create content.

Portable content means repeatable collaboration.
Just one tool will not cut it – insist on standard-compliant tools. Blog about it, ask about it on wikis, log requirements on sourceforge – this isn’t just for vendors selling but also for the open source community. When you get something working, share your experiences with others.

IBM has a Custom Content Assembler in beta that you can try out. It uses Lotus product docs as source and you can build your own custom guides, and then choose to publish to PDF or HTML.

The conflict between structure and collaboration is solvable – use DITA as a common currency.

Advertisements

STC2008 – Engaging diverse audiences with screencasts, wikis, and blogs

Two Sun microsystems writers from southern Cal
Gail Chappell gail.chappell@sun.com
Cindy Church cindy.church@sun.com

“Change is inevitable – except from a vending machine.” Robert C. Gallagher (author)

Audience – college age developers, industry-savvy developers working in the workforce coding enterprise apps

Documented NetBeans Ruby – tool for creating Ruby language programs, part of Netbeans integrated dev environment. Free, open-source software, means that contributions from the community are welcome, both for the product and the documentation

Survey by polling readers of their blog and the mailing lists – both audiences had the same expectations of deliverables – printed docs to learn at their own pace, also wanted screencasts, their initial assumption that only college age would want screencasts, but found that everyone wanted overviews and to see what it’s all about.

Assume that company-written docs are accurate, only trust community-written docs when they’re from a well known name in the industry. They’ll only trust blogs from well-known sources.

A plan that changed everything – content delivery as previous, writing style went from formal to folksy, nontraditional role, they went from writer to community member.

Previously they weren’t providing any rich media formats such as video or screencasts. If they added these, though, something had to be removed, so they scaled back on the online help. Their developers indicated that they always searched for info on the web.

Disadvantage – steep learning curve for the videos especially.

Came up with a plan for 3 writers online help, tutorials, blog, adding screencasts and wiki.

Screencast – video capture of the computer screen that includes audio narration. They used 3-5 minutes to introduce program features, 10 minutes screencasts showing how to build an application. Asked a well-known developer to narrate for them, Tor Norbye. Wanted to help build his persona, used royalty-free background music and rolling credits. Link to the page containing the screencasts – http://www.netbeans.org/kb/60/screencasts.html.

Wiki – collection of web pages that users can add and edit by using a web browser. Their “rock star” Tor Norbye contributed to the wiki. Metrics weren’t high but they were coming to the wiki. Engineering originally set it up with updates. Wanted initially to put the tutorials on the wiki, but on this official website, netbeans.org, that’s where all the other tutorials were being placed. Use the wiki for drafts of doc instead of uploading tutorials. One way to use wiki was delivering info quickly, didn’t have to be perfect or templatized. Also used the wiki to post drafts, then emailed user forum to let them know they could review it. Once it was reviewed and vetted, transferred it over to the main website instead of the wiki. Feedback from customers on docs they’d like to see – wish list of docs, requested that the community help write those docs as well. They also searched the internet to find info in blogs, and pointed to those blog entries that were helpful.

Blog – Insider scoop from the tutorial divas, mix technical and non-technical topics, such as interviewing a student ambassador and posting vacation pictures to the blog. Include tidbits from tutorials. tips and tricks – top three ways to install on linux, tried to post at least twice a week.

Traditional docs – using company templates and guidelines. Short, focused tutorials, containing steps, screenshots, and code. Went to minimal online help. Addressed needs of global audiences and those with limited bandwidth, unlike screencasts. Kept online help to real basics, got rid of “duh” information that people could figure out on their own. Thought about posting online help files on the web, but ran into immediate problem, when they searched, they hit help topics, but users didn’t necessarily want that. Embedded feedback mechanism on all help topics, webform per topics, when it sends, it goes to every writer on the Ruby project.

Q from audience – you’re doing open source, but what about licensed software? One A from the audience, Extranet with support login IDs.

Still maintained formal style, but only for tradition docs.

“Let the authors be free to use their own individual writing style” from the developer survey

With the wiki and blog, it was much less formal, adhered to company branding requirements, but bypassed editorial review and used conversational writing style and own voice. They became trusted names as well.

Final big change – from writer to community member – new hats – writer, managing editor, first responder, community personality. When they had questions, they’d ask the community forum, which was staffed by both the Sun employees and the community members, they’d get answers quickly.

They’d search the web once or twice a week and post new news to the wiki, to keep the front page of the wiki dynamic and updated. Could provide a more varied doc set.

They enjoyed “first responder” best of all – getting the emails responded to within 24 hours of receiving it. If they had to ask an engineer, then the user got feedback right away that they’re working on it. Writer knew they were responsible for the areas for which they wrote the doc.

Looked at their doc formats and tried to figure out how to get an online identity – included their names on the tutorials, on screencasts closing credits, the blog, and the wiki. Also have their pictures and bios online.

Five major challenges –
convincingdetractors – many writers didn’t want to change the way they were presenting information
overcoming steep learning curve esp. for screencasts – Tor didn’t want screencasts done on camtasia, wanted them done on Mac. Also a tutorial doesn’t make a good script for a screencast. Also had to record at least twice.
Finding a venue – where to upload the screencasts, didn’t want to use Youtube, not a large enough frame size. NetBeans TV is where they ended up posting. August started posting, there’s a rating system on NetBeans TV, plus post related docs and screencasts. Wanted quicktime format movies. So used mediacast.sun.com, only Sun employees can post to it, but anyone can view the posts.
Watchdogging the wiki – all they do now are quashing inappropriate content. If a community member has posted a tutorial and it becomes outdated, what to do? Pull it, ask the community member to update it? Mark it as “not vetted/warranted,etc?”
Combatting shyness – we’re accustomed to writing in anonymity, but had to put up pictures and their name. Made a blog that was a group blog, could encourage others to write.

Three tactics for analyzing the success of deliverables

Omniture SiteCatalyst – looks at daily unique visitors
socialmeter – determine number of social sites that link to their pages. (Hey, cool, my blog’s social meter score is over 1,200.)
User comments and ratings – part of their help system and the wiki.

Milestone releases last summer, after five months, analyzed. What succeeded, where to improve.

Screencasts – most popular was 1000 views a day, 2nd most popular was 240 views a day. 160,000 downloads from mediacast, had to open extra ports to handle the downloads. Going forward, have dev record screencasts on their own, and writers will produce screencast. Tools – IShowYou, Snapz pro. Finalcut pro for editing (“like using a sledgehammer to pound in a thumbtack”). Keycastr to record the keyboard shortcuts that appear in the upper right-hand corner of the screencasts.

Most popular tutorial was actually the written version of popular screencast with 180 downloads a day. Installing and configuring ruby support averaged 130 visits per day. Socialmeter score of 314 by end of five month period – del.icio.us, furl, digg, google links, reddit, shere, spurl, Technorati links.

Advanced tutorials got far fewer hits
only one comment on online help pointed out missing/incorrect info
averaged one comment a day on tutorials, esp. getting started.
change and Ruby programming language changed their tutorials, user feedback made them aware. Fixed tutorial, blogged about it when they fixed it.
Blog results – more than 300 visits per day, top 10 blog entries are technical topics, most read were from previous project. Good for short topics, testing tutorials, building relationships with the community, and polling customers.

Wiki results – added new, edited existing. wiki daily unique visitors 65 on front page. 22 on Installation, 6 hits per day on documentation area, averaged only 11 hits per day on the whole wiki. Socialmeter score was 146, lower than screencasts. Low community participation. Need to make official web site and wiki work better together. While their wiki had only 3 community-produced docs, Netbeans.org just attained 150 community-contributed docs. Will do usability on the front page of the wiki. Want to set up a rewards system and have a free giveaway – tshirts for tutorials.

Projects on the horizon
Vodcasts – screencast on iPod with RSS feed to iTunes. Quality is degraded, though, so they would produce file specifically for vodcast.
Books – Still a lot of value in a book; quote from a developer “to master something as complex as a new language, I want to be comfortable on the couch with no computer in sight”
Next-gen screencasts – interactive, want to stick with Mac and native OSX. Thinking of screencasts in another native nonEnglish language. They also make sure there’s a written doc that matches the screencast to make it accessible. They also show keyboard shortcuts during the screencasts. Youtube is a good venue for just faces, interview with developers at a Sun conference in Sydney.
Videos
Wikipedia – want a page that describes the technology they’re working on.

Regardless of age or experience, a developer thinks like a developer.
Screencasts, wikis, blogs and traditional written documents meet the needs of developers across generations, from college-aged developers to industry-savvy developers.
A developer can never have too much information.

… and curiosity keeps leading us down new paths.” – Walt Disney

Can online help show “read wear?”

I’ve been re-reading Jakob Nielson’s Participation Inequality essay on useit.com, and the suggestion to some how show wear marks on content struck me this evening for some reason. I guess it’s because I’ve been working on Drupal recently, and discovered that Drupal documentation contains site recipies in the Drupal Handbook. What a nifty idea. Stick with me, these two concepts are related through a recipe and cookbook angle.

Part of Jakob’s treatise on inequal participation in online communities is that you can do little to overcome the typical contribution stats of 90-9-1, although one of the suggestions is to make participation so easy that you don’t even know you’re contributing. Case in point – Amazon’s “people who bought this book, bought these other books” recommendations. Sounds like the easiest contribution ever – data mining and analyzing, then giving the data back to the shopper in an understandable format.

Jakob says, “Will Hill coined the term read wear for this type of effect: the simple activity of reading (or using) something will “wear” it down and thus leave its marks — just like a cookbook will automatically fall open to the recipe you prepare the most.”

What are some similar examples of displaying read wear from the online help or user assistance world? The first example that comes to my mind is a wiki’s “most active pages” feature that shows the page with the most edits. However, the page with the most edits may be more controversial than truthful, so the most popular pages would be more useful than touting pages most active.

How else can you show read wear on a website? You could also show the most searched-for terms when the user searches. Concepts may be more easily connected when you understand what others were searching for.

Or, rather than showing search terms, show the most recently viewed knowledgebase articles or most popular articles. I know I’ve found that useful in the past when searching through BMC Software’s rich knowledge base.

Just like CNN and other news sites offer a listing of the most emailed stories per hour, you could show the most emailed online help topics if your system offers the ability to email topics.

The ability to rate an article is included in many online help systems, and exposing the ratings to the reader would help in determining how “well-worn” a help topic is.

Tag clouds can display read wear as well, as I just realized while looking at the WordPress FAQ starting page – tonight, the largest tag is “Images.”

I’ve distilled it down to popularity, time spent on the page, rating on a page, and number of edits from strongest to weakest indicators. What other factors matter in an online help system?

The state of free documentation

That’s free as in freedom, and today’s post includes a link to Adam Hyde’s blog entry of the same title on FLOSS Manuals and some response based on my experiences so far.

Floss Manuals

What motivates people to contribute to documentation projects for free? Is the documentation actually free as in no-cost? I’ll speak from my own experience and draw from recent research in this area. Plus, I just read Chris Anderson’s excellent essay on free as a business model and learned about the multiple economies and values and currencies available to us today such as the gift economy or labor exchange.

In my Wiki-fy your doc set presentation, I talk about the motivations for people contributing to any online or community documentation, and these four categories apply for any online community, be it a wiki or a mailing list:

  1. reciprocity
  2. reputation
  3. efficacy
  4. feeling like you belong or identify with a group or cause.

These four categories explain why people are motivated to contribute for no pay (for free) to a documentation project. This poster presentation for a “General Online Research” conference 2008, GOR 08, offers even more insight into contributions to Wikipedia as well as reasons people cite for not contributing content but reading only. Now, I agree with Stewart Mader that “your (enterprise) wiki is not Wikipedia” but there are lessons to be learned from Wikipedia as well. Take a look at what they found motivated contributors:

Rank Motive
3.71 Free access to knowledge for everyone
5.15 Task enjoyment / Fun
5.33 Learning
6.55 Belief in the future of Wikipedia
6.69 Existing information was inaccurate
7.25 Quality improvement of Wikipedia

At the unconference last week, Tom Johnson asked me, why did you get started with documenting the OLPC project? My initial motivation was that someone who I used to work for asked me, and he works for Joann Hackos. So reputation was one motivating factor, but as I read more and more about the education goals of the OLPC project on laptop.org, the more I saw it as an opportunity to identify with an education cause especially as related to my own kids computer educations and expanding their horizons beyond Windows. Why are any of us interested in documenting a complex product or process? It’s possible that at the heart of our motivation is recognition or reward in terms of money or success. But, an underlying motivator for many technical writers is that we like to help others learn, which ties into my education motives. We may also think that writing and communicating with images, audio, or video is a great way to make a living. What I am observing more lately is that community members want to write or share content as well.

Last year, O’Reilly ran a survey asking about the motivations that people have for contributing to online documentation, be it via a forum, a mailing list, or a web site. With 354 responses, I’m sure there’s a wide variety of answers, but certainly some patterns emerged. Andy Oram dissects them in a five plus page article. My favorite line on the first page is “And while fixes to particular errors are easy to convey, best practices are not.”

His report contains many findings that are unique, because no one else had been asking the questions. What he found that surprised me was:

  • People surveyed don’t think they are contributing to the documentation
  • People surveyed didn’t think of themselves as writers

Indeed, community building is the more important ranked reason for contributing to online documentation, rather than personal growth.

I have seen that rather than the monetary gains you can make by freelancing documentation, the currency of community is a payment schedule all on its own right.

The “free” offerings represent a shift in thinking. It’s not that no one paid for the doc to receive it. Nor did anyone get paid to write it. But the infrastructure in place enabled a sense of free-ness, freedom, and lack of cost. In reality, an elite group of people who have computers (starting at US$600 or so) and pay US$40 a month for Internet connections trade in t their time and knowledge in hopes of getting repaid in time and knowledge, recognition, a sense of belonging, or a payback in time by being more efficient.

This shift represents a new economy for documentation. Payment is in a different, “free,” no monetary cost form.

DocTrain West 2008 – Darren Barefoot – Social Media 101: Now Everyone’s a Technical Writer

Here are my notes from Darren Barefoot’s talk, a self-described recovering technical writer.

He leads with what defines social media? Create your own definition around these concepts:

  • Conversation – comments on large media sites allow ayone to speak to the media person keeping on the pedestal
  • Collaboration – 7 million people collaborating on wikipedia, likely the largest collaboration in human history
  • Sharing – some sort of microbroadcasting is built into every type of website
  • Scope – there are no longer 42-minute hours on televisions. Your buckets of stuff and time are sliced and diced. Ebooks can be 10 pages to 1000 pages.
  • Community – constructing affinity groups is easy, accessible
  • Transparency – blogging encourages transparency – medium is the message
  • Authenticity – example of knowing it’s fake is fakeSteveJobs.com, Lonelygirl15 is an example of outed fakery

42% of Chinese internet users have a blog

“The people formerly known as the audience”The people formerly known as your audience

Survey of 1200 bloggers – why do you create content, do social media? Talk to friends and family first, Keep personal history, Emote top three. But make money bottom response.

How to use a Wiki – video showing how to collaborate without using email (yay).

Updated to add: How to use Twitter – video showing how friends use twitter to keep up with each other between blog posts (these are awesome videos, I now love commoncraft)

An excellent, engaging talk, with the conclusion being, there’s no way to relinquish control, it is already too late.

Here are the takeaways he left us with:

  • Relinquish control – realize that the best documentation for your product is already not on your website.
  • Users will help each other – put screenshots in Flickr to make it easy for your users to grab them and use them in their own doc
  • Empower your most passionate users – for example, the Red Room Chronicles created by a Marriot business traveller. He must be the most passionate hotel user known. Offer those users previews, invite them to focus groups, make them feel special.
  • Think outside the page – Twitter troubleshooting tips, and of course, remember video and photos.
  • Go where your users are – find their community spaces, be present as needed.
  • Relinquish control – again. 🙂

DocTrain West 2008 – Bob Glushko, Document Engineering

Bob Glushko blogs at docordie.blogspot.com, great blog name and a fascinating presentation. I liked that he shared and described his semi-retirement as verbalizing his desire to be a beach bum to his wife, but his wife said, I still like my job and I want to work, so go get a job! He has been teaching at UC Berkley ever since. 🙂

Building information supply chains – example of the E. Coli scare in lettuce in March 2007. Basically had to figure out how to track heads of lettuce, similar to tracking heads of people to avoid long lines at security in the airport. With enough data tracking – input and retrievability – you can make informed decisions.

Common themes of new information services – document exchange, patterns, similar to supply chains and distribution channels. There are hidden documents in business processes.

His “ah-ha” moment? he had always focused on the document, but with ordering on the web, his user experience is what really matters – did the business process work? Did the lobsters arrive dead or alive? Did his shipment get to him in time and was it the right order? You have to know the back-end, the time difference, the travel distance, the choreography and design of the pattern determines success and a happy user experience.

I’m reminded of the fact that there are 39 time zones in the world, and for collaboration across the world, we have to figure out the time zone difference relative to the person you want to collaborate with.

Bob offers an excellent analogy for wiki-based, community-collaborative content – a restaurant’s lines of visibility. At McDonalds, you have backstage production lines for food prep, at Benihana you have food prep as part of the entertainment right at your table (remeber that onion volcano so expertly prepared?) We should try to strategically determine where to draw our lines of visibility – what point of view do we wish to present to our users?

Ah, now he’s talking about a cooking school where the kitchen is the front stage for the cooks, and the back stage for the customers. A restaurant’s dining room is the front stage for the customers, but the back stage for the cooks. I’m reminded of a webpage I read where people proved that writing on a wiki actually helps you learn more about the tasks because you have to figure out your conceptual understanding of the task to write about it. If you allow more writing to happen next to the backstage when it’s the cooks in the kitchen, or the expert writers in the wiki, more beginners can learn by not observing or reading but by actually participating in the writing itself.

While you may have identified more with either the front end or back end design issues, you can choreograph the information experience for the user.
Here are Bob’s slides, also found on slideshare.net.

Collaboration with asynchronous communication – getting to know “you”

While gearing up for different conference trips and presentations, I’ve been trying to get to know collaborators using asynchronous communications, such as listening to Char James-Tanny’s podcast on techwritervoices.com. She presented “Virtual Ways of Communicating” at a Florida STC meeting and Tom Johnson recorded it and posted it later.

I really enjoyed not only listening to Char speak but also hear the audience questions and interactions. For example, when she showed tag clouds, one audience member asked, does the size and format of the tag words change when a tag is used more often than another? And I thought, wow, I’ve always assumed that is exactly how it works, but haven’t actually asked the question, such as refresh rate or what relative sizing means. It points out to me that I take a lot for granted in the Web 2.0 world due to observing so much of it so often. But, a new fresh perspective offers me the conceptual details that people would seek when first exposed to something like a tag cloud.

As part of listening to this podcast, I found many suggestions for cool videos, popular wikis, and new uses of RSS such as RSS that I hadn’t heard yet. I realize that no matter how hard I try to keep up, there are new applications of technology coming in every day. I thought I’d collect these together though as a nice collection of “have you seen this?” which may not make much sense unless you listen to the podcast, but these were enjoyable to hear about and explore on my own.