New Wiki Tool at Conn

We were getting tired of having to teach students MediaWiki's "wikitalk". Not because it's not a great language to replace HTML for beginners. However, we were looking for:
1. A visual editor. Some faculty did not want to learn the wiki tags, and most students did not want to allow the time to learn them.

In addition, we were also looking for:

2. A wiki with more powerful layout features. MediaWiki does not allow this "out of the can". Creative layouts are possible, but require a lot of experimentation with carriage returns.
3. More controls over fonts, font sizes and font colors, without getting into span tags and hexadecimal code.
4. A hosted solution, so we don't have to worry about server maintenance and security.

After considerable research, we narrowed the choices down to what I consider to be the "Big Three" that meet the above criteria: PBwiki, Wikispaces and Google Sites. We ended up choosing Sites. This can be used either within a single Google account, or as part of Google's Apps for Education

We chose the latter solution, as it allows integration with Google Docs, easily linking Sites wikis to "the cloud." The single account only allows a 100 MB limit on total capacity of a wiki's uploads, we anticipated this to be too limiting. The free Ed solution has an overall institution limit (10 GB I believe), with no limits on single wikis.

The other two wiki solutions, PBwiki and Wikispaces, are both excellent, and full of features, so it was a tough choice. I'll post more why we chose Sites for our own situation at a later time.

Student creation of media and web-based assets, as part of course assignments, is becoming more commonplace here, so I started a wiki of the landscape to serve as a guide: YouPub. This is obviously rough customized for our college's needs, and unfinished at this time. I think I got most of the headings right.

Don't get me wrong, MediaWiki is a fantastic tool. We will keep our server going and available to anyone that needs it. The 20 or so wikis on it will still be accessible and editable to its authors. MediaWiki served us well for two years, but was not the right fit for our current situation. One disadvantage of Sites is that single file uploads are limited to 10 MB. In these days of large video files, it is a challenge we will need to overcome. This will entail a combination of linking to hosted videos on other services and servers and more efficient compression of Sites videos.

Another challenge will be expandability. Once we reach our institutional file upload limit, how to expand? However, we needed to move on at the beginning of this semester, and decided Sites was the best solution to pilot.

How not to plan a successful wiki

One of our professors, Manuel Lizarralde, was recently in the DCC scanning hundreds of pages of books to PDF so he could "travel light" on his trip to Peru, for a semester-away with a group of students. I had not heard of this before, and thought it was a great opportunity for the students. On the Sunday before his Thursday departure I got the idea of providing him with a digital camera and an iPod with mic, for the use of the students to capture their experiences.


I offered the idea on Monday, and he gladly accepted it. Later that night I thought of starting a wiki for their experiences and use. I ran this by Manuel on Tuesday, with a quick demo, and he agreed to try it. Manuel was too busy to learn wikitalk though, and had emailed a student, Leia Crosby, to try and contact me for some basic instruction. I put the wiki together on Wednesday morning, and late afternoon Leia called me by cell phone, rushing between trip preparation tasks. We agreed to meet later that evening. Short on time, I spent about 35 minutes teaching her basic wikitalk. The next morning the students left the college about 7:30 am for the trip to Peru, and I came up with a logo for the wiki.

I was not sure what to expect, but I think it has turned out pretty nice so far. Here is the SATA (Study Away Teach Away) Peru wiki.

Many of the pictures are Manuel's, but some are the students'. Almost all the entries are from the students (Manuel signs his), with Leia teaching the others basic wikitalk. Due to slow network connections from Peru, Manuel emails the images to his stateside wife, Anne, who posts them to the wiki, and usually also inserts them in the students' writings. These are totally theirs, and not edited, but they seem a little too busy for page layouts, so Anne helps out here. Below are the students, in front of their current location in Cusco.


We are not quite sure where this is going, but it's an exciting project. Usually we plan things in great detail to ensure success, in this case there was no opportunity. The lack of planning actually seems a positive attribute this time, as no limitations were placed on the wiki's direction and purpose, which can evolve and grow with any changing needs over time. I do wish I had a full hour to teach Leia wikitalk though!

Wiki-related videos

I know my posts are too long. With today's short-attention-span sound bytes they are possibly as relevant as a Jane Austen novel. WHAT, a 140-character limit in a web app, who the heck would ever use it! Bound to fail.

