communication english Freedom Movements techie

RE: Freedom Movements Technology

EDIT: good reference

blah, I got tired of writing this. kind of pointless, anyway, now that the blog is up there. it’s just another semester of classes.


thanks for your concern with setting up a blog for the Freedom Movements class. (okay, that first line sounds like a customer service hotline from Wallmart. eww) As a pseudotechnician who has a few years developing organizationally meaningful models to support works by nonprofits, I think your distinction between a blog and a mailing list is too simplistic. I am not taking issues with that, as this is not a big deal for me, but you triggered a chance for me to settle down for myself a bit the technosocial issues that I have been pondering about for the past months with other organizations out there, so let me expand on that. I hope I don’t sound preachy – I’m trying to figure out what would be the desirable way of incorporating technology smoothly into the classroom. (and, I can probably recycle this material to do presentations for nonprofits)

The conclusion:

I think we should first have a nonarchivable mailing list as it is a technological bottom line for most mac students. Later in the semester, as more “needs” arise, we should be able to introduce other technologies in a fairly easy manner. We cannot rely on Macalester’s default mailinglist for its lack of administrative flexibility. Blogs may not be the right solution to what the class needs as a “class”. I set up in which we should be able to incorporate students in both sections of the class + auditing students, with the only hindrance that it is located outside the Macalester intranet, potentially being prone to network outtages.

Professor Rachleff, you could send out a message now that students should feel free to email right now, even when the list is not assembled yet. Incoming messages will be put in a queue and will be distributed when the email addresses are added to the listserve. And I can activate the list as soon as I get the list of emails for the class. (If you do not have the time to process their names, I think I can find ways to automatically transform names into emails addresses, so a raw list of names works fine too)

Now to the background for the conclusion:

(this analysis includes pictures, which may or may not show up in your email client. so i instead made it a blog entry and I’m giving you the link the page. click at the link.)

Macalester’s CIT provides very basic internet infrastructural support for collaborative course work, in part for concern of the Macalester server’s stability and in part for scarcity of CIT’s staff work time that could otherwise be spent in implementing more innovative technology to the classroom.

As far as I know, besides a very rudimentary web discussion board, a majordomo mailinglist and a web space that can only take static HTML (the “course folder” is just a label put to the web subfolders), CIT doesn’t provide software for coursework. There are many solutions in use for staff use, such as the corporate calendar, the CARS system which handles student data electronically, and others. This is quite detrimental, because 1) our majordomo has its archiving options disabled, 2) the web discussion board has its user customization feature disabled and 3) database-driven websites cannot run at the Macalester server. CIT doesn’t want to take responsibility to “possible” problems that might arise when dynamic control of web exchange is allowed.

There are some solutions out there that can aid coursework. The main divisions would be mailing lists, newsgroups (or usenets) and Content Management Software (CMS)s. CMSs are programs that run in the server and allow for a more flexible management of websites, as opposed to traditionally hard-coded HTML (via a web editor or otherwise.) A blog is a type of CMS. There are also community-focused CMS’s (phpNuke among those), wikis, portal engines, bulletin boards, and so forth. Technologicaly speaking, these all employ similar techniques for coding the social interaction among its users – more solutions are showing up these days that integrate various technologies together.

When thinking about technology, I think it’s important to first consider the social and individual needs the group has or might have, and then afterwards think about what solutions might best meet those needs, and not the other way around. Sometimes, needs are “unthinkable” as technologies that meet particular needs are deemed to be an engineering impossibility, and there is some merit in hard pushing technology just to break old conceptions, but the danger of getting caught in a technology-will-solve-it-all position is bigger.

Basically, what we need at the classroom is a nonsynchronic exchange of ideas AND controllable levels of public exposure. At least, that’s what I think. What I mean by these two concepts:

1. nonsynchronic exchange. we can discuss in the classroom and in small groups outside the class hours, but this in general tends to emphasize the reactionary (i.e. there is only so much time alloted to thinking about a new question presented during class) and what’s orally available (i.e. you can’t show charts to support your point during a class discussion). by bringing discussion to written texts we can provide a channel through which ideas would reach the target even when the two people were not in the same timespace and would be able to enrich the oral discussion by pointing to pictures, photos, videos, outside websites, books, other past discussions, etc.

