TSI: Internet2

Two tasks I was assigned during TSI were a 20-minute presentation on Internet2, which we have been connected to for almost two years, and organizing a videoconference with the Library of Congress (LOC). I had prepared for my I2 overview in a section in our wiki. Every major topic in this wiki realistically needs a frequent update, however, we often can't get to it unless necessary. Then it's an opportunity to entirely review and update the page topic, cut out obsolete information and links, add new information and links, and organize the page better. We keep an eye out for the specific use at hand, but also try to develop information adequate for a general overview. With technology changing and evolving every week, a wiki is a good tool for constantly updating and reorganizing information.

There are hundreds or thousands of links available on the web for every conceivable computer and information based technology, especially for Web 2.0 and Social Software. I have decided it's better in our wiki to just briefly explain the technology, and link to a few major examples, than to try and develop a comprehensive "encyclopedia of links" or detailed descriptions. Too much information usually results in eyes glazing over, at best, and total inattention at worst. Thus, when we target a general wiki page to an academinc audience, we judiciously try to find a few best representative examples of the relevant technology, and simplify explanations as much as possible.

We do crucially need those handy "encyclopedias of links" but other folks, like openculture, do such a comprehensive and timely job, it would be foolish to try to duplicate their efforts.

For some wiki topics, we are migrating towards a "two-tiered" approach for presenting information explaining different technologies. The distilled concepts and examples at the top, and any further details, links and examples at lower levels. This has not yet evolved into a visually distinct layout. The beginnings of this might be in our TSI Internet2 wiki page, linked to from above. I wrote up new basic fundamentals, uploaded some images, and then copied and pasted information from the older page sections, now shown below the three horizontal ruled lines. The entire page is a bit of a mess now, but the portion above the three lines is fine, and ready for a presentation. I do have to go back and clean up underneath this. It just shows how a wiki is often a constant, never-ending work in progress!

It took me 3 hours to revise our I2 page, and prepare it, and myself, for the 20 minute presentation that was scheduled. Unfortunately, the session on copyright, preceding mine, ran over by 20 minutes, there was no time for my I2 presentation, and it could not be rescheduled. Luckily, I had already shown and demonstrated our 47"-LCD I2 Cart during the faculty's earlier tour of the DCC. I had shown our contantly streaming I2 outbound MPEG2 VBrick video stream. The source is a multi-caddy DVD player. I had demonstrated incoming MEPG2 video stream reception over I2, and easily connected our H.323 Polycom videoconferencing unit to a videoconferencing classroom at Trinity College. So, at least some of the practical applications of I2 were demonstrated, though we did not have a chance to go over its history and a more comprehensive overall view.

But, I'll be ready for next time!

TSI: Podcasting

We had the challenge of having faculty record, compress and create an audio podcast in about 70 minutes. Most of them had no previous audio recording experience. One thing I have realized is that, when comes to instruction time required, you can only be as fast as your "slowest student", unless you decide to leave them behind. This we don't like to do, of course. I mean "slow" in relation to production speed, not intelligence, of course.

We decided to use the Plantronics DSP500 Headsets for microphones. These work well with both Macs and PCs, and are recognized by both platforms without having to install any drivers. We have three at the library circulation desk, where students can check them out for recording real-time voiceovers in their iMovie, Final Cut Express, and GarageBand projects, one in the DCC, and nine in Marisa's Foreign Language Lab, as they work well with Wimba.

Originally I was going to use QuickTime Player Pro (QTPP) for recording, as all the computers in our teaching labs have it. QTPP can also be used to trim the audio and compress it before uploading to a podcast. Then I thought we would use QTPP just to record, and import the file in iTunes for compression, as iTunes has a great free compression engine, and can compress to mp3 or mp4. It was an opportunity to teach faculty how to use it. At the last minute, however, I decided to use Audacity for recording, editing, and compressing. Keeping production in only one program meant a simpler, faster workflow. In addition, Audacity introduces the concept of audio as a visual waveforms, and allows for much more editing power than does QTPP.