I write for myself, but to satisfy those wanting, or should I say NEEDING, a short post here it is.

Found a nice site today of Wiki-related videos, maintained by WikiAngela, at right, the co-founder of Wikia, which "is supporting the creation and development of over 3000 wiki communities in more than 70 languages. Part of the free culture movement, Wikia content is released under a free content license and operates on the Open Source MediaWiki software."

There are all kinds of interesting links in the above URLs. We also use MediaWiki ourselves, and though we only have less than 10 wikis at this time, it's nice to know we are in such good company.

Wikimania, FLOSSE, and Cell Phones

As we start new wikis for the Fall semester in our installation of MediaWiki, I spent more time learning about the open-source software. First, I created a better support structure in case I was not around. I had many pages of printouts on how to start and customize a wiki and condensed them into a wiki page on how to start a new wiki in our own install.

I have to refine these a bit more, and have a team member use them to start a wiki. I always receive useful feedback when others follow my initial directions, which are then improved.

I still have to come up with a better way of automating daily backups. Right now, I'm using MySQL Administrator to copy the databases, but I'm not happy with the backup procedure of the apache documents folder. We also make a mirror of the entire drive each week with NetRestore, which can be restored to a spare computer in about 10 minutes.

One of our CS students is attempting to implement math equation support, but no success yet. This seems a difficult and less-than intuitive process, without clear instructions. If we do succeed, we'd like to document the steps to help anyone else. I had spent a fruitless day attempting to "make" textvc myself, and decided it was an ineffective use of my time to go any further. I had reached my level of incompetency, the student had the misfortune to stumble in my office to return a cable for a friend, and the rest is history...

I was wondering where the upcoming Wikimania was this year, and Google gave me the FLOSSE Posse link. The conference is in Taipei, a little farther for me than the one in Boston last year. I now wish I had attended it.

FLOSSE Posse is a group blog from members of Free and Open Source Software Association (VOPE), carrying out reportage of FLOSS and Open Content in Education, there is some good info on the site.

One nugget was a reference to Knowledge Building, an activity which wikis seem to support very well. To summarize Wikipedia's entry:

"Knowledge building refers to the process of creating new cognitive artifacts as a result of common goals, group discussions, and synthesis of ideas. These pursuits should advance the current understanding of individuals within a group, at a level beyond their initial level of knowledge, and should be directed towards advancing the understanding of what is known about that topic or idea.

The teacher becomes a guide rather than a director and allows students to take over a significant portion of the responsibility for their own learning including planning, execution and evaluation.

One of the hallmarks of knowledge building is a sense of we superseding the sense of I, a feeling that the group is operating collectively and not just as an assemblage of individuals."

Another eye-opening idea I found in FLOSSE Posse is that networked communication, and the Internet, may come to third world countries via cell phones, and not the computer . Over 97% of Tanzanians have access to a mobile phone, though only one in 10 houses has electricity. These cell phones are becoming agents of social change, and are narrowing the "digital divide" more so than computers. This bodes well for technology like the iPhone, which enables one to do more than possible with a standard phone, and is closer to a computer. The cost of these technologies have to dramatically drop to make them affordable in third-world countries (and even in industrialized nations!). Google is now spending hundreds of millions on it cell phone project, there seems to be a bright future in this area.


There is an on-line community and a wiki at Shareideas on the use of mobile communications for social and environmental benefits.

The last good link I will mention found at the FLOSSE Posse was to Open Educational Resources, educational materials and resources offered freely and openly for anyone to use and under some licenses re-mix, improve and redistribute.

We live in an exciting time when it comes to rapidly developing networking and collaborative technologies. It's even more rewarding to use these, and see them used, to improve the way people live, communicate, and learn.

TSI: Blogs and Wikis

In the past, we were able to get through both the wiki and blogging instructions in one hour for each, which is what we scheduled for this workshop. This assumes no experience with either technology on the part of faculty attendees, which has proven to be a common situation so far.

For blogging, we decided to use Blogger. We have not used blogging much at Connecticut College for direct course support, and have not finalized a "priority features" list. I think this is best developed through actual experience, which we will soon have. We have studied and evaluated major features of the more popular blogging tools, and have anticipated some potential requirements. But you can never be certain what features are needed, and important, until you get into real-life situations. We will be conducting a more thorough evalutation of major blogging solutions this summer.

