[Home]UniversityWiki

MeatballWiki | RecentChanges | Random Page | Indices | Categories
This page discusses the possibilities and necessary differences when applying WikiTechnology in a University as a tool for students communication.

Proposed by DavidSchmitt from the [Technical University of Vienna]. With helpful comments by HelmutLeitner and RustySmith.

Parts pertaining local situation and decisions should be split to UniversityWikiProject?.

1. Situation until now
1.1. Courses
1.2. Communications
2. Situation from now on
3. Goals
3.1. Student Guide
3.2. Full Replacement
4. Reasoning
5. Information structure
6. Security
7. Comments

1. Situation until now

Until summer 2003, two systems existed to provide information for students. The LZK ("Lehrziel Katalog") contained information on individual courses, via the other - dubbed SIDES-4mi - students subscribed (not enrolled!) to courses and received announcements and automated update notices for course webpages. Mailinglists for each course existed.

While most staff members updated the informations for individual courses (at least when the course was founded), there were several areas where the systems failed miserably.

1.1. Courses

On the positive side has to be noted, that those systems provided all essential information on the courses for the students. Sadly the LZK provided no means to navigate the courses from the curriculae. For example a student could not determine which courses he had to enroll given his enrolled curriculum and term. This information was primarily available via printed booklets, sold by the same group who did the LZK. [Considering it from this angle, I am not surprised anymore about the online (un-)availability of this information]

(Actually, the possibility to select all courses matching a given curriculum and term *did* exist through the "advanced search" page, although the data was not always accurate.) -- HeinrichMoser?

1.2. Communications

While SIDES-4mi provided a standardised avenue for the staff to broadcast information to subscribed students, the interface for staff members did not run even on all windows platforms even though being programmed in Java. When it could be run, it was a pain to use. This reduced the participation of the staff significantly. With repercussions on the quantity and quality of available information.

