182
Building a Large, Successful Web Site on a Shoestring: A Decade of Progress
Theodore W. Frick
Bude Su
Yun-Jo An
Indiana University Bloomington
Abstract
How did we build a site that has grown to more than 6,000 Web pages and 50 million hits per year – with a
few part-time people, with no budget for the first five years, and a minimal budget the next five? We will describe
an efficient and effective design process fundamental to our strategy that is essentially a method of disciplined
inquiry. Our own XML content management system perpetuates our Website into the future as Web browsers,
HTML, CSS, and editors continue to evolve.
Current School of Education Site at Indiana University
In May, 1994, the first Website for the School of Education at Indiana University Bloomington was
launched. The home page had two links – one to our Instructional Systems Technology Department, and the other
to the IUB home page.
Now our site ( http://education.indiana.edu ) consists of more than 6,000 Web pages, and we have received
more than 120 million hits in the last two and a half years. Our Website is highly ranked in Google searches. For
example, searching for the terms, ‘school of education’, in Google has consistently ranked our home page in the top
five out of about 12 million pages that contain the words ‘school’ and/or ‘education’ – i.e.,
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=school+of+education .
How did we make this kind of progress in the past decade with a few part-time people, with no budget for
the first five years, and a minimal budget the next five? We will describe an efficient and effective design process
fundamental to our strategy that is essentially a method of disciplined inquiry. Our own XML content management
system perpetuates our Website into the future as browsers, HTML, CSS, and editors continue to evolve.
Practical Web Design: An Inquiry-Based Process
Boling and Frick (1999-2004) have developed and refined and effective and efficient process for Web
development ( http://www.indiana.edu/~pedagogy/preview ). The process itself is inquiry-based.
Analyze Your Needs and Those of the Users
We typically conduct a needs assessment by using multiple sources of information. We often interview key
stakeholders in the School of Education, which include current students, faculty, staff, and administrators. We also
interview members of our target audiences, or gain information about their needs through our “gatekeepers”. The
primary target audiences we try to serve on our Website are prospective students (both undergraduate and graduate),
current students, faculty, staff and associate instructors, and our alumni. Our secondary target audience is K-12
teachers. Results from these interviews help us to form goals for our Website. We also interview “gatekeepers” in
the School – the people who often interact with prospective and current students, their parents, and other members
of the public. We ask the gatekeepers to list the most frequently asked questions they have received over the past
year, who asks the questions, when, how (phone, e-mail, walk-in), and what the answers are. Examples of
frequently asked questions: “When can I take the Praxis I exam?” (from students who want to get admitted into our
teacher education program); “What programs do you have?” (from prospective students); “Can you graduate in
four years?” (from parents of undergraduate students); “What are the prospects of getting a job when finished with a
degree?” (from students and parents). Finally, we look at Web statistics to see which of our existing Web pages are
receiving a lot of traffic. For example, we know that the most frequently accessed Web page link on our home page
is to “Academic Programs and Departments” and that our search engine is used next most frequently. We also get a
very large number of hits on our K-12 resources pages, such as lesson plans for teachers, classroom management
styles, for teens only, resources for teaching reading and social studies.
Next we sort through the data we have gathered. Often we put items on index cards. Then we do a card
sort, usually by inviting some people we grab from the hallways (i.e., students or staff who are interested and have
some free time) to rapidly group cards together with common themes. We label the piles of cards and put rubber
183
bands around them, and in turn start grouping the piles, until we get the number of piles of piles down to 10 or less.
This is effectively creating the information architecture for the Website, or for a subsite within the overall site, such
as an academic program area.
Who is the “we” here? Sometimes it is just the Web Director (first author) and graduate assistants. Many
times in the past it has been student design teams we have formed in appropriate courses in Instructional Systems
Technology (IST). This is a good learning experience for our IST graduate students, and it is very inexpensive –
usually just the cost of supplies and materials, such as index cards and computer printing.
Paper Prototyping and Usability Testing
Next the design team creates a set of paper pages, called a rapid paper prototype, containing a sample of the
content and structure we are proposing for the site. The content structure is based on the information architecture
we derived from the needs assessment. The paper prototype is typically put into a 3-ring notebook. We write
numbers next to the hyperlinks (underlined text), and then we have tabbed pages with numbers on them, so that we
can simulate Web browsing. We then conduct usability tests of the paper prototype by selecting members of the
target audience. Usually we need to only select 4-6 members of each appropriate group. We then observe these
people who try to use the paper prototype to answer frequently asked questions that we identified in the needs
assessment. We ask them to think aloud, and we record the paths they take and whether they find the information or
not (or where they would look for it if it were in the prototype). We occasionally alter the prototype – sometimes on
the spot – and continue to test it until we have identified major problems with the design of the information
architecture. If the problems are severe, we attempt to redesign the paper prototype and conduct another round of
usability tests. Otherwise, we fix the problems and incorporate the design solutions in our computer prototype,
which is the next phase.
Computer Prototyping and Usability Testing
We do rapid computer prototyping next so that we can conduct further usability tests. Now we need to
attend to some of the Web elements such as how users will navigate the site, banner graphics (or approximations),
page layouts, occasional images, etc. At this point, we are not trying to make the design completely finished but to
get enough of it working on the Web so that we can try it with users. In the past five years, we have made this
process fairly easy by creating new design templates and by using our EdWeb tools (described below) to build or re-
build a Website with the page content stored in XML files. We then publish those pages on a temporary computer
account that we use for testing. The temporary site has no public hyperlinks to it, so the rest of the world does not
know it exists (nor can it be indexed by search engines, since nothing on the Web links to it). The rapid computer
prototype often has links in it that go to other existing Websites at our university or within the School of Education.
We then select a new group of 4-6 users who are representative of each relevant target audience, and we
conduct usability tests in a similar fashion as described above for paper prototype testing. Users are asked to think
aloud, and we record their paths for browsing (and also how they use the search engine). We use these data to
identify further problems with the design, including navigation issues. If the problems are still severe or numerous,
we will make changes and conduct a new round of usability tests with the modified computer prototype with
completely new users. When satisfied that we have fixed the big problems with the design – based on our usability
findings – then we move on to the final production of the site.
Building the Web Site
At this point we need to pay attention to numerous details for Web publishing which naïve developers think
of as Web design – i.e., getting final versions of graphics produced so that they look good and load quickly, creating
and debugging style sheets (CSS), making sure HTML or XHTML is valid, making each Web page “look good” in
terms of layout, use of white space, inclusion of graphics, etc. We also need to test to make sure our hyperlinks are
working correctly. Normally we do this in our temporary Web account, so the public is unaware of the new site.
As we are building and testing the site, we ask key stakeholders to take a look at it, such as our Dean,
department chairs, and others in the School of Education. Based on their feedback and comments we tweak the site
further.
Finally, when we are ready to go “live”, we copy the XML files to the actual production site. We update
our production versions of design templates (a combination of PHP and XHTML), and then we use our EdWeb
Tools, described below, to publish the Website. If it is a completely new Website, then we need to add hyperlinks
on other existing Web pages on the School’s site and also notify other sites of the new site. If it is a revision,
usually little external change is required since we make every attempt to keep file names the same so that we do not
184
break external hyperlinks to the site or parts of it. We also ask our university Webmaster to direct the university
search engine to index the new site (or re-index it).
Then we announce the new Website in ways that are appropriate to the occasion. If the site is brand new, it
also needs to be registered in places such as Yahoo and Google.
The “we” here is the Web Director and assistants (authors).
Maintaining the Site
Every Website is like a new child. Someone needs to watch over it and help it grow and change. This is
usually where we bring in the content management person in the School of Education who will be responsible for
this. Basically, we train this person (often a staff member or graduate assistant in department or office) to use our
EdWeb Tools, so that she or he can update the content as it changes in her or his area of responsibility. Our
philosophy is to have people closest to the content do the management of it. They know when something changes
and the Website needs to be fixed to reflect those changes. These people do not need to have special Web design
skills. Usually someone who is experienced with e-mail and word processing can learn to use our EdWeb Tools and
a WYSIWYG editor such as FrontPage or Dreamweaver. They focus on the content, since we have provided them
with a working information architecture derived from our needs assessment and a design and navigation system that
has been evaluated with members of the target audience through usability testing.
EdWeb Tools for Content Management
The EdWeb Page Maker tools were written in PHP (acronym for PHP Hypertext Preprocessor) in 2001.
PHP is a server-side scripting language that works within HTML documents to enable generating dynamic Web
pages on demand. Although there are several other options such as Cold Fusion, Java, and Perl, we chose to use
PHP for two reasons. First, PHP is free. It was open source and we could find examples out there to modify and
adapt into own programs. Second, PHP is a combination of simplicity and robustness. For example, programmers
can use a few simple lines in PHP to retrieve or store data in a database.
In the School of Education, the content of each Web page is stored in XML format on a secure Web server.
The EdWeb Page Maker tools combine the XML content with the appropriate local design template to publish a
static HTML Web page for world to see. The School of Education is a complex organization with many program
areas and offices. Each unit needs to have customized navigation on their Web pages while maintaining a consistent
design with the overall School of Education Web site. In order to meet such a need, we designed a Web page
template for each unit with unique navigation sidebar and footer information (See image 3.1 below). Such a locally
tailored template can provide an effective and efficient way of managing the Web pages within that account. The
content providers in each unit manage (edit) the main body section of the Web pages. They can create a new Web
page or modify the content of an existing Web page. Whenever there is a change in the template, the Web Director
at the School level will make the change and use the EdWeb Page Maker tool to re-publish all the Web pages with
the new appearance. Once the templates are changed, republishing takes only a few seconds on the live Website
(analogous to remodeling a jet airplane while in flight).
185
3.1: Three main sections of a Web page
The EdWeb Page Maker tool is easy to use. Any person who is familiar with word processing software
such as the Microsoft Word or WordPerfect can use the EdWeb Page Maker tools with minimum training. The
process of how this tool works is listed below:
1. Launch Netscape or Internet Explorer.
2. Click in the location window, and type the URL of the EdWeb Page Maker tool.
3. The first screen appears as below (See image 3.2):
186
3.2: The first screen of the EdWeb Page Maker tool
4. Click on the XML file that you are going to update in the second column. If your XML file is in a
subdirectory, first click on the subdirectory name in the first column, and then select the XML file. If you
need to upload a file, make a new XML file, or make a new directory, you can do so in the third column.
5. If you are updating an existing file, the EdWeb Page Maker tool will open the file and you should see a
page that looks like this (see image 3.3):
187
3.3: Opens in the editing mode
(Note: if you are creating a new file, the text input boxes above will be blank.)
6. Modify fields of the EdWeb Page Maker Web form (see image 3.4).
188
3.4: Editing a Web page
7. Click the "Write XML file and preview" button at the bottom of the form. You will then see how your
Web page will look when combined with the template for your department or office (see image 3.5).
189
3.5: Previewing the Web page
8. If the "preview" page looks OK, then click the button at the bottom of that page, and you will publish
your Web page for the world to see! (see image 3.6)
190
3.6: Publishing the Web page
We have similar tools in the School of Education for updating faculty and staff profiles, for maintaining
course catalog and syllabi, and for hiding online e-mail addresses of individuals to reduce potential harvesting and
resultant spam messages.
In conclusion, the main purpose of using these EdWeb tools is two-fold. First is to centrally control the
overall appearance of the Web pages so that all the Web pages within the School of Education can have a fairly
consistent look. Second is to decentralize the content management to the local unit and even to individuals due to
the fact that they are the people who know what information their Web pages should contain. Of course, such a
decentralized approach requires certain amount of training for the content manager in each unit. It is usually a one-
time training session of 1-2 hours in the beginning. Typically each unit has one or two persons to take care of their
Website (which we consider to be a subsite of the overall School of Education Website). Since the Website
management in the local unit level does not require a lot of time, the local Web content manager often has other
duties, e.g., as a secretary or graduate assistant. More information on the EdWeb tools is available at:
http://education.indiana.edu/guide/guide.html .
General Strategy for School of Education Web Development
In summary, the general strategies of maintaining over 6,000 Web pages with three part-time Web
managers are to:
• Use an inquiry-based approach to design (user needs assessment, rapid prototyping, and usability
testing during design and development – which are often graduate student projects in IST courses).
• Keep content in XML format, separate from its appearance on the Web.
• Have Web managers at the school level design HTML templates and EdWeb Tools in PHP, so that
content providers focus on content.
• Let those closest to the content maintain and update it.
191
Reference
Boling, E. & Frick, T. (1999-2004) Practical Web Development: A Systematic Process. How to Make Useful and
Usable World Wide Web Sites. Bloomington, IN: book manuscript in process. See
http://education.indiana.edu/~pedagogy/preview/