In our opinion, Blogger was a good tool to start with. It is very reliable, and has low maintenance and instruction overhead. Blogger blogs can be archived to the desktop, as they are just web pages, and then uploaded to a local web server to indefinitely preserve someone's work. Jean-Claude Bradley has successfully used Blogger for a long time for course support. Thus, while there are other good blogging tools available, we felt comfortable starting with this one. Blogger is also constantly adding new features, they are now testing direct video uploads in Blogger in draft. You automatically get the advantages of these without having to upgrade local servers.

The past two times we taught Blogger, the first 10 minutes were wasted waiting for everyone to log in for their first time. So, for "homework" we asked participants to create a Google account the day before the blogging class, if they did not have one or a Gmail account. This was a big help in moving things along. The previous times we taught Blogger, an hour was enough to cover the basics of starting a blog, creating one Post, and uploading an image to the sidebar and to a post.

However, the one hour was accomplished without any "sidebars" and with a minimum of answering questions. This time around, we decided to allow for these, and one hour was not enough. There were many justifiable concerns in controlling reading, posting and commenting permissions. We still have to study all the available options for this in Blogger. An hour and a half is a more reasonable expectation of the time needed to cover Blogger, especially if uploading of images and basic Templates instruction is included. Our overall schedule allowed for some flexibility, and we were able to shuffle it to allow for this.

Shortly before the end of my Blogger instruction, the demo computer froze up, as I probably had too many web pages (both in IE and Firefox) and applications open. I'm usually very careful to either reboot or log in and out before teaching, but this time I forgot! Prof. Stephen Loomis came in for 10 minutes, and gave some good examples of how to use blogs while I recovered the computer. In the meantime our team was also in process of changing our teaching schedule WHILE I was teaching, as I was obviously running into the time allotted for wiki instruction.

So I felt a bit disorganized at the end, and was unable to provide a nice and neat conclusion. There was now an empty 25 minute period after my presentation and before lunch (not enough time for wiki instruction!), and Marisa gratefully (and gracefully) jumped in and gave a polished presentation on Wimba, which was to be given later. Things looked like a bit of a mess from backstage, probably only to me, and later the experience reminded me of a non-sexual IT version of Noises Off, which I had seen and laughed at years earlier. However, my team ad-libbed with talent and gusto, and I understand the faculty thought the morning went pretty well!

That night, I wrote up a "Blogging Wrap-up" in WIKI 2, our dedicated instruction wiki, which is customized to the instruction task at hand. Some of the faculty had asked where and how to find blogs, so we created a few links and hints. In my experience, it's best not to initially provide too much information when teaching technology, it's just overwhelming to average faculty. One or two, or just a few, good examples are all that are usually needed. We always stress to please contact us for more information and support. I spent a few minutes the next day going over the wrap-up, and felt much better after that!


We decided to use MediaWiki as our course support wiki software for the coming school year. Here again, there are other wiki packages, literally hundreds of them now! But we already have 5 or 6 wikis in MediaWiki, and believe it adequate for the anticipated tasks.

I think our main concerns are MediaWiki's ability to authenticate against our LDAP, which we have not yet implemented, its scalabiliy (how well will it support hundreds of wikis?), and ability to set granular permissions. That is, to have different read/write privileges for each page if necessary. Inter-wiki linking would be a useful feature to have. There also is no easy GUI admin functionality, as in a commercial package like Confluence. So, while using MediaWiki, we will be evaluating other wiki solutions in the coming year.

For wiki instruction, we created an account for each faculty member and teaching staff, and a link to their empty page, in WIKI2. This allowed everyone to go to a different page, with edit privileges, for the purpose of instruction. This consisted of stepping faculty through the wikitalk examples in "Wiki Help" in the sidebar, leaving out Commenting, Messaging, and Table of Contents. We had faculty upload an image that we pre-installed on their computer, and had them embed it in a wiki page.

The wiki instruction took about an hour and a half. We spent some time teaching faculty how to change the font color using tags. Not everyone got this, and in the future I think it's better to leave any html out of instruction. The purpose of the wiki is to make it easy for anyone, novice or experienced, to author and edit web pages, not to provide the ultimate control you get with html and css. We had kept wikitalk simple in the past, and will probably return to this approach.

Aside from that, the wiki instruction went pretty smooth. One of the faculty had asked for a Glossary of Web 2.0 and Social Software acronyms and definitions. We though this would be a good wiki excercise they could work on themselves. We started a Glossary page, but did not have the time to develop it as an instruction tool for faculty, and ended up starting to fill it out ourselves.

Several faculty asked for wikis for future courses, and we will be able to copy and paste any information already entered in WIKI2 to their new wiki. Our lesson learned was not to try to cover an overview of Web 2.0 and Social Software, Blogging instruction, and Wiki instruction, all in the same morning, if you also want to allow time for questions and discussions.

The second class wiki is first class!

Based on our experience with our first wiki, we feel our second was more successful. Some of the things we did differently:

1. Myself, Diane Creede, another instructional technologist, and Ashley Hanson, who provided research support for the class, attended the entire first class. This gave us a good overview of the course syllabus, goals, and expectations, in addition to understanding better how the wiki was integrated into the course. I demonstrated how the wiki and wikitalk worked for about 25 minutes, but also stressed that students were to see me for additional instruction before starting their wiki pages.

2. The faculty member assigned the wiki production 20% of the total grade. This provided incentive for the students to create a nice wiki. it was obvious to me that the students were motivated to do a good job.

3. There were about 20 students in the course. These were paired, and each pair was responsible for creating a wiki page or pages on their topic, which was selected from a list. Each pair of students came to see me for a private lesson to go over how to create and edit a wiki page, including the use of images. This was done BEFORE they did any significant work in their wiki pages. As projects' due dates were spaced at least a week apart, this made support easier, as I only had to meet with one pair of students every week. The individual lessons took about an hour.

Assuming all 20 students had to start and finish the wiki at the same time, a different approach might have been required. I feel this second lesson is indispensable, the first half-hour introduction the first day of class is not enough.

4. The wiki was private until almost complete, and only students, their faculty and our 3 staff could view it. Thus, students were not concerned about others seeing their unfinished and rough work. The class as a whole decided when to make the wiki public. I encouraged students to start writing right away in the wiki, and not copy-paste from Word documents.

5. I encouraged students to first create main sections, using the wikitalk == characters. The sections acted as an outline of top-level topics, that could then be filled in a non-linear manner, or by a different student. Each section has its own Edit button on the side, making the process easier.

6. I would look at the wiki every 10 days or so, and if I saw something that could obviously be made to look better, or could be coded better, I would email the students with suggestions on how to do it, without making the changes myself. The main problem encountered was in using images in MediaWiki: the formatting around the text for a second image can be skewed unless break code is inserted between text blocks. This was occasionally forgotten.

7. I told students it was OK to look at each other's code, copy/paste chunks of it in their own wiki page if they liked the formatting and did not know how to code it themselves, and then customize it to their own content and appearance. I see the wiki as a collaborative effort so I feel this is justified. The main goal of the wiki was not to learn how to code.

Credit for the wiki goes to Prof. Joseph Schroeder, who had the idea for using a wiki in his course, and to the students that did such a great job. I think that just a little extra effort on our own part paid off in big improvements.

Here is a link to the Neurobiology of Disease Wiki. Prof. Schroeder even created the professional-looking wiki logo shown above.

I learned about areas where MediaWiki software could use improvements for these types of projects:

1. Administration. It would be nice to have a GUI from which one could perform user administration (add/delete/password change), and granular page permissions (read/write/protect). The latter seems impossible unless one gets into the PHP config files.

2. Esthetic control. Students want more control over the wiki appearance. For font style and color, this now means getting into htlm code. It would be nice to have an easier way to do it. Students wanted more control over image placement, and background color, this is impossible with wikitalk.

I'm not sure how well MediaWiki would scale as "campus wide" wiki software without better administrative functionality, but it is certainly a good tool for a handful of individual projects. At this time I think we could administer about 30 individual wikis. Beyond that, one would need a full-time MediaWiki administrator.

We are looking forward to supporting our third class wiki, and I can't think of much we would do differently. One improvement will be to centralize our "Help" section. We now have 7 wikis, each with its own Help section! As we find better ways of organizing this information, it becomes impossible to update each one. In addition, when you click on Help in the sidebar, you navigate OUT of the page you need help in. It makes more sense to use the Help in our Instructional Technology Group Wiki, keeping it in the background as a separate web page for reference.

