March 1: Restructuring Information

We met in order to reorganize our project and the way in which we want to present the information. First, we decided to break the project up into two distinct sections: the initial overview and the application modules. In the initial overview, we wanted to present general principles of the internet, independent of any specific application. In the second half of the project, we wanted to have four separate modules, one for e-mail, one for the World Wide Web, one for newsgroups, and one for ISPs. Each module would discuss how the principles in the first section worked in the context of that application, what was the same, and what was different.

Our one concern with this approach was how to make the first section stimulating to the students. We discussed the use of various analogies, such as the post office, and finally decided that we could use one of the applications as our main example. As e-mail is perhaps the most straightforward, we decided that the initial section on general internet principles will be explained in the context of e-mail (with all of the analogies we discussed). The second half will have a brief summary module of e-mail, and separate modules for the web and newsgroups, explaining how they function similarly to and differently from e-mail, and a separate module for ISPs, explaining what they are and what role they play in electronic communication.

The next question we considered was how to unify the various modules and make them interesting to the students. Since Classical is a magnet school, over 90 percent of the students are college-bound. We decided to use this near-universal as the main premise of our software: students will send e-mail to the admissions officer of a college, for example, and in the process learn how it gets delivered, or access the web page of a university to find a specific piece of information about that university. In the process of finding that information via the web, the student will learn what the web is and how the web page in question is (or how web pages in general are) accessed.

The college idea also adds inherent interactivity to the software: students will send a mock e-mail and get a mock reply. If they send it incorrectly (for example, use an incorrect username or misspell a suffix), they will get an error message explaining what they did wrong. At the end, if the student has gone through the entire tour rather than just skipping around, he/she will get a congratulatory notice saying that the university has noticed that the student is really doing his/her homework and working hard to learn about the university and a good word will be put in to the admissions committee.

On a final note about interactivity: we are committed to making the software as interactive as possible, and are working to come up with ideas. We will also ask Adam for suggestions at our next meeting, as he has more experience with graphics than we do and has already volunteered his skills. One idea we're excited about is showing packets move across the net using animated graphics. When students click to send the mock e-mail, for example, the message will break into puzzle pieces to symbolize packets, and move across the screen.

The college idea led to a long discussion about whether to use Brown University or a mock college of our making. There are several class issues surrounding the use of Brown, but we ultimately decided to go with Brown anyway because a fake college would make the premise seem too cheesy. Everyone at Classical knows about Brown; this adds a feeling of realism to our work. Additionally, using Brown means that we already have a lot of resources (admissions officer names, info about the school, a school web page) at our disposal rather than having to create them all from scratch. We were initially planning to have the final congratulations page include an acceptance letter from the university, but making it a "We'll put in a good word." letter made us feel more comfortable with the idea of using a real university.

Next, we discussed how technical we should make our explanations. Most, though not all, Classical students have used e-mail, the web, and newsgroups, and some have a greater understanding of the premises. We want to find a balance such that we do not go over the heads of the beginners in the class and simultaneously do not insult the intelligence of the more advanced students. It is important to us to err, if error must occur, on the side of explaining too much rather than too little. In order to get a sense of how our explanations will be perceived by the students, we decided to try to arrange meetings with a cross-section of students when we meet with Adam to get a sense of what they know, what interests them, and what they want to know, about Internet technology.

Finally, we thought about the practicalities of building the browse and search mode. After much deliberation, we decided to integrate them into one FIND IT! mode, which will have entries for each word we use that we feel needs definition. Each page will have a button on the toolbar which links to a FIND IT! page, at the top of which will be a link for each letter of the alphabet. Clicking on that link will bring the user to the first defined word starting with that letter of the alphabet, and the user will be able to scroll to find the word he/she is seeking. A given entry will have the word in question on the left. On the top right of each entry will be a definition of the word, underneath which will be a list of links to pages which describe or use that word. Each entry will also link back to the home page and to the top of the FIND IT! page.


Back to the main project page