The mailinglists were mostly unused. Probably because the average student is as electronically illiterate as everyone else. (Which is actually a shame, especially for computer science students.) (Where should they learn it? The university obviously doesn't care.)

2. Situation from now on

In the summer holidays, the administration has replaced both systems with a self-programmed web application, which will improve the situation for the staff considerably [although it scores quite high on the CSS FeatureKarma]: http://tuwis.tuwien.ac.at/

3. Goals

Currently there are two major proposals on the table. The first is a student guide, the other a full replacement for the SIDES-4mi functionality.

Secondary goals include

3.1. Student Guide

Goals, grouped by dependency and priority.

Current TUWIS++ implementation: http://tuwis.tuwien.ac.at:8080/_ZopeId/14824436A09e.CDp4JE/tpp/lv/lva_html?num=188277&sem=2003W&nomnu=1

Current TUWIS++ implementation (http://tuwis.tuwien.ac.at:8080/_ZopeId/14824436A09e.CDp4JE/tpp/lv/sp/sp_html?kode=937&byear=2003) is missing some important features, e.g. course type (mandatory, optional), course group.

Currently only possible through mailing lists (e.g. http://www.alpha-i.at) or message boards (e.g. http://www.informatik-forum.at)

Supposed to be included in TUWIS++ through mailing lists.

3.2. Full Replacement

In addition to the points of the student guide, this would need

4. Reasoning

Provide the primary information source for students. This includes information about courses (where, when, who, what) and curriculae (general information, which courses are available and which are necessary). Webpages containing this information already exists, but are scattered and under-maintained. Often students have to rely on the GrapeVine? to find appropriate courses and information about the more obscure oddities of students life. Communication about courses is seldom. There exist web boards and mailing list for almost all curriculae - unofficially organised by a few students. Most of them are well-frequented but suffer the usual discussion-based problems. See WhyWikiWorks for a more in-depth analysis.

To pack all this into one wiki like system it would need all the information about courses and curriculae as well as a few students in each course maintaining and polishing the information.

The wiki should be understood as means of communication between and with students. While it would be great to be acknowledged as "official", this would bring with it responsibilities like registration which are high risk/low value to the students community. Also it would run against the points raised on LimitTemptation. It has to be noted, that optimal information probably only can be achieved in cooperation with the staff, but in contrast to the current centralised system, useful information can also be propagated without cooperation from the staff.

Usercount: Just as orientation, the Technical University of Vienna has approximately 11_000 active students, 1_000 members of the educational staff and 5_500 courses.

5. Information structure

6. Security

Users of a university wiki have high stakes because of the sensitive information contained, for example regarding exams.

Therefore strong safety nets have to be provided without being obnoxious or in-the-face. Here a discussion of the things mentioned on SoftSecurity, with a focus on the setting of the university. This is obviously and intentionally biased towards considerations about the Technical University of Vienna, where DavidSchmitt studies, since this page is also a summary of thoughts and arguments for the team.

Since the wiki will probably generate more changes than a single individual can or want to check, mechanisms for filtering changes would be nice. See CategoryFilteredRecentChanges and RecentRelatedChanges.
Following up to remark from SoftSecurity (It does let you know who was responsible.)
Since there are no logins on a wiki, responsibility could only be traced to a (time,ip address) tuple. Nevertheless, this should be sufficient even for appropriate reactions.

Older things which are mitigated by reducing the scope to an inter-student communication platform.

HardSecurity stuff:

Psychological problems:

7. Comments

David, I also think that WikiFractality can solve a lot of problems. Some of our wikis are growing out of their (logical) bounds and we tried to solve this problem by using groups of sister wikis under a common layout. But this concept seems difficult to grasp and also needs maintenance and won't scale beyond a dozen wikis. e. g. http://www.pm-bau.at

Since curricula are quite separate entities, splitting it up into one Wiki per curriculum would be a possibility. The problem though is, that some departments offer courses for several curriculae. Perhaps NearLinks could solve that. On the other hand, I plan to start small and just cover the basic stuff from CS, so this is probably only relevant for version two ;)

On the other hand the average wiki user takes advantage of advanced features only slowly, step by step. An organisation may take years to make the wiki transition. A hierarchical paradigm will help because it is easy to communicate.

At first, it will probably only serve the courses my friends and I visit and have a quite small visibility. Later on this will depend on how much it will be accepted by the management. If it stays some weird student project, data-entry for new courses will have to be automated (sucked down from the official pages) and teacher-cooperation will be few and far apart. If it is actually accepted, professors will have high incentives for participation and for students, I try to be realistic and aim at one or two editing students per course.

It isn't clear to me why a wiki is better for relatively static information like course listings. These probably already exist in electronic form, via the tools used to handle registration and print the course catalog. Why is a wiki better than, say, a database interface? If the existing web page is poorly maintained, why will a wiki be better?

Katherine, I agree that it may not be such a good idea to push wiki as a tool for tasks that are already solved in a classical way. On the other hand, wiki maintenance is much cheaper than any other type of maintenance, so if one could get the staff to care for their data, it may save a lot of money and improve the system. We have a wiki that is used by the Lions Club Austria to maintain the meetings and events: http://www.wikiservice.at/lions/wiki.cgi and this worked quite well for this purpose. -- HelmutLeitner

The current system has a cr*p JavaApplet? and a complex RightsSystem? for the staff to maintain their courses. Everyone hates it. The basic structure which courses exists has to come from where it is decided, but the rest can be WikiMaintained?. I am much more concerned about angry abusers ...

Because the static part is dead weight without the GrapeVine?. Since this part is maintained anyways in a database (and most probably I won't get direct access there) I am already thinking about generating semi-static parts of the course-specific pages from external sources or keeping theses things in a relational database or at least with custom tags. This is also a question of more structure vs. EaseOfUse?.

OTOH, I can see how a wiki would be good for more dynamic GrapeVine? and CommunityMemory? type information, but that's the kind of stuff that big organizations tend to be uncomfortable with. (Professor X is a sleep aid. Avoid his early morning classes.) Perhaps decoupling the two kinds of information is the way to go?

In Austria, there is something called "Lehrveranstaltungsevaluation" (german for "evaluation of courses"), which is currently implemented as a set of unwieldy webforms. So in the law and the upper management this is being pushed. The problem will be how the professor/assistant/department will react and how students will act who feel unfairly treated.

What we have been asked for many times during these years: "Can't we have a part of a wiki that is closed only for this project X, that's not for the public." or "We work in this project management course, but don't want that other groups see our work." or "We have this closed wiki, but we want to publish out results on some pages that should be readable by the public." We have introduced a number of feature to implement such things on a small scale, but never in a way that normal users can handle themselves.

In discussion with several people, the pseudonymity coupled with the strong emotional involvement of the students would make a true wiki a too easy target for abuse. After reading LoginsAreEvil, I think that a password-less solution might be preferable after all. Including registration for courses and similar things.

The number of 10.000 users sure looks intimidating at first sight and I don't see a wiki that could cope with that many active users *today*. Each of the bigger wiki software systems (WikiPedia, TwikiClone, MoinMoin, ProWiki, maybe SwikiClone and UseMod) can be grown into this task but this depends on the collaboration between users and developers. It has nothing to do with hardware. The majority of our 60 wikis run together on 1/10 of a managed server. On the other hand for a chamber-of-commerce project we use a separate dedicated server (30GB, 2000+) to have maximum processing power - the hardware costs are neglectable. So it is just a matter of really tuning a system to a task. If someone wants such an UniversityWiki today, it surely can be done.

Hmm, performance is something that troubles the current system. At the beginning of the term everyone wants to search for courses and accumulate their time table, thus creating enough load on the system that there are noticeable delays. Does anyone have experience which part of a wiki produces the most processing time?

Three wikis in universities that may be interested with this discussion:

Thanks for the links. Quite interesting stuff, although I had some troubles navigating those beasts. Probably I expected too much, because I want some more structure. Let's see if we can invite anybody :)

The lack of structure seems to be common to most wikis. The freeform text and links lend themselves to blurry hierarchies and random connections. That's a big advantage for WikiApplications?, but a disadvantage if you're trying to present information that has some inherent structure.

Thanks for the invitation to participate, David. WikiFish.org launched at auburn university about 8 months ago. It was initially started as a way for a small group of organized students to discuss concerns that they had concerning the deterioration of what in architecture schools has become known as "studio culture" (commonly characterized by habitual sleep deprivation, etc.). One of the problems this group faced in organizing their efforts was that our students are from a variety of year-levels, have differing course schedules, and are often located outside of Auburn participating in one of our variety of traveling and remote programs. As the faculty advisor to this group, I became increasingly frustrated with the inability for this group to codify any of their thoughts and observations into action. In other words, we had lots of great meetings (read: BitchSession?s) but no real action was ever taken. I began to investigate ways that we might begin to capture some of the information, insight and knowledge produced from these meetings, and after trying out EmailRing?s (they quickly spiral into disconnected ramblings) and blogs (too monolithically linear) I discovered the world of wiki. We were quickly kicked off both usemod and meatball for being too off-topic (we were using the wiki to collaborate, but not about wikis) and after a little hunting around, found a home at SeedWiki, hosted by Kenneth Tyler at 8th Fold. The document that emerged from our initial collaboration was the development and production of "A Students Bill of Rights," basically outlining what level of service and commodity a student should expect as a member of our studio community - this document was gleaned from various observations, statistical data and anecdotal stories about the students experiences here at Auburn University that were posted to WikiFish. There were about 8 truly active members of this first group. At the beginning of the next semester, I ran a joint studio between First year undergraduate architecture students and first year graduate landscape students. All of the projects in this studio were collaborative, (individual students performed work that was subsequently part of a larger group project, which in turn was part of a single large studio project). WikiFish became the primary medium through which all information was communicated. The students began to joke that "if it was not on wiki, it was not golden." We then began to use WikiFish as a way to distribute projects and course material (readings, etc.) as well as a way for the students to develop and submit for review much of their written work (thesis research, etc.). Finally, WikiFish continues to be a tremendous venue for sounding off, and the dissemination (and sometimes even dispelling of) grapevine and hallway rumors.

Disconnected Observations on Wiki for this type of communication:
1) Tempers flare. For some reason, an antagonistic position of a writer is often perceived by a reader, sometimes leading to an escalation of attacks due to simple misunderstandings. These misunderstandings rarely happen face-to-face, as the various nuances of physical communication take over. This most often occurs with new users, and takes some policing to get over.

2) It take a lot of work to get students to actually respond to, edit and refactor other people's work. Posts are often considered sacrosanct, and it takes a while for the students to learn that a piece of an idea plus a piece of another idea might just equal a really good whole idea - we actually initiate wiki project assignments that help develop this attitude.

3) The "recent changes" page is addicting. Most regular users of our wiki are recent changes junkies - meaning that very few enter through the front door, and making it very difficult for outsiders to understand the structure and organization of information that seems so "apparent" to us.