Our first class wiki

In early 2006 our team was asked if we wanted to support the college's first course support wiki. An innovative faculty member, David Kyuman Kim, wanted his students to be able to "create their own web site", and showed us what he wanted and was inspired by: Social Justice Movements, a site for a class by Prof. Robin D. G. Kelley at Columbia University. This was a pretty clean-looking site, running on a heavily customized install of MediaWiki.

I admitted to Professor Kim I did not yet have the know-how to get this fancy, and demonstrated our first team wiki. He was satisfied with the appearance. He did ask if we could include a few images, and make it look "like a normal web site" as much as possible. I stressed that students' ability to create and edit content collaboratively was the wiki's strength, and not a great ability to control visual appearance. We had one organizational meeting before the semester started, with Prof. Kim, Diane Creede (an Instructional Technologist), myself, and Ashley Hanson, who was going to provide the Reference Librarian support. The final result of this collaborative effort was the Theorizing Race and Ethnicity Wiki

Lessons I learned in supporting this wiki were:

1. I wish I had, from the beginning, a better understanding of the role of the wiki in the overall course. I only read the portion of the syllabus referencing the wiki itself, and did not study the rest. Our only meeting with Prof. Kim was for an hour before the start of the semester. We scheduled more meetings but something always came up to postpone them. I did contact Prof. Kim and the class by email occasionally, to remind them we were willing to help as much as needed, so they knew we were available. But I would have enjoyed more involvement in the process.

(Solutions: Go to the entire first class to hear about the overall course requirements and get a "feel" for the course. Ask to go to some classes when the wiki is discussed or used. Try harder to schedule meetings with faculty to ensure their needs and expectations are understood and met.)

2. We only had an hour of class time to present, in person, both the wiki instructions (30 min) and the reference librarian instructions (30 min). Students were strongly encouraged to contact us later for further assitance, and I put as much information as possible in the wiki on-line help. However, I only heard from one student once.

I think the students could have benefited from more instruction on how to format text in a wiki (wikitalk). A single 30-minute introductory class is not enough. The large number of students in the course, forty-two, could have made support challenging. However, as they never contacted us, it was not a factor.

