Monday I asked if anybody knew how email worked and what it might be good for. Based on some of the bloggery that’s come back, let me take some time to walk through the analysis of email.

Historically, email is one of the oldest applications on the internet. The ability to route messages asynchronously based on an address has been with us since the earliest days. Email is a classic example of a kind of technology that has become an almost universal model of content management — the “client-server architecture” model.

In client-server models, information processing occurs in two places. A central repository of content holds a store of material for delivery on demand to various calls for information and responds to a collection of instructions that cause the repository to add, delete, deliver, copy, or otherwise deal with the collection of information it has stored. A second piece of software is used to manage communications with the central repository in a way that the person using this software doesn’t have to worry about how the central repository is set up. You just tell your software what you want to do and it negotiates with the repository to do it. The repository is the server. Your piece of it is the client. They are connected by the network in such a way that commands you give to your client are transmitted to the server and the server’s responses are transmitted back. The client interprets the responses and tells you what’s going on.

Compare that with a simple software model — like your word processor — where all the manipulation of the information happens on your machine. You type something, it doesn’t go any where. You save it, it’s stored on your machine. You don’t need any connections to do this. It’s all contained on your computer.

The advantage of the client-server model is that you can do really complex things really quickly with large amounts of data by distributing the load across multiple platforms. You have some overhead involved with the network transmission, of course, but that’s why broadband access matters in a distributed world. The ideal is when the network can handle the information as fast as your computer can call for it, but we’re not there yet.

In the specific example of email, various entities create postoffices that collect, collate, and distribute the electronic mail files centrally. It might be your school, or your internet service provide. You may use Yahoo or GMail. They all do the same thing — they get mail coming in, they forward any outbound mail to other post offices, and they store your mail for you to read/download/dispose of. You use a piece of software on your computer to help you manage that disposition of email. If you use a webmail interface like you see in Yahoo or GMail … or a stand alone client like Outlook Express or Thunderbird … your client handles the negotiation between you and the postoffice (email server) so you can read, write, reply, forward, attach, delete, sort, flag, or otherwise deal with your email.

That’s simple email handling.

There’s another level of email processing called a “list server” and we use one to manage email across our little band of learners. You all told MajorDomo what your email address is and that you wanted to be put on the list for “email to the class.” MajorDomo is a relatively simple server that is designed to manage the bulk distribution of email. You tell the listserver what group you want to join and what your email address is and everytime any email comes for that group, the listserver makes sure that everybody in that group gets a copy of the message based on the settings established for the list and for the user. This makes it very easy for very large groups of people to follow along a discussion carried out in email without having to know all the email addresses of the people engaged in the conversation. Just email the list and the list server handles it by routing a copy of the email to everybody who said they wanted to be a member.

Now, how the servers and clients accomplish all this is thru the use of a set of standards called “simple mail transfer protocol” (smtp) which describe how email will be transfered, routed, stored, etc. You don’t really need to understand what the standards all are — that’s what your client is for. It knows and it can deal with them. You need to know what the communications characteristics of email are in human terms.

In the last five years, email has exploded. Almost everybody has an email address these days and anybody who doesn’t is really operating at a disadvantage. That wasn’t true five years ago, and it’s still true that even people with email don’t necessarily check it everyday. So one of the dimensions of email is the level and regularity of use. For example, I’ve asked that you all check email every day. I do that so you will be getting the information you need to be successful in the course without having to remember to log into Blackboard to find it. Using email this way, I’m able to counter the common belief that online students need to have “better time management skills” or that they need to be “independent learners” because I’m able to use email to remind, chide, and chivvy you all in very much the same way a teacher in a classroom might announce “Remember your homework is due tomorrow!”

Now I used to use email to deliver these daily posts, but with the spread of blogs and ‘gators, it just makes so much more sense to put my daily writings up where you can see them, refer back to them, aggregate them, and generally organize them like any other kind of online content. Email is, after all, a silo and anybody who isn’t a member of the list at the time the message is sent doesn’t get a copy of the message. This way, we have an archive of content and I can use the list to just remind you that it’s out there.

Email is particularly powerful for short, fast turnaround kinds of messages — less useful for extended writings. There are other kinds of uses — yes they’re all communications as one of you asked — but there are a large number of communications goals connected with teaching and learning. The key is understanding enough about how people use the various tools — and how they might use the tools — to fine tune your messages to the channel.

What other tools should be in the basic toolbox?

Comments are closed.