2. controllable exposure. students should be able to choose how much public exposure their individual contributions to the ongoing discussion gets. at the moment, exposure tends to be narrowly focused around the professor-to-student axis (no one besides your professor will ever know what you thought in your reaction papers unless you show them to other people – and I think there is a culture of “don’t bother others with your homework – after all, it’s just homework” mindset at Mac, which deters exchange of papers from happening, at least openly). I think there should at least be a “safe” space for only intra-class exchange, and a “public” space available in the web. More shades would be a good thing, too. For example, there could be partially public spaces that require a password to view its content. (that way, you can invite outside scholars/students to inside debate data without necessarily fully engaging them in the mailing list or whatever else it might be). And, students need to be able to choose between the various degrees of exposure with ease, without getting confused.

there are two more factors, which are not specific to software that supports coursework, but are a subsidiary result of the fact that many Macalester students come from non-middle class backgrounds. As a result, many either do not have a computer at their dorm rooms, or have not stayed around computers for long enough to learn to use them proficiently (what the Technology Committee at Mac calls “Information Fluency”).

3. technology needs to be simple and cannot require anything more than a web browser or an email client. anything that requires the installation of additional software, or nonstandard plugins, or a high speed internet connection will prevent some low-tech students from fully using the software.

4. students cannot be expected to go beyond accessing the internet content from a library. the ontological difference between having internet access next to your bed and having to walk two blocks in the cold to view it is wide.

There are many variations of these needs, but I think class work needs narrow down to the first two. Which technologies are available?

mailing lists

mailing lists are software that relay email messages to a given list of email addresses, allowing for the virtual creation of an email “group”. they are often used as a broadcasting channel as well as arenas for discussion.

advantages (+) and disadvantages (-):
+ they run on emails and their use could not be simpler. you just reply to an email, and the discussion can carry on forward from there.

  • mailing lists can take over your regular email, depending on how closely related you are to professor Peter Rachleff.

+ can be moderated

  • collaborative work can be tough. to get a document worked on and agreed upon, dozens of emails with modified versions of a word document (and the confusion inbetween) are necessary to achieve some form of democratic collaboration. this has to do with the fact that emails are a static material.

+ can be archived with individual URIs. the following screenshot is a well designed archives page for DEBATE, the South African discussion list

