<?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"
	>
<channel>
	<title>Comments for RodeWorks</title>
	<atom:link href="http://rodeworks.com/comments/feed" rel="self" type="application/rss+xml" />
	<link>http://rodeworks.com</link>
	<description>goto and play();</description>
	<pubDate>Wed, 23 Jul 2008 17:55:28 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>Comment on Wiki Deployment Tips by Craig Tobias</title>
		<link>http://rodeworks.com/archives/469#comment-61254</link>
		<dc:creator>Craig Tobias</dc:creator>
		<pubDate>Thu, 12 Jun 2008 07:22:34 +0000</pubDate>
		<guid isPermaLink="false">http://rodeworks.com/archives/469#comment-61254</guid>
		<description>Wow, that is a great question.  One I have been getting people to think about for some time now.  Most people can't think past getting their wiki up and operational.

I have two points on this subject.  One of the reasons I built Cisco's external wiki on the mediawiki platform beside scalability, and adoption is because the mediawiki stores its data in a database and there are a lot of converter out on the web that convert from Mediawiki to some other platform.  I often tell my management that you won't know how well I've done my job until we get about three to five years down the road and we have a migration strategy.


On the Enterprise side I built a system that would capture every aspect of our Network Operations BU.  This information is then collected and shared with our partners so they have the same operational information as Cisco does.  On of the purposes of this wiki is to keep long-term operations data.  Just because something goes end-of-life doesn't mean everyone stops using it.  Cisco still needs to track operational data on these products.  

