Getting Started: The Nature of Websites, and What You Will Need to Create Yours
Thinking About Your Website’s Genre and Features
ewcomers to the web (as well as many old-timers) are often tempted to focus, sometimes obsessively, on the technology. After all, technology is what most obviously distinguishes the web from our former primary realm of expression—paper—and despite our best efforts, we could not get through even the introduction to this chapter without delving into several technical computer terms. Individuals who are used to the world of books and journals often find themselves overwhelmed by the web’s technological otherness, and its myriad terms and concepts—HTML, servers, design and graphics software, and a host of other acronyms like FTP and ISP.
After more than a decade of experience with web production, we feel that this temptation to focus primarily on technology is misplaced. Not only can it be daunting, it can be distracting. If you were thinking about building a house, how much time would you spend concentrating on the type of plumbing you would like to use or the amperage of the electrical service? How long would you spend thinking about the types of wrenches you would use to install the hot water heater? These elements are important—indeed, critical to the construction of a modern house (especially the indoor plumbing)—but few would say that they define a house and make it what it is.
Although both are honorable professions, we encourage historians to think of themselves more like architects than plumbers. What kind of house are you building? What is the general area that it will be in? How will its design reflect or differ from the other houses in the neighborhood? Are you building a mansion or a cabin? In the same way that you would plan a book with a clear sense of purpose, content, and audience—is it a reference work, a monograph for specialists, a popular introduction to a subject?—you should ask yourself some preliminary questions about the genre and scale of the website you are planning to build, and about the key features it will have. These sorts of questions are very different from technical questions such as, “What kind of server should I put my site on–Windows or Linux?” or “Which software is better for website development–Dreamweaver or FrontPage?” or “Which is a better database–Oracle or MySQL?” These questions should be secondary, not primary. For instance, if you are just posting a syllabus to a website, you don’t even need to use a dedicated web development software program like Dreamweaver. Microsoft Word may be just fine.4 The answers to the primary questions lead to answers to many of the secondary, technological questions, such as whether you need a database at all.
In the spirit of beginning with first principles, we might also pose a question you should answer even before thinking about your website’s genre and features: Do you really need to spend the time to build a website at all? Although this book is a guide to the History Web, and we believe that the web has many virtues to recommend it (as we noted in the introduction), not all historical endeavors require a website. Some historical projects would be better off remaining on paper or in personal computer files, such as research notes that you don’t want exposed to the world. Compared to graphically sophisticated productions such as a full-color, large-format art history book, the web still pales. Other projects might function better by using nonweb computer technologies, such as email. Email remains the most frequently used application on the Internet, and historians should not be embarrassed to stick with that simpler method. Ongoing communications about a historical subject, such as the Sixties-L discussion group (on the turbulent 1960s) or the wide variety of H-Net topics, are often carried out better via email.5 Soberly assessing the web’s advantages and disadvantages and how they apply to your project will mean a clear-eyed entry into the digital world.
If you still desire a website, you should then consider what you will need to build it. Again, focusing on the genre of website you plan to build will help you answer secondary questions such as technological requirements. Begin by investigating other websites on your topic, and websites that have a similar mission to yours. For instance, if you are planning a website on the American photographer Weegee, look at other sites on the man and his images, and other historical photography websites. Do you envision a site that functions like a large gallery of Weegee’s photographs that visitors can wander virtually through (an “exhibit” as we categorized it in Chapter 1), or a site that is more like an online essay, with a smaller set of images chosen to illustrate a scholarly thesis?
Furthermore, assess what you like and dislike about the comparable sites you visit. How will your site differ from them, in scale, features, or content? Contact the creators of the best sites to ask them about their site-building experience. Did they have unforeseen problems that they could help you avoid? Did they discover some shortcuts to getting this kind of material onto the web? Which technologies or assistance did they find most useful—a good scanner, a web design company, a server host? If you can roughly match your website’s ambitions to an existing site—allowing for Chapter 1’s caveat that sites are hard to categorize and compare perfectly—you will begin to understand what you will need for your own creation.
Focus next on the features that will distinguish your site. What do you want, and what will you need? For a site on the Alhambra, you may want an interactive “zoomable” map that visitors can click on to explore different areas; to serve a diverse audience, including many nonspecialists, you may need a glossary of Arabic terms. Once you have a list of features, arrange them in order of priority. Which features do you absolutely need to launch the site to the public? Which features could wait? Perhaps some could be implemented later—or not at all if you run out of time or resources. Inherent in this analysis, of course, is some sense of how much effort (including technological complexity, staffing, cost, and time) each feature will require, to which we now turn.