4) about 80% of the posts to our wiki are absolutely junk - inside jokes, passing fancies, etc. This sort of "goofing off" is valuable in a couple of ways, however: it gives us some insight into what is going on with the students on a day-to-day basis, as well as lets them develop personal relationships with each other.

5) the optional anonymity provides a more common ground for discussion concerning issues between students, staff and faculty. We have already had a number of instances in which anonymous discussions have affected changes here in our program.

6) as a repository for the institutional memory and management of this resource the wiki has been invaluable; younger students learn more quickly from the past experiences of the older students; it also in a funny way breaks down barriers between our year levels. Students first begin to communicate via the wiki about similar interests, and subsequently become more comfortable seeking each other out for face-to-face time. Our department head has recently made the observation that our students are more knowledgeable of each other more than ever before due to the initial contact they have with each other due to this resource.

7) Wiki makes our IT group more than a little nervous. What with the lack of control and access, the hard infrastructure being located on the opposite side of the United States, and the lack of organizational oversight, it is a wonder that they even sleep at night! [IT groups all over the world seem to have magnificent paranoia. I cannot truly imagine how our IT group would react, but they would surly get creeps :))]

I hope that this information is of help to your discussion. We are working hard to develop this type of forum into an even more useful tool, (it will be a cornerstone of a collaborative studio effort with another architecture school next spring) and are eager for any suggestions and observations that users from this group might share. [RustySmith]