More and more individuals want to create using their own computers lately, as opposed to going to a specialized lab. Audacity has the advantage that it is free, works almost the same on Windows and Macs, and is a fairly powerful, but easy to learn, entry-level audio editor. This makes instruction and support much easier. I had used Audacity only once, months earlier. It took me about 10 hours to learn enough about the program to teach its basics, install it on 12 computers, and write up some usage directions.

In addition to installing Audacity and the LAME library as an admin, some configuration has to be performed at the local user level. I have had previous experiences with long periods of time devoted just to configure software and hardware before any work is done. Thus, I decided to pre-configure everything required for each individual user account the day before instruction. I asked the faculty to leave themselves logged into their workstations while away at lunch. This gave me enough time to connect the Plantronics headset, have the computer recognize it for the first time, and set the Control Panel Audio Preferences to use it as both the recording and playback device. I also selected the Plantronics as the recording device in the Audacity preferences, and linked the program to the LAME library. This only has to be done once for each user account. I thought we might run out of time at the end, so I preselected a compression setting of 32 kbps in Audacity. I also opened iTunes and QTPP for the first time, as there is a little extra time and effort involved with the original initialization. Having all the computers pre-configured saved a lot of time the next day during the actual teaching, everything was plug and play, and just worked!

Of course, we had accidentally logged off one computer at lunchtime the day before, and I had forgotten to configure it. So, we did have to futz a bit with one after instruction started. A small glitch, but it would have been hell if we had to configure 10 of them!

I divided the Podcasting instruction into four distinct parts: 1. Quick Tech Overview, 2. Recording and Editing, 3. Compression and Export, and 4. Uploading to the Podcast Server. I find it useful to prepare my lesson plans in our wiki. This allows me to "build it as I go" and make fast changes from any computer. It enables other people to see it and comment on it before instruction. I also project it while teaching, to help keep me on track, and allow any stragglers and confused people an opportunity to catch up.

I had previously drawn the Podcasting Workflow on a large whiteboard at the head of the classroom, and quickly went through in in about 5 minutes.

All in all, the rest of the instruction went pretty smoothly. However, I again suffered a bit in my time management, and did not have time to explain how to amplify a weak waveform. This was not in the instructions, but, while teaching, I realized I should mention it. It was not a major omission, though, as we had already gone over how to record a "healthy" waveform.

At 11:55 am, with 5 minutes to go, everyone had an mp3 sitting in their computer. I had previoulsy prepared an empty podcast for every faculty member on our Podcast Server. I had already developed instructions on uploading for a student trip to Brazil. This final portion of the class went nice and smooth, and by 12:05 everyone was listening to their podcast in iTunes. Success!

Tech note: While we used Audacity to compress to mp3 for instruction, our usual workflow up to now has been to compress to mp4 with iTunes. This takes a bit longer and involves more steps. Audacity can only compress to mp3. We will reassess our compression recommendations, but mp3 and mp4 files can coexist fine in the same podcast. We will still continue to use other audio editing programs, such as Pro Tools LE, GarageBand, and Soundtrack Pro, when more powerful features are needed.

TSI: iPods

The iPod class was an optional afternoon class, and 4 faculty signed up. This was promoted as a beginner's class. Some faculty already had iPods, and justifiably did not attend. I wanted complete kits for all 4 participants, but only had two, so I borrowed from my team members and from our "new pool". To the left, below, is our complete "iPod Kit".


It includes: 30 GB iPod, iPod case, iPod-to-USB cable, earbuds, AC adapter, Belkin TuneTalk mic, Belkin mic-to-USB cable, written list of kit contents (to help ensure everything is returned), and printed instructions from our wiki, on Recording Voice Memos and Audio

I had prepared the one-hour program beforehand and outlined it in our team wiki. This was displayed on the classroom's LCD projector, alternating between it and iTunes, when appropriate. I had distributed a set of full headphones with each iPod Kit, I prefer them to earbuds for the purpose of instruction. Each faculty member had an iPod Kit, the headphones, and a computer with the latest copy of iTunes.

Unfortunately, my time management again suffered a bit. I had alloted an hour for instruction, and we had to leave the classroom for another use after the hour. I had placed an audio CD at each computer, and wanted to put the faculty through the process of importing a track in iTunes, and then moving it to their iPod. We ran out of time for this, so I just spoke about how it is done. We did have time to record a voice memo with the Belkin mic, and move it from the iPod to iTunes, which is probably more important.

