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.

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.

Can Academic Staff Learn Anything from Sports Coaches?

My daughter played competitive sports for many years. I feel she learned many lessons as a player that carry over to general life skills and strategies. Recently I became aware of lessons that athletic coaches can learn, and how these also carry over to leadership in other areas of life.

The December 2006 issue of Fastpitch Delivery, a softball trade journal published by the National Fastpitch Coaches Association (NFCA), has a good article where Jeff Janssen and Greg Dale interviewed some of college sports' top coaches to determine the secrets of their success. They discovered a new style of coaching they call "credible coaching" that focuses on developing solid relationships with athletes based on trust and respect. This is unlike the traditional style of coaching which used fear and intimidation to motivate athletes.

I think many of the characteristics of what they call "credible coaching" can carry over to team building and leadership in the real world. So here are a direct quotes from Jeff Janssen's article on Credible Coaching: "Coaching is about relationships....You have to create an environment of trust among your staff and athletes. Without trust, you have nothing. If you do have trust, you will be able to accomplish great things."

Janssen and Dale identified seven primary components associated with successful coaches. Credible coaches are:

1. Character based
They seek to do the right thing. They are honorable people with high ethical standards and great integrity. They tell the truth to their athletes and never manipulate or play mind games with them. They conduct themselves in a professional manner and take pride in representing their teams and athletes with class.

"A lot of our success in Duke basketball has to do with character. And at the heart of character is honesty and integrity" (Mike Krzyewski)

2. Competent
They have a thorough understanding of the strategies and fundamentals of the game. They know how to make the appropriate adjustments. They are highly inquisitive people who continually look for innovative and improved ways of doing things. Further, they understand that admitting their limitations and mistakes is actually a sign of strength, not weakness. Even though they are highly capable and often revered people, credible coaches tend to remain humble and keep their success in perspective.

"Sometimes the most important listening you do is the listening that comes after you've reached the top, after you've gotten very good and could be susceptible to the idea that you know everything." (Dan Gable)

3. Committed
Credible coaches are highly committed people. They create successful visions for their teams and are more than willing to put in the time required to make them happen. They have a true passion for sport and coaching which fuels their intense drive and enthusiasm. They also have incredible reserves of energy and resiliency which enables them to weather the inevitable storms of adversity.

4. Caring
Credible coaches care about their athletes as people. They sincerely want the best for their athletes in all aspects of their lives and are willing to help them in any way possible. They invest the time to get to know each of their athletes on a personal level, showing an interest in their athlete's families, friends, faith and future goals.

"I know if somebody really cares about me and is really fighting for me, I'll go through a wall for them. The same works in reverse. If somebody knows you don't care about him and aren't really fighting for him, then he won't go through the wall for you" (Mike Shanahan)

5. Confidence-builders
Credible coaches continually build their players' confidence. Credible coaches have a special knack for making people feel good about themselves, capable of achieving almost anything they set their minds to. The are demanding and set high standards, yet are patient enough to help athletes develop and improve. When athletes do fall short, they use a good balance of being challenging and supportive to get people get back on track.

"When people realize that someone has faith in them, productivity usually increases. We have a natural desire not to want to disappoint those who believe in us and trust us" (Tom Osborne)

6. Communicators
Credible coaches are excellent communicators. They are open, honest and direct when communicating with individuals and the team. They continually remind and refocus people on what they need to do to be successful. They seek to involve their athletes as much as possible and value the input they receive from them. They have the remarkable ability to truly listen to their athletes. They take the time to understand where people are coming from and are able to make decisions accordingly. Because of their ability to listen, credible coaches are often aware of concerns and conflicts, and proactively address them before they become major problems or distractions.

"You have to listen to develop meaningful relationships with people....You can't do that by talking. You do that by listening. What I have learned is, coaching is not all about me going into a locker room and telling them everything I know about basketball. It's a matter of knowing how they think and feel and what they want and what's important in their lives. Listening has allowed me to be a better coach" (Pat Summitt)

7. Consistent
Credible coaches develop a sound philosophy of coaching. This philosophy remains stable over time, but they are flexible enough to adapt to changing situations or personnel. They maintain a consistent approach to rules and standards for the team. They tend to be highly organized people who take their practice and game preparation very seriously.

I could not find the article on the NFCA web site, so I have taken the liberty of directly quoting relevant passages for the benefit of the non-softball world.

My opinion is that being a "credible coach" is a big, challenging task, and that it is hard to find a coach that scores high in all the above areas. Naturally, you also need talented players and support staff to be successful. The above principles only provide a successful path to reach a common goal, once you have that talent on your team.

Not all of these components may be relevant to leadership in academic settings, and most IS staff probably do not want clones of Pat Summitt or Mike Krzyzewski yelling at them from the sidelines. And, I'm sure that Pat Summitt teaches as much as she listens. The point, though, is that listening is very important to her.

However, some of the concepts Jeff Janssen and Greg Dale have found can be used by leaders in any field to improve the effectiveness of their teams. All levels of leadership, starting with the staff member that supervises one part-time student assistant, can benefit. It is perfectly justifiable to cherry-pick the components that resonate to individual situations.

One should note that not all good players make good coaches. I remember two players that helped a college win a national championship, and then graduated and made a mess of coaching a summer team of young girls. So, some of us may be happier and better suited to playing on the team than coaching from the sidelines.

A final thought is that in sports there are usually winners and losers. In academia, everyone can be successful, there do not have to be any "losers". Maybe that's one reason why a few slightly-jealous folks claim we "don't live in the real world"!