Rusty, thank you very much for your input. This is a quite encouraging RealityCheck?. You might want to take a look at WikiFractality (how to partition a Wiki without splitting it) and SoftSecurity (interesting background info WhyWikiWorks and why LoginsAreEvil). Especially the pages referenced from the latter provide deep insights into the working of a (wiki) community.

Did you have any significant troubles due to the anon- and pseudonymity, like abuses on assignment-pages or so? After your description I would presume not, it seems to be quite a small community. How many students are using the WikiFish? -- DavidSchmitt

We have about 450 students in the School of Architecture. Of those we have about 90~100 regular daily users. We usually average around 200 edits per day (many obviously minor) and usually have anywhere from 3000~5000 "real" page hits by users per day (pages that actually hit from a link within the wiki, not simply "crawled" by some sort of bot). We currently maintain about 1200 non-archived pages that sustain some sort of activity, but of course many of those only see activity once in a blue moon.

We began using the wiki in our first year program; our second batch of first year students have recently been introduced to the forum and our third group will be introduced when the new semester starts in about a month and a half. Our thesis students that are here on campus this summer have also been introduced and next year's students will also be required to begin using it for course work. About 30% of the student's that are required to use it for coursework also use it for other real "wiki related" activities. We expect this number to grow as more students are formally introduced to its usefulness.

We have suffered only a little trouble with abuses. In the beginning, WikiFish was used by a small core group of about 8 users. A couple of months later, we rolled it out as a communication venue for the use of 2 design studios that were collaborating projects together (these studios met at different times and different locations). This expanded the regular daily use to approximately 45~50 users, not including faculty and other "outside" participators. An interesting phenomenon of anonymity occurred at this point when an individual named MitchWeaver? joined the discussion. Mitch was a fictional person, but since none of the students from one studio knew the students in the other, it took a while for the students to figure out that Mitch might not be real (I myself had to check the class rolls to figure out that he was not an enrolled student). Mitch was a heavy (but not heavy-handed) participator in the conversations, down to spending a tremendous amount of time actually performing all of the on-line assignments. He was soon joined by his girlfriend SandyBarwood?.