(Solutions: Make a requirement, or a strong suggestion, that at least one student from each group or team meet with wiki support staff to go over how to use it, at the beginning of their actual use. Course time is usually tightly scheduled, so this must be done on the student's own time.)

3. It seemed there were long periods when no work was done on the wiki. Then, all of a sudden, it would greatly expand in size. This seemed to happen twice, at mid-term and at the end of the semester, probably when due dates came up.

(Solution: Create a greater number of deadlines or "milestones" when material has to be submitted in the wiki. This, however, is up to the faculty. This can also be addressed in the solution to Observation 5.)

4. At deadline times, text was usually copied-pasted from Microsoft Word. Formatting such as bold, italic, and paragraph spacing is lost when this is done, and you end up with long run-on sentences without any breaks. In many cases, these were not fixed by students. This made the wiki very difficult to read, with a disorganized appearance. I ended up fixing all the problems myself, at the end of the semester.

(Solutions: Encourage writing directly in the wiki instead of copy-pasting from Word. Implement better instruction on how to format text in a wiki. There should be a student 'visual editor' for each group, responsible for appearance, not content. This editor needs to contact staff for assistance with wiki formatting. Staff needs to contact the editors if they see things are not right.)

5. A student contacted me twice, concerned that "everyone" outside the class could see his unfinished work, while he was working on the wiki. In both cases I suggested he contact Prof. Kim directly to express his concerns. I also told the student that the chance of someone stubling into the wiki, one of millions of web sites, is pretty slim. It's possible this aspect of the wiki: always open to readers, though only editable by students, may have been responsible for the large amount of "copy-paste", from finished Word documents, at deadline times.

(Solution: Make the wiki private initially, with a password needed for reading in addition to editing. However, as the goal is to eventually "publish" the results, do this when students feel comfortable, or at the end of the course.)

6. The wiki never did look like a "normal web site", though it has more variety than many wikis. All fomatting to make text more "stylish" was created by staff. It seemed that there was just enough time for students to insert text in the wiki, with no time left to learn to make it more esthetically pleasing. There was a possible misunderstanding with Prof. Kim, he may have expected us to do that. No images have yet been included. In addition, we did not know what types of images to look for.

(Solution: determine whose responsibility it is to make the wiki attractive. If it is the students', then allow for adequate training, support, and time. If our job, ensure we ask for enough guidance regarding text style and image selection. Better communication between our staff and faculty is needed in this area. After the course is completed, ask faculty if anything can be done to enhance its appearance. Obviously, content should be left alone. Insure faculty understand that it is technically difficult to make a wiki appear like a "normal" web site.)

7. I thought that Prof. Kim was satisfied with the work we and the students did, but things were so rushed at the end of the semester that I did not ask for more detailed feedback on the overall process.

(Solution: Request a meeting with faculty at the end of the project to go over, in more detail, their likes and dislikes, and their own "lessons learned")

As the instructional technologist that was in charge of primary support, I hold myself responsible for any problems that could have been resolved by better involvement or judgement. I think and hope I have learned my lessons. All in all, though, I think it turned out to be a nice wiki.

In a future post I'll describe how we are handling our second wiki at Conn. Thanks to Ward Cunningham for inventing the wiki. He prototyped it on HyperCard, and then ported it to the web in 1995. Ward named it after the Hawaiian word for fast or quick, and was inspired by the Honolulu Airport shuttle bus that runs between the airport's terminals. The fact that the wiki was invented over 10 years ago shows how some collaborative, participatory technologies that are now sometimes considered "Web 2.0" have been around for a long time, since "Web 1.0"

That first wiki, WikiWikiWeb, is still running!
To the left is its logo.

Wikis at Conn, Beginnings

In the fall of 2005 I thought it was time to get familiar with wiki technology for the purpose of course support. After evaluating a dozen hosted and locally installed solutions, I decided to go with MediaWiki for our first wikis. The reasons for this were, in no specific ranking:

1. A local install gave us more customization possibilites and software control. For some nice MediaWiki customizations, look at Beagle and Mozilla Developer Central. I wanted the potential to get away from the stock wiki look.
2. The college already had a student-managed wiki on another server, Connwiki, running on MediaWiki.
3. There is a very large user base in Wikipedia, which runs on MediaWiki.
4. There is a large base of developers and tweakers, with lots of helpful support information on-line. Many other sites run on MediaWiki.
5. MediaWiki is open-source, free, and non-proprietary.
6. Although relatively complex compared to some of the other wikis, I thought I would be competent enough to administer it after installation, with enough sources of help online if I needed assistance. There are also tech support staff here familiar with the technologies involved: HTML, CSS, PHP and MySQL.
7. If the on-line help and local help was not enough to get me out of trouble, the underlying technologies were popular enough that it would not be hard to find and hire an expert to fix things.
8. I wanted some "under the hood" experience, for my own personal development.

I spent my Christmas vacation in December 2005 learning how to install and configure MediaWiki. I first reformatted my PowerBook hard drive into 2 partitions, put OSX and all my stuff on one, and installed OSX Server on the other. I could boot into either partition, and used the server side for wiki development. I imaged the server side with NetRestore after a basic system configuration, but before installing any software, so I could easily restore it to its pristine state if I messed up. I did end up having to restore and start fresh a few times, due not only to MediaWiki. I was also learning how to customize Apple's Weblog Server for a podcast server in the same partition. So, the restoration option came in real handy.

It took about 40 hours to teach myself how to install MediaWiki and customize it to the state I needed. I had little background in HTML, CSS, PHP, and MySQL, though I had some programming experience in Director's Lingo, which no-one seems to use much any more. I learned just enough of the technologies that MediaWiki runs on for the job at hand. I have to admit my experience was usually more of a "cookbook" approach than true understanding. Thankfully, there are enough "recipes" around, though spread out a bit.

My biggest concern, on top of having the wiki run reliably, was security. I did not want a hacker getting in and messing up our site. This concern proved to be justified, as looking at the web logs later I determined an average of two hacking intrusion attempts a day, for a considerable amount of time.

After a few successful installs on my PowerBook, I felt confident enough to install the production version on an older but reliable Mac G4 running OSX Server 10.4, and started our first wiki, for our Instructional Technology Team. The computer is automatically backed up every night, with a complete image of the hard drive created weekly. Our wikis are still running on this G4, but will be migrated to a new XServe this spring.