<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: 25 Tips for a Better Wiki Deployment + 1 Tip on How to NOT Use Presentations</title>
	<atom:link href="http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/</link>
	<description>Connecting the dots ...</description>
	<lastBuildDate>Fri, 19 Aug 2011 16:10:19 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Kelly Parker</title>
		<link>http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/#comment-19606</link>
		<dc:creator>Kelly Parker</dc:creator>
		<pubDate>Fri, 04 Dec 2009 05:48:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/#comment-19606</guid>
		<description>Looks like Craig left Cisco and now is the CTO of WiiKno http://www.wiikno.com</description>
		<content:encoded><![CDATA[<p>Looks like Craig left Cisco and now is the CTO of WiiKno <a href="http://www.wiikno.com" rel="nofollow">http://www.wiikno.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig Tobias</title>
		<link>http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/#comment-11696</link>
		<dc:creator>Craig Tobias</dc:creator>
		<pubDate>Fri, 16 May 2008 06:10:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/#comment-11696</guid>
		<description>Considerations in Deploying an Enterprise vs. an Internet Wiki

There is a difference between an enterprise or internally facing wiki (inside a firewall) and that of an Internet based or external wiki (outside a firewall).  While the platform can remain the same and the basic purpose of collaboration is the same, it is their application purpose and the types of data collected and maintained on these systems which is different.   Enterprise wikis contain team and project type information.  This information usually consists of information such as team member, colanders, project statuses, inventories, and processes.  Enterprise wiki contain large portions of information for a limited or closed set of people.  An Internet based wiki is a wiki which provides information about an organizations good or services to a much larger user base.  Internet wikis serve much more in an information sharing, education, and marketing capacity and less in a project management and process documentation capacity than that of an Internet wiki.

Because there are some differences in these two types of wikis, there are also a number of other items that must be considered when building an Internet wiki versus that of an enterprise wiki.  The main factors you will want to address in an Internet based wiki will be:

•	Ease of use
•	Speed (User Response)
•	Scalability
•	Security
•	Content Moderation
•	Skins (Look and Feel)
•	Navigation
•	Metadata

It is not that these items are not important in an enterprise wiki, they are extremely important but there are a number of items which take priority in an enterprise system such as:

•	Flexibility
•	Plug-ins/Extensions/Adaptors
•	Integration (mashups)
•	Email integration
•	RSS feeds
•	Content change notification
•	Training
•	Job function application
•	APIs

Again the reason for the differences here is because most people will use the Internet based wiki as a repository for viewing and collecting information on products, technologies/systems and services.  The user base will most likely have about a 1-2% user contribution rate, where as in an enterprise wiki it would not be unreasonable to have an 80-90% contribution rate meaning that 80-90% of the users have contributed at least once.  So with an Internet wiki the more users you have the higher qualify information you will have. This isn’t necessarily the case with an enterprise wiki where the quality of information will largely be a result of a concept understanding peer review, benefits of adoption, and mainly education.  

With an Internet based wiki you will want to focus on the skins to make sure they adhere to your organizations branding standards.  Internet wikis also have the potential for explosive growth as well as vandalism items which are much less of a concern in an enterprise wiki.  If an enterprise wiki has scalability or navigation issues you can tell the user base to hold-on changes are on their way.  On an Internet based wiki system your users simply don’t come back if they find the site aesthetically unappealing, unreliable, or no responsive enough.  Therefore with an Internet wiki system you will want your site to have a very professional and appealing look and feel so that no matter what is contributed it is well presented.  This will make visitors less hesitant to contribute to your company’s public collaboration space.  You will also want to have a process for moderating content.   Removing liable and unseemly content will be important in maintaining an environment that appeals to the greatest number of contributors and promotes participation.

Enterprise wikis are slightly different in that factors that contribute to the greatest adoptions and collaboration are benefit to a person’s role, education, and a clear contribution strategy.  What is meant by this is that people are often willing to contribute but they will say they don’t know where to put something.  Having clear information architecture, a method for easily navigating it and educating the users on the basics of the information architecture will greatly drive adoption.

An enterprise wiki will also need to be much more flexible because it will be used in a much wider capacity than that of an Internet based wiki.  For any one organization the wiki might be used to keep track of customers, part number, manufactures, suppliers, shipping, operations, training, and other function required by and organization.  So one will want to look at watch features a particular wiki has and in addition how that wiki can be expanded in capabilities this is usually done through plug-ins.  Different wikis call them different things such extensions, modules or adaptors.  Whatever they are call their purpose is to expand the capabilities of the wiki.

Since on an Internet wiki some of the main concerns are speed, reliability, and security you will not want to just start adding plug-ins without carefully considering each and everyone.  Each plug-in generally expands the command options or feature set therefore that code much be processed before a page can be displayed.  The more plug-ins you add the more code that must be processed per-page therefore adding vast amounts of unnecessary will not only slow down the response to the user with each line of new code you must consider the security implications.

Craig Tobias
Senior Solutions Architect
Cisco Systems</description>
		<content:encoded><![CDATA[<p>Considerations in Deploying an Enterprise vs. an Internet Wiki</p>
<p>There is a difference between an enterprise or internally facing wiki (inside a firewall) and that of an Internet based or external wiki (outside a firewall).  While the platform can remain the same and the basic purpose of collaboration is the same, it is their application purpose and the types of data collected and maintained on these systems which is different.   Enterprise wikis contain team and project type information.  This information usually consists of information such as team member, colanders, project statuses, inventories, and processes.  Enterprise wiki contain large portions of information for a limited or closed set of people.  An Internet based wiki is a wiki which provides information about an organizations good or services to a much larger user base.  Internet wikis serve much more in an information sharing, education, and marketing capacity and less in a project management and process documentation capacity than that of an Internet wiki.</p>
<p>Because there are some differences in these two types of wikis, there are also a number of other items that must be considered when building an Internet wiki versus that of an enterprise wiki.  The main factors you will want to address in an Internet based wiki will be:</p>
<p>•	Ease of use<br />
•	Speed (User Response)<br />
•	Scalability<br />
•	Security<br />
•	Content Moderation<br />
•	Skins (Look and Feel)<br />
•	Navigation<br />
•	Metadata</p>
<p>It is not that these items are not important in an enterprise wiki, they are extremely important but there are a number of items which take priority in an enterprise system such as:</p>
<p>•	Flexibility<br />
•	Plug-ins/Extensions/Adaptors<br />
•	Integration (mashups)<br />
•	Email integration<br />
•	RSS feeds<br />
•	Content change notification<br />
•	Training<br />
•	Job function application<br />
•	APIs</p>
<p>Again the reason for the differences here is because most people will use the Internet based wiki as a repository for viewing and collecting information on products, technologies/systems and services.  The user base will most likely have about a 1-2% user contribution rate, where as in an enterprise wiki it would not be unreasonable to have an 80-90% contribution rate meaning that 80-90% of the users have contributed at least once.  So with an Internet wiki the more users you have the higher qualify information you will have. This isn’t necessarily the case with an enterprise wiki where the quality of information will largely be a result of a concept understanding peer review, benefits of adoption, and mainly education.  </p>
<p>With an Internet based wiki you will want to focus on the skins to make sure they adhere to your organizations branding standards.  Internet wikis also have the potential for explosive growth as well as vandalism items which are much less of a concern in an enterprise wiki.  If an enterprise wiki has scalability or navigation issues you can tell the user base to hold-on changes are on their way.  On an Internet based wiki system your users simply don’t come back if they find the site aesthetically unappealing, unreliable, or no responsive enough.  Therefore with an Internet wiki system you will want your site to have a very professional and appealing look and feel so that no matter what is contributed it is well presented.  This will make visitors less hesitant to contribute to your company’s public collaboration space.  You will also want to have a process for moderating content.   Removing liable and unseemly content will be important in maintaining an environment that appeals to the greatest number of contributors and promotes participation.</p>
<p>Enterprise wikis are slightly different in that factors that contribute to the greatest adoptions and collaboration are benefit to a person’s role, education, and a clear contribution strategy.  What is meant by this is that people are often willing to contribute but they will say they don’t know where to put something.  Having clear information architecture, a method for easily navigating it and educating the users on the basics of the information architecture will greatly drive adoption.</p>
<p>An enterprise wiki will also need to be much more flexible because it will be used in a much wider capacity than that of an Internet based wiki.  For any one organization the wiki might be used to keep track of customers, part number, manufactures, suppliers, shipping, operations, training, and other function required by and organization.  So one will want to look at watch features a particular wiki has and in addition how that wiki can be expanded in capabilities this is usually done through plug-ins.  Different wikis call them different things such extensions, modules or adaptors.  Whatever they are call their purpose is to expand the capabilities of the wiki.</p>
<p>Since on an Internet wiki some of the main concerns are speed, reliability, and security you will not want to just start adding plug-ins without carefully considering each and everyone.  Each plug-in generally expands the command options or feature set therefore that code much be processed before a page can be displayed.  The more plug-ins you add the more code that must be processed per-page therefore adding vast amounts of unnecessary will not only slow down the response to the user with each line of new code you must consider the security implications.</p>
<p>Craig Tobias<br />
Senior Solutions Architect<br />
Cisco Systems</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zoli Erdos</title>
		<link>http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/#comment-7802</link>
		<dc:creator>Zoli Erdos</dc:creator>
		<pubDate>Thu, 20 Dec 2007 22:55:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/#comment-7802</guid>
		<description>Sean, yes, you are right, I wanted to focus on the form, cause that&#039;s what p****d me off, to the point that I could not even read the whole thing through.  

To the bigger thought: I think one day we&#039;ll discover that there is very little difference between &quot;documents&quot; and wikis.  Online documents will evolve, with links in and out there won&#039;t be finite begin and end-points, just links, links, links.  Online editors already support collaboration, version conrol, etc.  That means documents are becoming like ... wikis! 

At the same time the better enterprise wikis can do all the &quot;freezing&quot; you&#039;re talking about, so within a wiki I may very well have work-in-progress as well as finished products.

Finally, I fully agree with you, using wikis for projects, businesses is entirely different from the Wikipedia case. In fact sometimes I think wikis would get adopted faster without the Wikipedia analogy.</description>
		<content:encoded><![CDATA[<p>Sean, yes, you are right, I wanted to focus on the form, cause that&#8217;s what p****d me off, to the point that I could not even read the whole thing through.  </p>
<p>To the bigger thought: I think one day we&#8217;ll discover that there is very little difference between &#8220;documents&#8221; and wikis.  Online documents will evolve, with links in and out there won&#8217;t be finite begin and end-points, just links, links, links.  Online editors already support collaboration, version conrol, etc.  That means documents are becoming like &#8230; wikis! </p>
<p>At the same time the better enterprise wikis can do all the &#8220;freezing&#8221; you&#8217;re talking about, so within a wiki I may very well have work-in-progress as well as finished products.</p>
<p>Finally, I fully agree with you, using wikis for projects, businesses is entirely different from the Wikipedia case. In fact sometimes I think wikis would get adopted faster without the Wikipedia analogy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean Murphy</title>
		<link>http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/#comment-7801</link>
		<dc:creator>Sean Murphy</dc:creator>
		<pubDate>Thu, 20 Dec 2007 22:44:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.zoliblog.com/2007/12/18/25-tips-for-a-better-wiki-deployment-1-tip-on-how-to-not-use-presentations/#comment-7801</guid>
		<description>I would characterize you as &quot;way too deeply&quot; interested in wikis. But you criticized the form and not the substance of the presentation, perhaps because, like me, you couldn&#039;t find any real substance. It seems to me in their several suggestions for rewards and merit badges the authors were confused about the fact that wikis dissolve voice and authorship. Many of these suggestions are more appropriate for encouraging an internal blogging ecosystem. Wiki&#039;s require team incentives and rewards to be effective, rewarding individuals is more appropriate for blog or forum posts where the authorship is clear. They also seem to miss the point completely that the place to start is with frequently updated information that is also frequently accessed. Meeting agendas and minutes (avoiding the bottleneck of the designated note taker and/or overlapping amendments in different e-mails that then have to be reconciled), early and still evolving specifications, and project status in a dynamic environment are much better places to start. At some point in the enterprise world many wikis must be congealed into a document or document set and either archived, frozen as a static HTML tree, or transferred to a content management system where more formal revision and change control methods are more appropriate. Projects end, products are shipped and end of life, problems get solved: unlike Internet wikis, older wikis in the Enterprise are often better preserved as read only archives. I think Wikipedia anchors a lot of expectations in a use case that is rarely appropriate to a team that is not building an encyclopedia.</description>
		<content:encoded><![CDATA[<p>I would characterize you as &#8220;way too deeply&#8221; interested in wikis. But you criticized the form and not the substance of the presentation, perhaps because, like me, you couldn&#8217;t find any real substance. It seems to me in their several suggestions for rewards and merit badges the authors were confused about the fact that wikis dissolve voice and authorship. Many of these suggestions are more appropriate for encouraging an internal blogging ecosystem. Wiki&#8217;s require team incentives and rewards to be effective, rewarding individuals is more appropriate for blog or forum posts where the authorship is clear. They also seem to miss the point completely that the place to start is with frequently updated information that is also frequently accessed. Meeting agendas and minutes (avoiding the bottleneck of the designated note taker and/or overlapping amendments in different e-mails that then have to be reconciled), early and still evolving specifications, and project status in a dynamic environment are much better places to start. At some point in the enterprise world many wikis must be congealed into a document or document set and either archived, frozen as a static HTML tree, or transferred to a content management system where more formal revision and change control methods are more appropriate. Projects end, products are shipped and end of life, problems get solved: unlike Internet wikis, older wikis in the Enterprise are often better preserved as read only archives. I think Wikipedia anchors a lot of expectations in a use case that is rarely appropriate to a team that is not building an encyclopedia.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using disk: basic
Database Caching 2/6 queries in 0.008 seconds using disk: basic
Object Caching 273/277 objects using disk: basic

Served from: www.zoliblog.com @ 2012-02-09 21:59:43 -->