I also did not have time to explain the differences between Mac and PC formatting, how to use the iPod hard drive as a storage device (though this is fairly self-explanatory), and explain a bit better what I consider to be the "heart" of iTunes, its compression engine controlled in the Preferences.

However, the faculty felt the class was very useful. None had any experience with iPods before, we covered most of the important features and procedures, and 95% of the program. The podcasting aspects were to be covered at a later class, attended by all faculty, so they were not addressed.

EQUIPMENT NOTES

We had previously tested three iPod mics: the Belkin, the MicroMemo, and the Griffin iTalk, and found the Belkin to provide the best quality. This was determined not only by listening tests, but also by comparing the recorded audio waveforms. The Belkin recorded at a slightly higher volume than the MicroMemo, this is important as often the speaker is further from the mic than the optimal 1-3 feet. The Griffin recorded at the same sensitivity as the Belkin, but had a higher internal noise level, see below (click to enlarge).


These tests were conducted when each model first came out. They probably need to be conducted again, as manufacturers often tweak their products over time. Any of the three models will provide adequate quality for plain voice recording if you are a few feet from the mic.

The Belkin has a useful additional feature: a built-in USB port and included USB cable. This can provide power to the mic and iPod, to extend the recording time beyone the usual 3 hours or so, and can be connected to either a computer or AC adapter. This cable can also be used to synchronize the iPod to a computer.

I found some nice plastic boxes at AC Moore, seen in the first image. You get two, a larger one and a smaller one, for $2.99. The larger one is just the right size for our iPod Kit, and the smaller one is a good size for our Samson AL1/AM1 Wireless Mic Kit. This is shown at the right in the above image. The wireless receiver connects to the Belkin Tune-Talk, which is connected to the iPod, and the mic/transmitter can be clipped to the speaker. Then, no matter where in the room the speaker is, a good signal is recorded to the iPod.

We usually set up the levels in the wireless transmiter/receiver beforehand for faculty, with a small included plastic screwdriver. We do need to write up and include some simple usage instructions in our kits.

Often faculty come in and ask for a portable speaker to use with their iPods, to play back audio selections to their class. We were very happy with the JBL On Stage, which has a nifty remote that controls the iPod as an optional accessory. However, the JBL needs to be plugged into an AC outlet, and we wanted a truly portable but inexpensive system. After much research, we settled on the $100 Altec Lansing inMotion, shown below. It is battery powered, and comes with all the different iPod adapters, but we usually just stick our iPods in it without one. The volume is only moderately loud, but is adequate for a class of 30 or 40 students. I don't think any of the small portable systems provide actual "hi-fi" quality, but they are fine for non-critical audio and music sharing.



There must be 70 different protective cases available for the iPod, we like the Marware and Body Glove products in the $20-30 range, but there are other good manufacturers. These models are changing all the time. For those on a tight budget, there are several $10 "soft sleeve" products available.

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.

TSI: Web 2.0 and Social Software

Following are a few more details on teaching new technologies during the Tempel Summer Institute, described in an earlier post. After developing our teaching schedule, we revamped our wiki dedicated to hands-on instruction, WIKI 2 in preparation for the course.

We decided to first give faculty a brief half-hour overview of the concepts of Web 2.0 and Social Software, with examples of major categories in each area. A section on the WIKI2 main page was prepared for this. A picture is worth a thousand words, and I love the illustrations in Dion Hinchcliffe's Blog, so we used the following:


The image provides a nice overall view of the major revolution of web content to user-created and user-managed information. Our presentation covered general categories and was not limited to educational areas, but we also did not want to overwhelm faculty with too may concepts and examples. On the first pedagogy instruction day, Diane had already demonstrated a couple of examples of wikis and blogs, so after going over the implications of the above illustration, Prof. Steve Loomis showed his Facebook page, a good example of Social Software, and how he uses it in his relationships to students.

We then quickly went through examples we had already listed in WIKI2: Another Social Software (Twitter), Video Sharing (YouTube), Image Sharing (Flickr), Mashups (Flickvision), and Presentation Sharing (Slideshare). One of Bryan Alexander's Presentations is a good example of the difficulty of separating the concepts of Web 2.0 and Social Software. The presentation itself, converted from PowerPoint and able to play full-screen, is based on Web 2.0 coding technologies. But the comments below, "Digg this", "Subscribe to user", Tags, and Embed Code are all at the Social Software end of the spectrum. Thus it is really impossible to separate the two concepts. This can be difficult to accept for people that need exact definitions.

Unfortunately, by the time we reached On-Line Office Suites we ran out of time, so we did not demonstrate these. We expected to cover Podcasting and RSS later in the week, but were unable to cover the "OPTIONAL" topics: Tagging/Social Bookmarking (del.icio.us), 3D Virtual Worlds (Second Life), User-Driven News (Digg), and Custom Home Pages (iGoogle).

Based on the above experience, I think a minimum of 60 minutes is needed for a brief but fairly complete overview of major Web 2.0 and Social Software categories. To individuals that have not been exposed to all of these, it could be an overwhelming, but also mind-expanding, experience.

Geotagging was added in the wiki later, when someone wanted to know if Flickrvision indicated where the pictures are taken. It only indicates where they are uploaded from, whereas geotagging indicates the images' actual locations. Unfortunately, I never had a chance to explain geotagging, due to the massive amount of information we were dealing with, and time constraints.

After the above presentation, we jumped right into blogging, which will be covered in a future post.

Tempel Summer Institute 2007

We recently completed our eighth annual TSI workshop for 10 faculty, conducted over a period of 7 full days. The title of the hands-on workshop was "New Ideas for Designing a Course that Incorporates Technology to Enhance Student Learning". Five members of our Instructional Technology Team provided instruction (Chris, Diane, Mark, Marisa, Janet and myself), with two other members of our team (Don and Newell) providing hardware and software tech support. Members of the library's Research Support Team also spoke on reference assistance, information literacy, and copyright issues (always a favorite topic!)

We conducted the workshop in a large computer lab, with dual projection, both from a Mac and a PC. Each faculty member had a computer to use, this year we had 7 PCs and 3 Macs, in the past few years it's been about 50/50.

Two faculty experts on pedagogy, Stephen Loomis and Eugene Gallagher, started off the workshop with a day mostly devoted to pedagogical concepts and course design. Chris and Diane also gave faculty an overview of ConnCourse (our name for WebCT) and the technologies we would be using in the course. I attended the first day to learn more about pedagogy, and to be available to answer technical questions.

I have to admit I'm mentally exhausted by the end of the school year, so I was not looking forward to working twelve days in a row without a day off. But right after commencement is the best time to get faculty before they leave for the summer. The timing also allows us a full summer of catching up on old work, starting new projects, office cleanups, and vacations, without a major interruption. So we march when we have to, and I managed to find the resources, day by day, to perform what I hope was a good job.

One thing I realized, by the end of the institute, is how competent our faculty are in the areas of teaching and pedagogy. Running a technology lab with scanners, audio and video editing equipment, and lots of technology, I often see faculty in a state inexperienced in these matters. Not seeing these individuals in their teaching environments, it's an unfortunate human tendency to generalize any lack of knowledge or understanding of technology to other areas. This workshop gave me a good opportunity to see faculty in their own natural teaching/learning worlds, and gave me a better understanding and appreciation of their skills.

One of the main purposes of the institue is to increase faculty's understanding and appropriate use of technology. So, over a period of time, their overall experience level in these areas has been increasing, as by now over 80 faculty have gone through the institute. And, of course, some of them are ahead of us in some areas of specialized technology.

This year, for the first time, we introduced podcasting, wikis, blogs, iPods videoconferencing, and the concepts of Web 2.0 and Social Software. I'll write a few posts on my involvement with these, although many other topics were covered. Considerable more preparation was required for this year's Institute, due to the introduction of these new technologies, all in the same week. Looking back on it all, it was well worth it.

Here is a LINK to the nice brochure Janet Hayes made for the Institute (880k).

Process, Product and Presentation