When rolling out the wiki, in various wiki posts, I always made a big deal out of signing one's work with either their WikiSignature? or at least with AnonymousDonor. When Mitch and Sandy showed up on the scene, for some reason I decided to treat them as "real" identities, never letting on to any of the students that they might be other than that. Whoever these characters were in real life, they did a tremendous job of keeping their true identities a secret - quite a feat for anyone who perpetuates a hoax for long. Eventually, several of the students actually decided that I was Mitch and/or Sandy (I was not).

A couple of months after this rollout, the studio students, wishing for greater school participation, performed a significant "advertising" campaign around the design campus for WikiFish, which brought in a host of new users (about 100 more users) , a few of which were malicious. The first three days after the larger school began to participate myself and several very dedicated students spent most of our time repairing and replacing (through SoftSecurity measures) large portions of the wiki that were being damaged or deleted. It was a great object lesson for the students - at first they panicked at the damage that one or two individuals could inflict on the larger community, but they quickly figured out that 4 or five people could, through sustained perseverance and watchfulness, out live any attack. Now, I usually am not even aware of any maliciousness, as we have a good core group of folks that are pretty watchful. The real casualty of this larger roll-out was that we lost both Mitch and Sandy (their identities were co-opted by many others). They both committed WikiSuicide? / WikiMindWipe as their status was diminished to a bad joke.

I have often been surprised that we suffer from little to no identity theft - I cannot imagine that it is simply because no one has thought of it. Rather I think that it may be because many of us come in real contact with each other on a semi-regular basis, thereby making our wiki contact that much more visceral. To my knowledge, even I have not suffered from an impostor, and I would seem to be the most logical target.

We have suffered only a few problems with "editing" of students assignments (this is usually relegated to students personal pages, and manifests itself as benign inside jokes and horseplay amongst friends). We have had a few instances where it has not been in particular good taste or just down-right mean spirited, and at that point I will step in and repair (at least the physical) damage. Usually that is enough - however a couple of students' pages that many of the other students do not care for (often for legitimate reasons, I might add) take regular policing. If there pages show up in RecentChanges, I know it is probably for reasons that are not very positive.

We do have a couple of instances of WikiFractality, most notably RengaWiki?, which started out as a student's personal page. She was interested in prose and poetry, and started a page that was to become a single, long running verse. She subsequently began having weekly competitions for participants to submit entries too (each week featured a different form) and the winning entry was selected by a group of poets in our English department. I think the usual prize was a six pack of beer or soda, either of which you had to share with the student. Her page has now become a doorway to many other pages that are on a separate wiki. The separation has cleaned up WikiFish's RecentChanges page, but at the cost of her users - she does not get nearly the casual "passerby" traffic she once did, and is thinking of moving back within the fold of WikiFish. The active presence of the work is missed.

Ultimately I believe that our wiki works due to the rather unique environment that architecture students share. A class works together in a studio, which usually consists of a large open room that holds about 15~20 students sitting together at large desks. We have about 15 hours of scheduled class time together, but the students may spend 70+ hours together in studio per week performing studio assignments, and many more hours doing work for other classes. The studio is truly a place where the students perform the bulk of their living while in design school - in other words, studio is a 7 day per week "lifestyle." We have 18 studios on 3 floors in our building. In this situation, the students get to know each other pretty well, the wiki is just one more way that allows the students to get to know each other better. Next year we will begin to use it to collaborate with more studio students at other universities that we do not have direct contact with. I am interested to see what dynamic will emerge. [Reminds me of the MitAiLab :)]

