Welcome to the 2008 version of Blogs, Wikis, and Collaborative Learning. I’m Karl Richter, your host during our weeks together this summer.

I’ll be blogging throughout our time together, and you’ll each create your own blogs.

I have created a Basecamp project for “Puttin’ on a Show”.

To access the project, click on this link.

Username = edtec700

Password = edtec700

This login has been given permission to leave messages only.

You will notice when you enter the project, your default page is to View Messages. From here, you can see an overview of the project by clicking the “Overview” tab. Or, you can go directly to the To-do list, Milestone, or Writeboard tabs.

If you would like, you can leave a message. Or, reply to a message.

This site is purely a mock-up site. It is not currently being used.

Enjoy!

Background 

The financial institution, which I work for, is in the process of implementing a new LMS.  The go-live date for the learners is 1Q08.  The implementation will be the result of three companies collaborating to replace an existing system which serves 250,000 employees.  It is an interesting project due to the synergy resulting from the client, HR service-provider, and LMS vendor.

The Audience

The audience is the Enterprise Learning Operations Support team.  This team is responsible for supporting the LMS and serving as relationship managers for the varied bank line’s of business.  The team has both domestic and international clients.  Another important characteristic of this team is they are a virtual team residing in Virginia, North Carolina, Washington, Colorado and South Carolina.  They rely on email, conference calls, webinars and instant messaging to stay connected.  The larger department, Enterprise Learning, hosts an annual face-to-face meeting.

The team has an overall “beginner” skill level using online tools.  There are several tools currently in place, but the team is on the receiving end of the tools, meaning they pull the necessary documents, rather than manage the site.  Existing tools include Sharepoint, Outlook, Live Meeting, Team Workspace, and Communicator.  A great deal of time is wasted searching for the correct or current documentation.

 The team has two roles.  The first is referred to a business as usual (BAU).  This pertains to the day to day operations of the existing LMS.  BAU includes the following:

• Training new users on the system
• Oversite of LMS data integrity
• Issue resolution involving user error, system issues, system functionality, and data errors
• Troublshooting
• Communication

The second role is to serve as the subject matter experts (SME)  for the new LMS.  This requires the ELOS team to be involved in all aspects of the new LMS implementation.  This includes:

• Meetings
• Document review
• Data mapping
• Functional specifications
• System roles and access verification

Essentially, this results in MEETINGS, MEETINGS, MEETINGS!  It would be safe to say the team is getting frustrated. 

This team needs