DEBATE’s web interface is really nice, and they are supported by a nonprofit dedicated to providing technology to African issues ( This probably cost some money, if not on DEBATE’s behalf, then on the nonprofit.

  • people confuse the “administration” of a mailing list with the “content delivery” of a mailing list. the result is occassional barriage of “please remove me from the mailing list” as a CONTENT
  • Macalester’s mailing list software sucks. Or, it has been disabled of some core functions to allow a “safe” handling of the mailing list, making it almost useless.
  • free commercial mailing lists available on the internet (yahoo, google groups beta, topica, etc) are SLOW. what takes 1 or 2 seconds for a Macalester majordomo to handle, it takes minutes or hours depending on the condition of the mailing list.
  • free commercial mailing lists usually include ads. they ain’t pretty.
  • independently hosted mailing lists solve the above three problems, but they are still prone to internet outtages. by an outtage I mean cases in which the entire campus loses access to internet. in those circumstances, all messages are queued (unless CIT really messes things up) these things have happened a few times last year.

+ internet outtages occur less frequently than Macalester majordomo downtimes. so, at least they are more reliable than Macalester’s own mailing lists.

  • emails are closed systems. by this I mean that no one, except the “recipient” of the email, can have access to the content of the email. therefore, mailing lists tend to be closed systems. this can be fixed by the use of public archives, but in pulbic archives you have control between “public” and “private” and nothing in between. Furthermore, a “public” or “private” setting applies to every single message in the mailing list and cannot be applied selectively.

There are many ways of setting up mailing list archives. One way is to subscribe a free commercial mailing list to an independently hosted mailing list. (I do this with MPJC and SLAC because there isn’t enough space in Adelante!’s servers to store attachments)

MPJC’s mailing list:
combined archives for MPJC, SLAC, MSFT

Another way is to feed mailing list exchanges as a blog entry., among others, offers this option, which I have implemented in FAC’s announcements-centered blog

FAC’s mailing list
FAC’s blog

The reverse is also possible. Blog entries can be fed as emails in mailing lists.

Of course the standard way of doing the archives is simply by using the internal archives function of the mailing list. We had that in adeantemac’s lists, and decided they were taking too much space. Since I blew that up after January, I can’t show you those, but they look like the DEBATE listserve above (a bit uglier) and each email has its own URL address so they can be reffered back.

newsgroups (usenets)

newsgroups are quick, simple, keep a archive of “most recent x number of” posts, but require a separate usenet client. (at least mulberry can’t touch it, and there is no web interface as far as I’m aware.) out of the question.

bulletin boards (BB)

bulletin boards are CMSs that present a list of texts written by the users, and enable threaded discussion on each text (also called posts, articles, etc). this discussion can be on a post-against-post basis, or on a post-against-comments basis. the important thing is that bulletin boards are used usually for a discussion on various topics by a group of people. it would be weird that individuals used bulletin boards to write personal stuff, as other CMS are more appropriate to discussion-less texts. similarly, it would be also weird to have bulletin boards with the discussion feature disabled and functioned as announcements-only, as other technologies are more appropriate. (the discussion is the whole point of a bulletin board). post-against-post bulletin boards look a lot like mailing list archives, and the trend is to have a post-against-comments format.

+ post-against-comment BBs allow for a fairly dynamic framekwork on working with IDEAS
+ they can linked with emails in a more flexible manner. users can individually opt to receive notifications

  • these days, BBs have too many features, and even if you deactivated most of the unnecessary stuff, the user interface of BBs can still be quite confusing to new users.

a random philosophy discussion site I googled (pure post-against-comment format)
Macalester Curricular Renewal (post-aginast-comment format, but also has a sidekick interface that presents a post-against-post format)

sample listing of topics in a BB

sample view of a “post” in a post-against-comment format

sample view of a “post” in a semi post-against-post format

in this screen, Daviod Chioni Moore made a post titled “the no curriculum option”, to which Danny Kaplan made a “comment”, which was presented as such in the “post” screen. This is a post-against-comment format. But it can be seen that in the index to the left, there are two links called “the no curriculum option”, each linking to each “post” This is a post-against-post format.


blogs are CMSs that present content in a linear format. in a blog, the most recent “post” is located in the beginning of the site, with the rest of the “posts” following in a chronological order.

+ the biggest advantage in blogs is that they can individualized, in the sense that each person can have her or his own blog and produce their own texts.

  • blogs lack the “open debate arena” feel of BBs. but this is very appropriate for blogs, as they are primarily a repository of individually produced texts that the author may choose to bring or to not bring to the public forum.

+to compensate for the lack of a shared field for discussion, blogs usually feature trackbacks, which indicates that a secondary text B was written in response/reaction to text A. trackbacks work by modifying text A so that it says somewhere in the text, “this text was referred, or trackbacked, by text B”
+blogs can also be linked together with emails (see the last comments on mailing lists above)
+is often used by groups of writers as an online publishing tool.

The course blog that just opened is a good example of how blogs work.

community-focused CMS

CMSs in the line of phpNuke offer a variety of community tools, that allow people to supplement (or replace?) their social interactions with other people sharing some interest. community CMSs are usually all-inclusive sites with internal emails and messaging, BBs, event calendars, and a newstelling system quite similar to blogs but with more features, etc

-in general these CMSs overuse scripts and slow down the client’s browser.
-it’s not really for a class

This is a gaming group CMS that I googled to make the point.


I give up. I’m sure it can be refreshened up to do “consulting” another time.

Leave a Reply

Your email address will not be published.