Given that many wiki systems will publish out to HTML this is a decent alternative if you don't have a direct conversion script to your next system.</description>
		<content:encoded><![CDATA[<p>Wow, that is a great question.  One I have been getting people to think about for some time now.  Most people can&#8217;t think past getting their wiki up and operational.</p>
<p>I have two points on this subject.  One of the reasons I built Cisco&#8217;s external wiki on the mediawiki platform beside scalability, and adoption is because the mediawiki stores its data in a database and there are a lot of converter out on the web that convert from Mediawiki to some other platform.  I often tell my management that you won&#8217;t know how well I&#8217;ve done my job until we get about three to five years down the road and we have a migration strategy.</p>
<p>On the Enterprise side I built a system that would capture every aspect of our Network Operations BU.  This information is then collected and shared with our partners so they have the same operational information as Cisco does.  On of the purposes of this wiki is to keep long-term operations data.  Just because something goes end-of-life doesn&#8217;t mean everyone stops using it.  Cisco still needs to track operational data on these products.  </p>
<p>Given that many wiki systems will publish out to HTML this is a decent alternative if you don&#8217;t have a direct conversion script to your next system.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on IT Training by RodeWorks &#187; IT Training Part 2</title>
		<link>http://rodeworks.com/archives/584#comment-58041</link>
		<dc:creator>RodeWorks &#187; IT Training Part 2</dc:creator>
		<pubDate>Fri, 23 May 2008 18:41:13 +0000</pubDate>
		<guid isPermaLink="false">http://rodeworks.com/archives/584#comment-58041</guid>
		<description>[...] part 1 of this post I started musing on what type of training is appropriate for &#8216;normal&#8217; [...]</description>
		<content:encoded><![CDATA[<p>[...] part 1 of this post I started musing on what type of training is appropriate for &#8216;normal&#8217; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Wiki Deployment Tips by Randall</title>
		<link>http://rodeworks.com/archives/469#comment-56729</link>
		<dc:creator>Randall</dc:creator>
		<pubDate>Sat, 17 May 2008 00:49:13 +0000</pubDate>
		<guid isPermaLink="false">http://rodeworks.com/archives/469#comment-56729</guid>
		<description>Craig,

Thank you for a very thoughtful comment.  I also get concerned with the longevity of the intellectual content built up in the wiki.  Web 2.0 technologies come and go, but the knowledge built up in a wiki can represent a substantial asset for an organization.  Especially with software-as-service type wikis I wonder whether the built up knowledge will still be there in 5 or 10 years.  At least with a solution hosted in-house you have the raw data, which can be converted to some new scheme.  So I guess I lean towards the enterprise wiki.</description>
		<content:encoded><![CDATA[<p>Craig,</p>
<p>Thank you for a very thoughtful comment.  I also get concerned with the longevity of the intellectual content built up in the wiki.  Web 2.0 technologies come and go, but the knowledge built up in a wiki can represent a substantial asset for an organization.  Especially with software-as-service type wikis I wonder whether the built up knowledge will still be there in 5 or 10 years.  At least with a solution hosted in-house you have the raw data, which can be converted to some new scheme.  So I guess I lean towards the enterprise wiki.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Wiki Deployment Tips by Craig Tobias</title>
		<link>http://rodeworks.com/archives/469#comment-56560</link>
		<dc:creator>Craig Tobias</dc:creator>
		<pubDate>Fri, 16 May 2008 06:15:01 +0000</pubDate>
		<guid isPermaLink="false">http://rodeworks.com/archives/469#comment-56560</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.


I have deployed several internal wikis at Cisco and have most recently been responsible for the deployment of Cisco’s external wiki.

http://supportwiki.cisco.com

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>I have deployed several internal wikis at Cisco and have most recently been responsible for the deployment of Cisco’s external wiki.</p>
<p><a href="http://supportwiki.cisco.com" rel="nofollow">http://supportwiki.cisco.com</a></p>
<p>Craig Tobias<br />
Senior Solutions Architect<br />
Cisco Systems</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Adobe CS3 Install problems by RodeWorks &#187; Adobe Installer issues</title>
		<link>http://rodeworks.com/archives/403#comment-50624</link>
		<dc:creator>RodeWorks &#187; Adobe Installer issues</dc:creator>
		<pubDate>Wed, 16 Apr 2008 16:43:27 +0000</pubDate>
		<guid isPermaLink="false">http://rodeworks.com/archives/403#comment-50624</guid>
		<description>[...] like nine months ago I first wrote of my struggles with the Adobe CS3 Installer. And that issue continues to be one of the most viewed posts in the entire blog, with the most [...]</description>
		<content:encoded><![CDATA[<p>[...] like nine months ago I first wrote of my struggles with the Adobe CS3 Installer. And that issue continues to be one of the most viewed posts in the entire blog, with the most [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Adobe CS3 Install problems by Wayne</title>
		<link>http://rodeworks.com/archives/403#comment-50542</link>
		<dc:creator>Wayne</dc:creator>
		<pubDate>Wed, 16 Apr 2008 07:08:39 +0000</pubDate>
		<guid isPermaLink="false">http://rodeworks.com/archives/403#comment-50542</guid>
		<description>Yes, an entire day wasted. I finally got my order of CS3 Master Collection from my retailer. Got it home, went to install, and NO setup.exe files anywhere on any of the disks. I call Adobe tech support, and three hours on the phone - being switched from one tech to the other and being hung up on during one of the transfers between departments, they finally say they are going to send me new disk. I need to phone back to ensure that they are going to send me ALL the disks and they confirm they will - 3 to 5 business days- which brings us to next week. Of course, during this nightmare, I uninstalled all my prior Adobe products and will be without tools for productivity for this length of time. I guess I can reinstall my previous version of CS and of course, reactivate the friggin software and then delete again and run their hell hole scripts again to rid of their crap to reinstall CS3 once the disks arrive.

I try to install with .msi and of course, all applications need setup.exe to install, exept Acrobat. That one tells me that my NEW serial number is invalid. I am fuming, call Adobe AGAIN and they tell me that the serial number is indeed invalid. WTF? They say they can issue me a new serial number, but I need to fax them a copy of my proof of purchase. Whatever. I plead with them to just let me email a scanned copy. They finally say okay after being on hold for another 20 minutes. I scan my receipt of purchase and emailed them this. It will take 24-48 hours for this new serial number to come my way as they have to confirm I legitamately purchased the software. 

Way to go Adobe.</description>
		<content:encoded><![CDATA[<p>Yes, an entire day wasted. I finally got my order of CS3 Master Collection from my retailer. Got it home, went to install, and NO setup.exe files anywhere on any of the disks. I call Adobe tech support, and three hours on the phone - being switched from one tech to the other and being hung up on during one of the transfers between departments, they finally say they are going to send me new disk. I need to phone back to ensure that they are going to send me ALL the disks and they confirm they will - 3 to 5 business days- which brings us to next week. Of course, during this nightmare, I uninstalled all my prior Adobe products and will be without tools for productivity for this length of time. I guess I can reinstall my previous version of CS and of course, reactivate the friggin software and then delete again and run their hell hole scripts again to rid of their crap to reinstall CS3 once the disks arrive.</p>
<p>I try to install with .msi and of course, all applications need setup.exe to install, exept Acrobat. That one tells me that my NEW serial number is invalid. I am fuming, call Adobe AGAIN and they tell me that the serial number is indeed invalid. WTF? They say they can issue me a new serial number, but I need to fax them a copy of my proof of purchase. Whatever. I plead with them to just let me email a scanned copy. They finally say okay after being on hold for another 20 minutes. I scan my receipt of purchase and emailed them this. It will take 24-48 hours for this new serial number to come my way as they have to confirm I legitamately purchased the software. </p>
<p>Way to go Adobe.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 2.162 seconds -->