I often try to think of ways of reducing complex situations to simpler ones, for the purpose of explanation, management and support. The danger in this, of course, is that something complicated, with a lot of connections, forces and combinations of underlying technologies IS really complicated. So, eventually, someone has to deal with the fact the situation is not simple in order to adequately support it.

With that caveat, I think that a student's educational experience in a course can be distilled to three things:

1. The process of learning. The interaction between teacher and student, student and the rest of the world, and interactions within the student themselves.

2. The visible end product or products of that process. These are created by the student or study group, and can be simple or elaborate. The goal of having some end-products in a student's portfolio seems an increasingly important tool in job searches. In addition, creating finished products as part of an educational activity, that we can be proud of, is a reward in itself. I still have some of the better term papers I wrote over 40 years ago, along with a few paintings, stashed in the basement. I get a pretty good feeling when I run across them.

3. The student's presentation of the created product to an intended audience. Verbal or formal presentations are becoming more common as part of the educational experience. (Many being PowerPoint shows!) This gets into the areas of public speaking, time management, and also affects design decisions at the beginning of project creation. These are sometimes ignored.

A little story about time management and design decisions. I let one of my student assistants work on her PowerPoint class presentation at work recently, as she was all caught up on her work with us. I noticed it was fairly complex, with 25 slides. I asked, and was allowed to, attend her oral class presentation. At the beginning, the faculty member reminded them that they only had 15 minutes to make their presentation. I divided 25 by 15, and knew she could not get through almost two slides in each minute! She rushed through her slides (I have never heard her speak so rapidly), and the professor gave her an extra 5 minutes at the end (standing up discreetly at one side, but looking slightly uncomfortable). Although the presentation went well, with very original content, it would have been a better experience for everyone if either the students were given more time to explain complex concepts, or if our student had somehow managed to leave out or distill important information. This may not be a typical presentation, but it was given by a senior in the top 5% of her class.

The presentation area is one where students can use more systematic support and training, in my opinion.

The extreme failed presentation, of course, is described in Edward Tufte's analysis of how an inadequate PowerPoint show probably contributed to NASA's Challenger disaster.

Naturally the three areas of Process, Product and Presentation are related to each other. By thinking of them as 3 different concepts, it may make it easier to support each one.

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.

Ideas for "Learning 2.0"

I'm always scouring the web for ideas on how to clearly and best present 2.0 concepts. I know Bryan Alexander and others, many on my "blogroll", have done some great jobs, better than I could ever do. But still, one has to develop their own little presentation eventually, geared to the group and purpose at hand. As I used to advise others...."beg, borrow and steal". I say "steal" jokingly, of course. Lately you don't have to steal any more, almost everyone is generously giving their stuff away free, they just want a little credit. So, I will try to change that saying to "beg, borrow and credit". Hmmm, borrow and credit don't go too well together, have to work on that...

Surfing through Technorati last week, I was intrigued to see "Learning 2.0" half-way between Paris Hilton and Sanjaya in search hits. This led me to the PLCMC Learning 2.0 site.

This contains 23 Things, or small exercises, that the staff members of the Charlotte and Meckenburg County Public Library could do on the web to explore and expand their knowledge of the Internet and Web 2.0. The additional incentive was to complete all 23 items by a certain date in order to to receive a free mp3 player and qualify for a computer laptop drawing.

23 Things was developed for the library staff by Helene Blowers, the Technology Director for the library. I believe the inspiration came partially from Stephen Abram's article and the 43 Things Social Software site.

Here is the PLCMC Logo According to the 23 Things Blog other libraries are adopting the program, which has been released under a Creative Commons license, and customizing it to their own needs. Seems 23 Things is having quite a "ripple" effect, with 17 libraries signed up today. Some of the adaptations are pretty nice.

Our Temple Summer Institute, a week-long faculty training session, is coming up in June, and I'll be looking at all these sites for ideas on how we can "beg, borrow and credit". Our Instructional Technology Team is more concerned with curriculum support for specific courses, for faculty and students, but there is a lot of useful instructional information here.

Nice Wired Article on 23 Things. While the individual technologies and excersises are not new, the sequencing, combination, and process that combines them in a complete and finished self-training "package" is certainly unique, and I congratulate Helene on her innovative achievement.

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.