The order presented is the most natural order to cover chapters. However, there are many possibilities to omit or reorder the coverage of chapters. The strongest (solid lines) and weakest (dotted lines) dependencies among chapters are shown in the following precedence diagram (also available as a PDF file for printing):
The book was developed in the context of a semester course with 45 contact hours total. It is not advisable to try and cover the entire book in this format, especially if any of the supplementary materials (mentioned later) are used. I have skipped parts of the book, depending on the level (undergraduate or masters) and the interests of the students.
There are four major topics in the book: applications, organizational and business issues, acquiring applications, and infrastructure. A given course can easily deemphasize one or two of these. Specific suggestions:
I have used the book in a masters level class in information systems. In this case, I skipped Chapters 7 and 8, because they are adequately covered in another course I offer. I added much of the supplementary material mentioned below. I also used it in an undergraduate service course, where I skipped Chapters 7, 8, 9, 10, 17, and 19, as well as advanced sections in a few other chapters. Skipping these chapters altogether left room to cover the remaining material more slowly and carefully. In a course for MBA students, I skipped Chapters 10, 17 and 19, and also covered the remaining infrastructure topics more superficially. This allowed us to spend more time (particularly in a discussion format) on the business and organizational issues.
The chapters are ordered in a top-down fashion, where the students are given the "big picture" first, and then details are gradually filled in. While I find this technique effective, especially for students without much prior background, it does require discipline on the part of the instructor. There is always the temptation to "drill down" when covering aspects of the big picture. I find this dropping this discipline problematic, because it often loses the students with the least background, and also temporarily disconnects the class from the text. On the other hand, some students express impatience with this top-down approach, requesting additional details on topics as they are covered. This is particularly true of students with more background, who are more aware of what is not being said. An effective way to deflect these requests is to frequently present "road maps", laying out for students what details they can expect to learn about a particular topic later, and why it is being deferred.
It is also possible to "unwind" the top-down approach to some extent by reordering chapters. For example, Chapter 18 and 20 can be covered immediately after Chapter 12, giving a pretty complete picture on both what networks do and how they work, all at once. Other chapters that can easily be moved earlier are Chapters 4, 9, 15, and 16. However, in my judgment the text ordering is the best, and it has proven effective in the classroom.
Available here are a number of supplementary writeups. They can be assigned as Web reading, or printed out and reproduced for the students. I have found them useful for two purposes:
In particular, I have used many of these writeups in my masters-level information systems class, but I skipped them entirely in my undergraduate and MBA classes.
It would be an excellent idea to supplement the text with hands-on laboratory experience with using networked applications, or even developing new networked applications.
In my classes I have tried to integrate as many social and information access applications as possible into the functioning of the class. I assign readings on the Web, and also assign "explorations" where students are asked to find more information on particular topics. I have also used a discussion forum application to supplement the class (I used Delphi, which allows anyone to set up a private discussion forum). On the forum, I post questions (particularly of a controversial nature) weekly, and ask the students to discuss them.
I have not yet assigned more weighty laboratory experiences, such as installing and configuring networked applications or even developing new ones (based on tools such as JavaScript). This is not because I don't think it is a good idea, but because I haven't had the time. If any instructors develop things like this, please consider sharing them with the rest of us.
I have found projects to be a useful adjunct to the homework assignments. In fact, in more advanced classes they are in many ways more valuable. I have tried three types of projects with success:
In all these cases, I have made the project groups (with 3-5 members) as heterogeneous as possible, so that students can attack more ambitious tasks and learn from one another. I do this by asking the students at the beginning to divulge a bit about their relevant background, and I then assign the project groups.
For specific project examples, see the project page.