A wiki is a page or collection of Web pages designed to enable anyone who accesses it to contribute or modify content, using a simplified markup language. Wikis are often used to create collaborative websites and to power community websites, usually as a very simple form of content management.
Let’s say that the most driven and driving developer on your team, who also happens to be a popular blogger, comes to you and asks why your end-user documentation doesn’t allow comments or ratings. Rather than stammering something about Wikipedia’s latest scandal, or reaching for imperfect responses that sound like lame excuses, do your homework and learn best practices from others who are implementing social web content that is conversational or based on community goals.
The era of desktop publishing is over, and I must bid Microsoft Word and several other desktop applications good-bye. In case you think I'm singling out Microsoft, it's not just MS Word, but also OpenOffice, GoogleOffice, or any application that makes what we used to call 'documents'. Nowadays, I'm simply using a wiki for collaborative information sharing and a blog for online reporting.
There are two camps in technical documentation. There’s the “quick web” folks who connect easily and author easily, and then there’s the “structured quality” camp that requires more thoughtful testing and time spent on task analysis and information architecture.
In early March we opened up the Atlassian documentation to the wider community. We added a CC-by (Creative Commons Attribution) license to our product documentation. We invited people to contribute to our documentation after signing an Atlassian Contributor License Agreement (ACLA). At that stage, the ACLA was just starting its three-month trial. The trial period has now ended, and we're delighted to say: it's a go!
The dynamic nature of wikis can cause a few headaches when you need to baseline documentation that's on a wiki to correspond with the release of your product. This blog post looks at some ways in which you can try baselining wiki content.
Blogs are about to give way to a new development. Wikis are web sites within which any user can quickly and easily edit much of the content, without HTML. This idea regarding user-generated online content goes beyond the comment posting of a standard blog. Blikis are blogs that have wiki support, so that users can edit the comments posted.
Depending on who you ask, HTML 5 is either the next important step toward creating a more semantic web or a disaster that's going to trap the web in yet another set of incomplete tags and markup soup. The problem with both sides of the argument is that very few sites are using HTML 5 in the wild, so the theoretical solutions to its perceived problems remain largely untested.
A wiki to collect information on this topic as there are a lot of presentations written about it but all differ in approach and content and collating all these great ideas can help us form a solid approach to selling web standards to the business.
Despite all the excitement in the technical communications community over Web 2.0 technologies like wikis and blogs, it looks like companies are still reluctant to tie the knot for a variety of reasons.
A lightweight markup language uses syntax that is similar to wiki syntax -- keyboard characters are used to define formatting. This blog post argues that if your documentation needs are simple, and you have a low or non-existent budget, then a lightweight markup language might be worth investigating.
The intention of this article is to open the readers eyes to the issues with trusting user edited content. Over time, the Wikipedia may balance out. Eventually, or possibly even now, user tests are being performed to see how much content is credible. Also, the academic communities could step up and decide unanimously that the Wikipedia is not a trusted body of information to use for research. Once this happens the Wikipedia will have to change the way information within their pages is handled to maintain existence.
The article alerts technical communicators to wiki technology, an emerging new medium that allows dispersed groups to create shared content via collaborative editing and different-time communication. Wiki-based collaborative content creation enables new communication practices and thereby challenges several assumptions of existing media choice theories.
In July, in a sharp break from tradition, the Army began encouraging its personnel — from the privates to the generals — to go online and collaboratively rewrite seven of the field manuals that give instructions on all aspects of Army life. The program uses the same software behind the online encyclopedia Wikipedia and could potentially lead to hundreds of Army guides being “wikified.” The goal, say the officers behind the effort, is to tap more experience and advice from battle-tested soldiers rather than relying on the specialists within the Army’s array of colleges and research centers who have traditionally written the manuals.
Catalyze is a member-driven community for all professionals involved in defining business systems, designing software applications and creating websites. If you are a business analyst, usability professional, UI designer, information architect, interaction designer, product manager, project manager or anyone else involved in the definition process of software applications, this community is for you and will be worth your time.
I’ve been collecting examples of wildly inconsistent writing lately. I’m not sure why these have stuck out to me, but when I think of book sprints and community writing events, consistency is an important, though sometimes difficult, goal and outcome.
Four service-learning projects were conducted in technical communication courses using wikis. Results confirm previous findings that wikis improve collaboration, help develop student expertise, and enact a “writing with the community” service-learning paradigm. However, wikis did not decenter the writing classroom as predicted by previous work. Instructors using wikis to scaffold client projects should calibrate standards for evaluation with students and client, and they may need to encourage clients to stay active on the wiki.
In this post, technical writer Milan Davidovic that contributing to wikis can help novices build skills and a portfolio. And he offers a simple roadmap for doing that effectively.
There are a wide variety of uses for Wikis and a level of interest in using them that’s matched by an extensive range of Wiki software. Wikis introduce to the Internet a collaborative model that not only allows, but explicitly encourages, broad and open participation. The idea that anyone can contribute reflects an assumption that both content quantity and quality will arise out of the ‘wisdom of the crowd.’
Like many companies, CorVu has extensive knowledge of its own products and a desire to make that knowledge available to customers. A major block to achieving that desire has been a lack of people with the time to either record the internal knowledge or to fashion the knowledge into a customer-ready format. We needed to spread the load so that a broad range of developers, tech writers, professional service consultants and others could all contribute what time and knowledge they had to a shared goal. Our hope was that a process built around several Wiki sites would facilitate this collaborative approach.
Offers a strong recommendation to read Anne Gentle’s Conversation and Community: The Social Web for Documentation, which provides tips for incorporating wikislices, screencasts, and comment/feedback systems, into your user assistance.
If you need the collaborative aspects of a Wiki combined with DITA's modular topics and publishing capabilities, then DAISY might just be the system you need--and it's free. DAISY provides WYSIWYG editing for Wiki pages that can be combined to publish books, either in a PDF or as a single HTML page.
What are your thoughts on whether wikis could be used for end-user technical documentation? I'd imagine that a more structured wiki based on DITA content (which may have already been created for end-users) might work well for technical documentation. Have you seen any good examples? I'd love to see a well-done example.
In this podcast, Stewart talks about the following: the advantages of using a wiki for your technical documentation; why lack of advanced styles in wikis isn’t a major problem; the relentless focus on simplicity with wikis; choosing the right wiki among dozens of wiki engines.
Recently I’ve been working on a simple calendar project that uses a wiki for documentation. Although I’ve heard a lot about using wikis for documentation, and have even used them in the past, I ran into a few surprises this time.