Out of Control – The DIGG Riot and Web 2.0
Web 2.0 has a few basic principles. Two – social networking and user-supplied content – are familiar; they’re often written about and have real-world analogs. But there’s a third – disintermediation, eliminating the mediator or middle-man – that carries some big risks along with its benefits.
Disintermediation is good because it eliminates information bottlenecks, especially if the information is coming from many sources, like the members of a user community. Web sites like Digg (digg.com), provide a rating service based on the collected and aggregated opinions of a community of users. The lack of a mediator, at least an overt one, is a plus. Consider Digg’s description of itself:
“… a place for people to discover and share content from anywhere on the web. From the biggest online destinations to the most obscure blog, Digg surfaces the best stuff as voted on by our users. You won’t find editors at Digg — we’re here to provide a place where people can collectively determine the value of content…
How do we do this? Everything on Digg — from news to videos to images to Podcasts — is submitted by our community (that would be you). Once something is submitted, other people see it and Digg what they like best. If your submission rocks and receives enough Diggs, it is promoted to the front page for the millions of our visitors to see.”
It sounds good but there’s one flaw, the assumption that a community’s motives are good. What if they’re not? The result may be that your content gets taken captive and you may be unable to do much about it. Consider the “Digg riot”.
Overview of the Riot
In February, someone leaked the decryption key for HD-DVD and Blu-ray disks onto the internet. The key uses technology created by a consortium made up of Microsoft, IBM, Intel, and other heavy hitters.
Toward the end of April, the key was posted on Digg. The consortium filed a cease-and-desist order, and Digg began deleting posts containing the key and suspending posters. In response, users began flooding Digg with multiple messages containing the key, daring Digg to stop them.
Digg tried. At 1 PM on May 1, Digg CEO Jay Adelson wrote “…We’ve been notified by the owners of this intellectual property that they believe the posting of the encryption key infringes their… rights. In order to respect these rights and to comply with the law, we have removed postings of the key that have been brought to our attention… required by law to include policies against the infringement of intellectual property.”
The response was an avalanche of criticism. Posters to many forums (Google ‘digg riot’) called Adelson “fascist”, claimed that it’s impossible to copyright a key because it’s just a number, and so on. And Digg users continued to flood the site with copies of the key.
At 9 PM, Digg surrendered. Founder Kevin Rose said “We’ve always given site moderation… power to the community. Occasionally we step in to remove stories that violate our terms of use… So today was a difficult day for us. We had to decide whether to remove stories containing a single code based on a cease and desist declaration. We had to make a call, and in our desire to avoid a scenario where Digg would be interrupted or shut down, we decided to comply and remove the stories with the code.
But… you’ve made it clear. You’d rather see Digg go down fighting than bow down to a bigger company. We hear you, and effective immediately we won’t delete stories or comments containing the code and will deal with whatever the consequences might be... If we lose, then what the hell, at least we died trying.”
Dianne Lynch of Ithaca College summed up the situation in a May 7 ComputerWorld article. “If you’re going to turn the site over to the community, you can’t decide to change your mind without having serious implications. User-generated content means that users will make a collective decision about what is and isn’t appropriate.”
And Rod Carveth of Marywood University, said in the same article “Communities that develop on sites such as Digg… form their own social norms. And when they feel they are violated, they use their own sanctions, site administrators be damned.”
What It All Means
It’s risky to read too much into the story. There are big differences between Digg and the types of Web 2.0 applications that technical communicators are likely to create. But technical communication itself is evolving in ways that are hard to predict. The lesson here is to be aware of the risks of Web 2.0 before jumping blindly into the technology.
Saturday, July 21, 2007
Sunday, July 1, 2007
Whither WinHelp (and WinHelp 2000)?
In the mid-‘80s, online help authors had a choice of many tools – Views, Window Book, Black Magic, etc. Each tool had an authoring module, costing about $500, and a user module, costing about $50 per user. The latter kept the market small because it was expensive to provide online help for each member of a large user community at $50 a pop.
Microsoft’s release of Windows Help, or WinHelp as it become known, in the late ‘80s changed this. It killed the older authoring tools, pushed hypertext into the mass market, and laid the foundation for online help as it exists today. WinHelp was unofficially terminated in ’97 when Microsoft released HTML Help. It’s now, apparently, been officially terminated with the release of Vista which, officially, no longer supports WinHelp. But dead or not, WinHelp is still used by many firms that, for various reasons, have not yet moved to HTML or XML.
So What is WinHelp?
WinHelp files are written in a format called RTF (Rich Text Format). (HTML Help uses, not surprisingly, HTML.) The RTF files are processed – “compiled” – into the finished output that’s distributed to users.
In the first version of WinHelp, the output was one file with an .hlp extension that contained all the topics and some minimal navigation features. Later versions of WinHelp added a second file with a .cnt extension that added table of contents, index, and search tabs. Users viewed the whole thing with a help mini-browser made up of one file – winhelp.exe, later winhlp32.exe – that came with Windows.
WinHelp’s authoring module was effectively free since authors could type the text and codes in Windows Notepad and use a free compiler from Microsoft to create the output. The user module was free since the winhelp.exe or winhlp32.exe file was bundled with Windows. The older hypertext systems couldn’t compete and either went out of business or went into niche markets.
Although authors could hand-code in Notepad, this was boring and a rich source of typos. Early authors created macros to speed up the work, and it wasn’t long before commercialized versions appeared – Doc-To-Help in ’91, RoboHelp and others soon after. The help authoring tool, or HAT, market was born.
Most early HATs were really Word plug-ins. They used Word’s features to create the content and add codes in regular .doc files, then converted the files to .rtf for compilation. In theory, authors could use any word processor to do this but Word was the easiest. As a result, authors who used other word processors, like Ami Pro, Manuscript, or WordPerfect for hard-copy but needed to create online help as well often migrated to Word, which hurt the other word processors’ sales.
WinHelp’s Output Structure
When users opened an early WinHelp file, they saw one window containing the help’s “home page”. Here’s an example, a WinHelp file that I wrote in the mid-90s as an introduction to graphics for new online authors.
In the mid-‘80s, online help authors had a choice of many tools – Views, Window Book, Black Magic, etc. Each tool had an authoring module, costing about $500, and a user module, costing about $50 per user. The latter kept the market small because it was expensive to provide online help for each member of a large user community at $50 a pop.
Microsoft’s release of Windows Help, or WinHelp as it become known, in the late ‘80s changed this. It killed the older authoring tools, pushed hypertext into the mass market, and laid the foundation for online help as it exists today. WinHelp was unofficially terminated in ’97 when Microsoft released HTML Help. It’s now, apparently, been officially terminated with the release of Vista which, officially, no longer supports WinHelp. But dead or not, WinHelp is still used by many firms that, for various reasons, have not yet moved to HTML or XML.
So What is WinHelp?
WinHelp files are written in a format called RTF (Rich Text Format). (HTML Help uses, not surprisingly, HTML.) The RTF files are processed – “compiled” – into the finished output that’s distributed to users.
In the first version of WinHelp, the output was one file with an .hlp extension that contained all the topics and some minimal navigation features. Later versions of WinHelp added a second file with a .cnt extension that added table of contents, index, and search tabs. Users viewed the whole thing with a help mini-browser made up of one file – winhelp.exe, later winhlp32.exe – that came with Windows.
WinHelp’s authoring module was effectively free since authors could type the text and codes in Windows Notepad and use a free compiler from Microsoft to create the output. The user module was free since the winhelp.exe or winhlp32.exe file was bundled with Windows. The older hypertext systems couldn’t compete and either went out of business or went into niche markets.
Although authors could hand-code in Notepad, this was boring and a rich source of typos. Early authors created macros to speed up the work, and it wasn’t long before commercialized versions appeared – Doc-To-Help in ’91, RoboHelp and others soon after. The help authoring tool, or HAT, market was born.
Most early HATs were really Word plug-ins. They used Word’s features to create the content and add codes in regular .doc files, then converted the files to .rtf for compilation. In theory, authors could use any word processor to do this but Word was the easiest. As a result, authors who used other word processors, like Ami Pro, Manuscript, or WordPerfect for hard-copy but needed to create online help as well often migrated to Word, which hurt the other word processors’ sales.
WinHelp’s Output Structure
When users opened an early WinHelp file, they saw one window containing the help’s “home page”. Here’s an example, a WinHelp file that I wrote in the mid-90s as an introduction to graphics for new online authors.
Note that there’s no table of contents, index, or search tab. To see them, users clicked the appropriate button in the “button bar” below the menu. This opened a separate “navigation” window containing the table of contents, index, and search tabs. Separate navigation and content windows made sense early on, when no one knew the best way to design help, but soon proved inefficient because users had to actively reopen the navigation window in order to use it, a big drawback.
Another drawback was the fact that a typical WinHelp project might pack several hundred topics into one Word file. This caused two problems. First, a Word file containing the equivalent of several hundred pages of material might take twenty minutes to open. It was also difficult to manipulate individual topics.
Another drawback, though not obvious at the time, was WinHelp’s use of macros to control many of its features. Today’s security concerns didn’t exist in the early ‘90s but, for companies still using WinHelp today, the macros must be a concern.
Another drawback is the shrinking pool of authors who can create WinHelp. The tools that date from the early days of help, like Doc-To-Help and RoboHelp, were originally created for WinHelp and only moved to HTML later. So these tools still support WinHelp; RoboHelp for Word, for example, is the original RoboHelp of 1991, albeit much upgraded. But fewer and fewer authors know how these tools work or understand the details of WinHelp projects, like the +, $, and K and other symbols at the top of each topic. So companies that still use WinHelp are at risk of losing the ability to maintain their own help systems.
Finally, as technical communication continues moving into a web model, WinHelp can’t support the new features coming online. And it just looks old…
What About WinHelp 2000?
When Microsoft released HTML Help in ’97, it combined WinHelp’s separate content and navigation windows into one “tri-pane” window, as shown below.
Another drawback was the fact that a typical WinHelp project might pack several hundred topics into one Word file. This caused two problems. First, a Word file containing the equivalent of several hundred pages of material might take twenty minutes to open. It was also difficult to manipulate individual topics.
Another drawback, though not obvious at the time, was WinHelp’s use of macros to control many of its features. Today’s security concerns didn’t exist in the early ‘90s but, for companies still using WinHelp today, the macros must be a concern.
Another drawback is the shrinking pool of authors who can create WinHelp. The tools that date from the early days of help, like Doc-To-Help and RoboHelp, were originally created for WinHelp and only moved to HTML later. So these tools still support WinHelp; RoboHelp for Word, for example, is the original RoboHelp of 1991, albeit much upgraded. But fewer and fewer authors know how these tools work or understand the details of WinHelp projects, like the +, $, and K and other symbols at the top of each topic. So companies that still use WinHelp are at risk of losing the ability to maintain their own help systems.
Finally, as technical communication continues moving into a web model, WinHelp can’t support the new features coming online. And it just looks old…
What About WinHelp 2000?
When Microsoft released HTML Help in ’97, it combined WinHelp’s separate content and navigation windows into one “tri-pane” window, as shown below.
To ease the shift to HTML, eHelp created a RoboHelp output that bridged HTML Help and WinHelp. It kept the WinHelp code but modified the look of the output to sort of resemble HTML Help. The result was WinHelp 2000, below. (The example is from RoboHelp for Word.)
It looks sort of like HTML Help in that it shows the content and navigation panes together – the “tri-pane” model. This is controlled by enabling a WinHelp 2000 feature and distributing a WinHelp 2000 plug-in with the .hlp and .cnt files. But it’s still WinHelp, and thus has all the disadvantages of WinHelp.
I’ll sum up by saying that WinHelp has a long and distinguished history and that it created much of today’s online help authoring world. But its end is in sight and it’s getting to be time to move on.
I’ll sum up by saying that WinHelp has a long and distinguished history and that it created much of today’s online help authoring world. But its end is in sight and it’s getting to be time to move on.
Subscribe to:
Posts (Atom)