• Efficiency
• Simplicity
• Accuracy
• Information
• A good laugh  (here is one of our favorite sites http://www.despair.com/)

What the team really needs is a club house.  A place they can come together, share what has happened during the day, provide updates, compare notes, track deliverables and access current documents.

The Message

The tool for the ELOS team will have two purposes.  The first will be the ability to access project documentation. There are well over 100+ documents supporting the project, spread over 3 different tools.  The team needs to be able to quickly locate a current and accurate document as they serve as the SME’s.  The second purpose will allow the team members to track their project deliverables.  Please remember the ELOS team is juggling both BAU and the new LMS. 

The contribution of the users will be

• To post current project documents or provide links to the most current version
• Update deliverables
• Share insights and ideas

The Tool

Thanks to some good advice from a certain instructor, a tool has been located.  The tool which will bring some sanity to the ELOS team is Basecamp (www.basecamphq.com).  The Basecamp site offers  

• Customized colors and logos
• Dashboard
• To-do lists
• File sharing – key to our project
• Message board
• Milestones
• Time tracking  – no one really enjoys this!
• Project Overview – VERY NICE
• Comments on messages – easier than email strings

This appears to be a tool which can bring together the ELOS BAU and LMS work together on one page.  The site will have three objectives:

1. Increase the team’s efficiency with ease of access to documentation and tasks.
2. Decrease the team’s stress by streamlining the information overload and simplifying communication.
3. Develop the team’s technology skill set.

Subtitle: how a class project turned into something meaningful for myself and other college and university faculty

Introduction:

Same song, different verse – how to get faculty engaged in instructional technology in a seriously meaningful way???? There is an old saw that floats around the halls of higher education like old lecture notes. “Leading faculty is like herding cats”. And leading them to accept and even embrace instructional technology is often much harder.

The Plot Thickens

As I set in a conference presentation in New Orleans that addressed the problem of faculty participation in development efforts pondering the herd and the tremendous number of developmental efforts that I have seen fail it awned on me that, in effect, the audience at the Merlot (Multimedia Educational Resource for Learning and Online Teaching) conference might be unusual in that it certainly consisted of faculty but it was different because those in attendance were predominantly faculty but they were, for the most part, volunteer participants. In addition, they were already using technology to a significant level. The one are where there was a paucity of experience was Web 2.0 and social networking software. What I found more fascinating was that they were almost unanimous in their belief of the necessity of integrating that software into their (and other’s) instruction. I ended up recruiting 14 people to work together. There are 15 including me so that we cannot end in a tie in any vote. For those not familiar with the inner-workings of the academy, consensus building is critical and votes are frequent on everything. Since we were all in one place at the same time, we held an organizational meeting and hammered out some basic agreements. We further agreed to meet at the two semi-annual administrative meetings of Merlot. My original plan was to address a traditional faculty audience (the herd of cats). Having been involved in faculty development for over fifteen years I have seen countless programs begin with great fanfare only to see them fissile in short order. I could regurgitate the professional literature on why faculty choose not to participate and build yet another system that would most likely end up on the dump like so many other professional development programs or I could choose to build a program for faculty who already evidenced a strong desire to participate. A short answer as to why faculty do not participate is the culture of the academy. While it is beginning to change, the speed of that change in most institutions can be most accurately described as glacial. I felt that I was being presented with the opportunity to develop a truly meaningful program. I also had the opportunity to test such a program on volunteers or recruits from this audience.

Selection of Appropriate Tools

During our organizational meeting we agreed to the use of a blog initially to reach some basic decisions including what Wiki to use. Since several people were familiar with WordPress the decision was made to use it as our initial communication tool. It was also decided to use a Wiki once the initial work was done to prepare the way for our ongoing efforts. Why a Wiki? In a great online article, O’Reilly Network list the advantages and disadvantages of using wiki software. One of our next steps is to determine which Wiki to use. We will be using Wiki Matrix , the Blinklist Community, and other sites and resources as we compare tools.

Advantages to using a Wiki

Why might you want to use a wiki for your project? The wiki is:

• Good for writing down quick ideas or longer ones, giving you more time for formal writing and editing.
• Instantly collaborative without emailing documents, keeping the group in sync.
• Accessible from anywhere with a web connection (if you don’t mind writing in web-browser text forms).
• Your archive, because every page revision is kept.
• Exciting, immediate, and empowering–everyone has a say.

Disadvantages to Using a Wiki

OK, you get the picture: we like using wikis. But why might you not want to use one?

• Dirty laundry isn’t a good public face. If a wiki’s a shared memory, it’s not going to be terribly tidy, and you may not want people to see your half-formed, unsure, and speculative ideas (though actually, we advise against having your wiki be public).
• Its tendency to get messier. A wiki isn’t an administrative panacea, and there’s certain maintenance you need to perform, otherwise it’ll turn into unusable idea soup.
• Its terrible content management system. You’ll have to look after your own standards for formatting and when it comes to moving to whatever your final document format is, there’ll be more work.
• If you have a public wiki with open editing, you’ll need to patrol it to avoid users battling over content unproductively.
• It’s not so good for non-geeks, as you need to be reasonably tech-savvy and familiar with the concept of text markup.
• Some People Hate CamelCase.
• It’s not obvious how to set up or back up your wiki software.

Based primarily on our needs, reviews of current literature, and the experience of those in our initial group we decided that a wiki will be our primary tool. Additionally, we decided to use Google calendar and Google docs and spreadsheets rather than Microsoft tools, which is our normal default tool set, in keeping with the theme of social networking and Web 2.0 software. One additional consideration continues to be cost. Our plan is to use free software wherever possible.

Into the Future

As you can see, a funny thing did in fact happen on the way to completing this assignment. What is most interesting from my viewpoint is that this class was the primary contributing factor to what happened. As an aside, the administrative leadership group for the business discipline heard about what we are doing and asked if I would talk to them (which I did) since I am a member of that group about the possibility of using a Wiki for communication purposes in the business and perhaps across all of Merlot in the future. It is now on the agenda for review.

Jim Formosa

After doing the initial audience analysis for my proposed project, I conducted a needs analysis and looked closely at what the audience needs before deciding on a tool straightaway. I am part of the audience that is looking for a solution.

 Needs Analysis
Some important highlights from the needs analysis I conducted are given below: 

• Need to share knowledge and information within the team

• Share and learn from best practices

• Find information on tips and tricks, templates, formats, etc. on design and development of training quickly

• Information included in the tool should lend itself to being reviewed, modified, and expanded over time

• Cannot replace email communication and regular team meetings  

Readiness of Audience
I conducted a poll to gauge the readiness of the audience in using a tool – as that would have repercussions on the selection of the tool. 

• Out of the 15 people in the audience, 13 of them have never used a blog, wiki, or podcast before.
• They are not even familiar with the definitions and uses of the tools mentioned above – which could be potential solutions.
• The audience was however, ready to experiment and learn – as long as the tool did not require them to spend long hours scripting or learning how to do it.

Selecting a Tool
After analyzing the audience and their needs, I have decided to go ahead with a wiki, primarily because of the following reasons:  

• The collaborative aspect of a wiki would offer the team the ability to make the wiki evolve into the requirements of the team. 
• Easy to use and does not require any prior authoring skills – which was the biggest concern of the audience.
• A wiki would offer an open environment for users to post content and create the foundation for a knowledge-based culture – that is very typical of the company the audience works for.
• A wiki is flexible and this feature is also in tune with the requirements of the audience.
• LPDs need not fear accidentally damaging articles when they add or improve information in the wiki, as they can always revert back to a previous version of an article.
• The “Recent Changes” feature of a wiki would make it easy for users to access the latest posts made by an LPD.
• All LPDs are responsible for the content that gets uploaded to the wiki. There would be no vandalism of content as users can access the wiki with their unique Single Sign On numbers. The wiki would be accessible only by members of the LPD team and would not have the usual concerns users have about free-flowing content on a wiki like the wikipedia.
• A wiki would work for the audience as they have traditionally worked together by building consensus – and a wiki allows users to do just that.

 

Source: Wikipedia Consensus Process Flowchart

Corporate Guidelines
However, there are a few corporate guidelines that would need to be followed while designing a wiki for the LPDs.  

• The company meatball would have to be clearly displayed.
• Corporate policies and guidelines would have to be clearly outlined in the wiki.
• Clear description of Copyright issues and guidelines.
• Communication to users on what cannot be included in the wiki. For example – new product features, pricing information, or documents that require revision control like service manuals.

Recommendations 
Apart from that, I recommend that the wiki includes the following items keeping in mind that majority of the audience is very new to working on wikis.

• A Help section to get users up to speed
• A glossary of common wiki terms and their definitions
• Some kind of a cheat sheet on formatting tips
• Known issues and solutions
• A support team to help all the LPDs be able to use the wiki quickly and efficiently
• Ability to quickly access other tools and intranets of the company that users frequently access

 Challenges
The biggest challenge right now is to identify a core team who would get the wiki up and running and act as subject matter experts for the rest of the team.
The other challenge would be to work with the IT department and ensure the wiki resides within the GE firewall and follows all the IT policies and guidelines.  

I have chosen Basecamp as my tool to manage the project of “Puttin’ on a Show” and to collaborate with cast members, volunteers and other interested parties. My reasons for choosing Basecamp are as follows:

• Minimal learning curve
• Web-based – all you need is a web browser and an internet connection
• Minimal cost – starting at free and easily upgraded if necessary on a month to month basis at reasonable rates
• Incorporates project tracking capabilities
  • Milestones
  • Tasks
  • To-do lists
  • Calendar
• Encourages and facilitates collaboration
  • Message Board
  • Chat
  • File sharing

A simple blog or wiki would have allowed me to collaborate and share files with my users. But, it would not have given me the project management tools that are necessary and critical to this project’s success. I could have chosen to use a well know project management software package such as Microsoft Project, but it would really be overkill for this project.

I have read and listened to a number of user reviews and the only negative reviews have been that the software doesn’t have functionality that I do not require for this project. I also checked this out for my earlier class Web 2.0 review and found it to be very simple to use and to have all the pieces necessary to support this project.

The company that developed Basecamp is 37Signals. They are a small, privately held company founded in 1999. They claim to have 1,000,000 users on Basecamp.

Since this is a hosted site, software updates are maintained by 37Signals.

The user community (those involved in the show) are responsible for contributing content to the site. I foresee a core group of users creating milestones, tasks, to-do lists and communicating needs for such things as sets, props, costumes, box office needs, etc.

Individuals can be setup to have access to the project and to receive email notifications and/or RSS feeds. However, the number of people that I see subscribing to a project’s RSS feeds would be limited to a few core users. (Not everyone would be interested in being notified of changes to the project as a whole.)

Once individuals are setup as users their access rights can be specified. If it becomes necessary to further restrict access to individuals, multiple projects could be created and users assigned to only the project(s) that would directly relate to their responsibilities. In other words, permissions could be tailored in more detail if necessary.

A statement taken from the 37signals website sums up my reasoning for choosing this application. “We aim for the software sweet spot: Elegant, thoughtful products that do just what you need and nothing you don’t.”

Audience
15 Lead Program Developers (LPD) of the Education Services Team of a large coproration, located in different parts of the U.S. The role of the LPDs is to interact with service engineering, clinical applications, and marketing teams located in manufacturing centers around the world and then design and develop training materials for service and bio-med engineers and clinical applications personnel by working with vendors in the U.S. and other countries for audiences in all poles – Americas, Europe, Asia, and Australia for new products that are introduced in the organization.

Audience Analysis 
The age of the LPDs range from 33 to 64 years. Eight of them have Masters degrees and the rest at least have a Bachelors degree with some professional training in fields as varied as mechanical engineering to communication. Work experience in the field of training design and development varies from about 4 to 20 years. Around half of the LPD population in the Education Services team  has experience teaching the products that the Ultrasound modality manufactures and sells. So quite a few LPDs used to double up as developers/instructional designers and subject matter experts when required. At least, that used to be true till about two years back. Then the two roles of delivering and designing/developing were separated. Hence, some LPDs still have a steep learning curve as far as instructional design principles are concerned.  The motivation level of all the LPDs to learn new tools and better, more efficient ways of doing things is quite high. Promotions are directly tied to learning new skills and taking on more responsibilities.

 

Need to Share and Evolve
In this scenario, sharing of knowledge is an extremely important component as it not only brings the skill level of the entire team up collectively; but it also fulfills some key “values” in the organization – team spirit and open communication. Hence, there is a need within the team to have a space for sharing “best practices” and teaching and learning from the team simultaneously. The best practices can range from easy steps to editing an image in Photoshop to working more effectively with the manufacturing team in Norway. It could be a new template for “lessons learnt from a project” to tips on usability testing. The focus would not be on features of new products, sales updates, or application innovations.

The Message
The message shall focus on collaborative and informal learning and building skills and confidence among all the LPDs. Some kind of a repository system for tools and templates would be helpful for future reference. Information would change quickly and updates would be frequent, as the team has expressed a desire to share more often in different forums. The LPDs are located in different places and this also adds to the requirement of having a common “virtual” forum to do best practice sharing.

Let it Grow …. 
The success of this project would of course depend on the LPDs themselves. It would be up to them develop and grow this “virtual forum” into something that could potentially be shared with other training teams across the organization who would then be a secondary audience and have each member grow in confidence and skill by using and contributing to it. 

Tools
Many possible online tools can accomplish the goals for this project.  Some will be more effective in most targeted areas; while others will be less effective over all.  Possible solutions must address the needs of the group and the individual participant.  Since the program will focus on extending staff development of a Learning Management System (LMS), the selected tool should help the participants to use the LMS and to find ways to integrate the LMS into their classroom environment.  The tool should support participants in searching for and finding relevant information.

Requirements
Preferably, the tool should be able to support communication, data storage, collaboration, and exhibit flexibility.  To help participant buy-in of the LMS, this tool should open pathways of communication between the disperse participants (across the county of Orange – about 780 square miles).  Such communication should focus on pedagogy and application of instructional findings.  This tool should also promote data storage as in a data base structure.  Such data storage should focus on lesson plans, events, seeds, media, and findings.  This tool should encourage participants to collaborate with peer members.  Such collaboration should focus on the professional needs of the participants.  Finally, this tool should exhibit the ability to be flexible to the needs of the group as it develops.  Such flexibility should focus on ease of use and reformatting of the data storage.

Evaluation
Is there really only one perfect tool for this project?  No.  Possible options shall be selected from the synchronous/asynchronous tool within the OC Online/Angel LMS environment – behind the password protected gate.  The following tools were evaluated:

• Blogs:  Excellent for communication, but lacked data storage and flexibility – can be used for support
• Discussion Forums (Threaded Discussions):  Good for communication, but lacked structure of data and flexibility – can be used for support
• Email (CourseMail):  Excellent for one-to-one and blast communication, but lacked full solution for communication and data storage  – can be used for support
• Instant Messenger:  Good for real-time communications though other IM services support videoconferencing, but lacks effective data storage ability – not recommended
• Podcasts:  Excellent for broad communication and data storage, but does not support documents and other visual media – can be used for support
• Whiteboard: Good for real-time visual communications, but lacks effective data storage ability – like IM and not recommended – video would be superior
• Wikis: Excellent for offline communications, best data storage, strong collaboration tool, and is flexible. This project aims to help participants to use OC Online/Angel LMS and to professionally collaborate with other members. 

After the analysis, the wiki tool showed to be the strongest choice.  A more effective solution will use the other tools to support participant communication and collaboration.

Research
From a literature review on wikis within the K12 and higher education market, I found good evidence that this type of application has been recently studied, found to be instructionally effective, and has promoted learner interest.  Unfortunately, I was not able to find a study or an article that matches my project.  I would have liked to have found some barriers, constraints, guidelines, and results.  The literature seems to point positively toward releasing the control of the data storage to the participants, and to some point I intended on doing just that.  However, this will be an Orange County Department of Education (OCDE) website, and the management of the site will need to conform to established professional conventions.  The literature also focuses on the positive nature of collaboration with in knowledge construction in the wiki environment.  We build it – so that it mean more to us.

IT Concerns
OC Online/Angel LMS has been up and running at the OCDE for over a year now.  The application with supporting storage is now being housed on two servers at the county offices in Costa Mesa.  The county is highly motivated to make this program work.  They have invested time, effort, and available funding toward establishing OC Online through out the public and private elementary, middle, and high school.  Angel LMS is not open source.  Created in 2000, Angel is an enterprise level eLearning software system that was designed for higher education, but has been making inroads into the K12 and corporate markets.

TeacherWiki
Since OCDE is hosting the Angel LMS system, the county will manage user access, application updates, and related resources.  The EdTech department in OCDE will continue to be the direct managers of the program, and I will be working for them on training teachers on the application.  When teachers are given their login information, they are automatically enrolled into the OCDE Intro course, and in the course will be the wikki tool.  TeacherWiki will be the name of the tool.  With the help of other members of the EDTech department, we will facilitate the promotion, gardening, and seeding of the tool.  But most of the content will be constructed and maintained by the participating teachers. 

If some of this goes well, then teachers will learn to use an LMS to achieve effective instruction, they will join in and participate into the TeacherWiki, but above all they will reach out make connections with their peers.

Here is a wonderful video titled – Wikis in Plain English  

Choosing the Right Tool

“Nobody who ever bought a drill actually wanted a drill.
They wanted a hole.”

I am not sure where this quote originated but it has been in the forefront of my mind as I have been trying to decide what software tool to use for the “hole” I want to make.
When deciding what to use, I considered the following:

• Website
• Wiki
• Blog
• Edline

After a long debate and analysis (of my Audience and Message also), I chose to create a Class Blog through WordPress. WordPress is an open source project and does not require my users, including myself, to have any technical knowledge before posting. WordPress started in 2003 and has grown to be the largest self-hosted blogging tool in the world, so I don’t think they are going to implode in the near future. The reason for choosing a blog is that I need something that can be updated quickly and from work, allows students to contribute their knowledge and ideas, allows people from outside the class to be involved, is safe for students to use, and provides me with the flexibility to use media and hypertext.

In the past, I have tried to use a website as a reference tool and as a way to communicate to parents and students. The problems were that I was unable to update the website from work and it was too much of a hassle to update from home every night. I need something that can be updated quickly and something user friendly enough for the students to contribute to. Not only do I want to use a tool for reference purposes, I also want my students to be able to interact with it. I want to be able to initiate learning prompts on the internet and have my students reply back from the classroom, computer lab, or from outside of school. It is important to provide this information on the internet in order to communicate with a local and global audience.

My school district is assigning every teacher a site on Edline.com, which is basically a cookie cutter website that is easily updated and password protected. My problem with it, however, is that it isn’t attractive, it’s too restrictive, I cannot incorporate multimedia, and students cannot interact with it. I will still be required to use it and I plan to take advantage of its grade book function, but it will not be the primary destination for my students.

I considered a wiki and it is a tool that meets several of my needs, but it is missing the dialogue piece I desire where students can comment and respond. A blog is the one tool that meets all of my needs.

Updating
There is no IT person in my building and the technology coordinator doesn’t know what a blog or a wiki is anyway, so I will be doing all the updates and managing of the Class Blog. My responsibilities are time consuming enough, therefore I wanted to choose a tool that I could update and monitor easily. I am also hoping that it actually saves time by not having to collect papers, organize files, and keep for the next year. All data will be saved on the web, organized for me by categories and tags, and I will have it available to reference for the next school year.

Student contribution
There are many times when I come across a news article online or a thought provoking picture or quote and want to share it with my students in order to begin a dialogue. For example, this week there was a coal mine disaster in Utah where six miners are trapped and may take a week or longer to reach them (living in West Virginia means you can relate at least a little to coal mining disasters). Typically I would print the article out and discuss it in the class but have no way of recording or evaluating each student’s contribution to the discussion. A Class Blog allows me to easily post a prompt and it allows the students to post their comments online where I can easily evaluate their contributions. It also provides me an opportunity to respond to individual comments and challenge them further in their thinking. In class discussions, it is easy for quieter students to withdraw and be left out of the conversation, but the Class Blog levels the playing field and gives each student an equal voice in the conversation. Plus, the conversation does not have to end when I am finished. Students can continue the dialogue even after I have moved on and posted a new prompt for them to respond to.

Global Audience
The asynchronous nature of the conversation mixed with the knowledge that their parents, the principal, and the world may be reading their comments, should motivate them to provide thoughtful responses and take assignments seriously.

Safety
Whenever I use the internet with children, safety is always my biggest concern. I knew I needed to select a tool that will allow me to provide a safe environment for my students where they can remain anonymous and yet still be held accountable for their contributions. I wanted a tool that was password protected so I could control the content being displayed and I did not want a tool that would require my students (or whoever else) to be registered and logged in to post comments. WordPress allows my students to simply use their initials (or however I choose to identify them) and it has security features to easily let me screen potential inappropriate posts. WordPress also allows me to set my users as editor, author, or contributor (I won’t be giving them administrator privileges).

Flexibility
I know that looks are not everything, but when you are trying to motivate students you need to use something that looks pretty cool. If it even partially looks unhip, they will not buy in. WordPress allows me the flexibility to make it look cool and include features that are important to me: hypertext, pictures, and multimedia. I want to be able to use more than just text to prompt my students and I also want to share some of their other in-class work.

I have been thinking about this “hole” I need to make for over two years now and have failed in the past by using the wrong tools. Now, however, I think I have the right tool (WordPress) for the job and am excited to use it this year.

 

Advantages/Disadvantages:

I chose a wiki (Social Text) as the tool for my project because the initial audience of about 12-15 people are dispersed in various locations through our 11 state territory and getting everyone in the same place at the sametime is impractical. Even weekly conference calls are not able to include everyone.

Visibility: A wiki addresses these issues by allowing everyone to contribute information to everyone else asynchronously in a manner that is much more effective than email. By moving information out of email it becomes visible to the entire target audience immediately as opposed to relying on the email to be sent to the appropriate people. Often the sender may not even know who is the best recipient. Another benefit of moving from email to a wiki is all the good info becomes searchable.

Accessibility: Another benefit of a wiki is that once the wiki platform is installed and available adding users is very quick and easy and does not require any further involvement by our IT department. No long, drawn out process of submitting a request for access; routing it to who knows how many approvers and then a week or more later being told that you didn’t fill out the form correctly and can not have access. New users can be created in minutes as necessary. And unlike standard web pages, contributors don’t need any type of special authoring software. Any common web browser will allow them to participate. No special code or software needs to be created and no complex integrations with any other systems that require large chunks of lead time.

Flexibility/Adaptablity/Usability: Unlike potential solutions such as Microsoft Sharepoint wikis are very adaptable. Sharepoint’s rigid structure and lack of logical usability is a significantly limiting factor. We’ve seen numerous people who find it too difficult to use and simply give up and revert to email due to it’s lack of intuitiveness. Wikis on the other hand are quite intuitive and most users are off and running after a very short introduction.

Archive: Because every change is recorded wikis provide a good history of all project details which are not lost when someone deletes them. This is a BIG advantage.

Other specific benefits of the Social Text wiki include the ability to: track all recent activity at a glance, email content out of or into the wiki, attach files/documents to the wiki, email files into the wiki, incorporate tagging, and subscribe via RSS to track items or topics of interest.

Of course there are some drawbacks to consider. These include:

• a relative lack of “prettiness”. Formatting options are pretty limited. Especially to non-geeky users who do not know html, css, etc.
• a requirement for someone to serve in a “gardener” role to watch after the wiki and clean it up or give some guidance when necessary by providing some scaffolding on new pages for users to follow.

Alternatives:

Other software that could have been used may have included email, standard html/web page authoring tools, Microsoft Sharepoint, a central database application

I’ve personally polled the target audience and demonstrated the advantages of wikis which has received a very favorable feedback.

When it comes to persuading the IT guys they always seem to point to security first and foremost. Putting this wiki inside our firewall in addition to requiring usernames and passwords to contribute to the wiki has seemed to assuage all of their security concerns.

Solution:

I chose to go with a Social Text wiki since they have an open source option that I can install on a server that I already have access to and do not require any additional “official” IT resources or approval. This version uses the mature and stable application code used by Socialtext’s business customers. The system requirements are any reasonably modern server. 2gHz and and 4GB of RAM

The target group is responsible for generating all of the wiki content.

Our user permisison options will be that anyone inside our company can view the wiki but to contribute by making additions and edits you must have a username and password. This username must be verified to an internal email address via a confirmation email. There will be at most 2-3 people who will be admin type people who are able to create the user accounts and change wiki settings.

In the end, I thought that any disadvantages were far outweighed by the advantages, and that a wiki suits this situation perfectly. We have a need for including a group of distributed people in on frequently updated, quickly changing information to make an effective well-informed selection for our corporate LMS.

I look forward to reading the other solutions that everyone has come up with. I encourage you to leave a note with any questions and comments for me but I will apologize in advance for not quickly responding. I’m in a leadership event for my company that is 8 am to 10 pm everyday this week….and no that is NOT A TYPO!

“See” you in class!

Mike