One final observation that may be of interest to the group as it pertains to wikis in the university: Over the past couple of months WikiFish seems to have gained just about enough critical mass to become self-sustaining. In that time, I have begun to decrease my overt presence in the community discussions - I usually relegate my presence to assignment posting and response and often will only respond to an issue or question when directly requested to. As a figure of authority to the students, my responses will often shut a topic down, as there is a perception of "the final word of the professor" amongst the students (this observation is not my own - it has been shared with me by a number of students). Often as a topic will lose steam, a request will finally come such as "well, Rusty - what do YOU think?..." at which point I will put my two cents in and refactor and then attempt to spin the discussion into another direction. Ultimately I try to maintain a delicate balance between letting the students know that I am always there, lurking, but maintain a relative hands-off approach to most of what is being discussed. For me, the maintenance and "feel" of the wiki as an open forum that is policed by the student community - not the university institution - is ultimately of the utmost importance. As faculty, we may set examples for the student, but in the end, the students have to lead. It is their education, not ours. [RustySmith]

[Weblogs and Wikis at Bemidji State University]

I started the [Blogs and Wikis] wiki as a collaborative writing space for a course focusing on online writing, but it became an informal course management system, too. That it's often difficult to isolate the course management from the student-created content is one of the big virtues of using a wiki in this way. But it remains more a writing space for students than a course system for me. The more I work with it as a teacher, the more I find myself tapping into the student's work.

I teach rhetoric and writing so I come at the wiki from a rhetorical perspective, seeing wikis as shifting both the practices and the epistemic ground of writing. Some observations.

1. Lack of prescribed/a priori structure. Lack of an obvious formal structure can make the wiki hard to review, but loose structure and multiple structures are a virtue of wikis. The structure is in the project engaged or the participants rather than in the wiki itself. When I teach the course, i create a new (or modified) syllabus in the traditional way: I write a time-stamped list of readings, discussions, and assignments on the EntryPoint?, and archive it as the course proceeds. This lets me re-use some materials, re-cast or refactor others, create new materials, and incorporate student work on the fly. It's like jazz: there's structure back there, but the practice is an improv with students. The wiki could be (re)structured if someone looked through the pages that have been developed to create categories and indexes.

2. As RustySmith at WikiFish mentioned, students in the course (mainly English BAs and BFAs) are shy of responding to writing in progress and refactoring. MA candidates are a little less timid, but apologetic. Students (without a programming background) are also unfamiliar with the practice of refactoring: they don't know how to do it, and they don't trust themselves to do it well. I demo it in class and in the background, silently refactoring some of their work so they can see how they might proceed. The difficulties of contributing and refactoring hold back the development of content on the wiki. To address it, I write refactoring right into the [StyleGude].

2a. Part of the refactoring problem might stem from the difficulty in writing from a neutral stance or a BalconyView?, and from a difficulty in synthesizing alternative perspectives. I've encountered similar problems in students writing analyses: they want to move to evaluation before developing a ground for analysis. This can be addressed by instruction - show students how to do it - and practice.

As RustySmith mentioned, the course wiki becomes both a repository and a studio. That is a big part of its value. Studios - especially shared studios - get messy and need to be cleaned out and rearranged now and then.

3. Are we a GatedCommunity? The Blogs and Wikis wiki is cast as a FishBowl rather than gated. We can be seen, and readers are invited to contribute: I can email the password. We use a password to minimize maintenance. Visibility is a significant element of the rhetorical situation the students write in and shapes much of their work, both the topics they take on and their approach. The wiki is there as much for external audiences (teachers, other students, theorists, rhetoricians, others interested in wikis) as it is for students of the course. We want to be seen, and we are being seen. CMS such as WebCT? and BlackBoard? are gated: high impenetrable walls. FishBowls? are fragile.

4. [Blogs and Wikis Wiki] is pretty self-referential. The content the students work with and create address writing weblogs and writing with wikis. In their wiki articles they address matters of writing online that affect them, that they are interested in: audience, creativity, academic writing, wiki culture, and so on. This content is developing slowly, but I'm getting better at guiding it and students better at creating it. Some, but too few, continue to contribute to the wiki after the course has finished each semester, but life moves on for most of them.

Hope this is helpful. Both MeatballWiki and WikiFish have been instrumental in the development of [Blogs and Wikis Wiki]. We want to give something back. MichaelMorgan

Suggested reading:

Project News

-- David Schmitt

Other university wikis:

CategoryAcademia CategoryEducation

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: