Washburn Law School Web Development: A Developmental Process


Lloyd Herrera, Washburn Law School


At Washburn Law School we have been running our legal information services web site, WASHLAW for a little more than three and a half years. With the explosion of web sites on the Internet, we decided to develop an additional law school web site. This new site at Washburn highlights selected features of the Law School and Law Library.

The growth of web servers on the Internet has been nothing short of astonishing. Matthew Gray of net.Genesis Corporation (http://www.netgen.com/info/growth.html) compiles growth information on web server statistics and his research shows that in June of 1993, there were 130 web sites, 1.5% of those being commercial web sites, which works out to be 13,000 computers to every one web site; by June 1995 (latest figures available) the number of web sites had grown to 23,500, 31.3% being commercial sites with the ratio of computers to web sites now at a remarkable 270 to 1! There is no question the web services have become the primary form of information delimitation on the Internet.

In the development of our site, the first task was to decide our target audience. Our target audience primarily will be those students interested in attending Washburn Law School. Our secondary targets will be the students already attending. The third targets are our alums and individuals that can provide support and services to our school (donors and legal firms that recruit from Law Schools). The decision concerning how we would deliver the information lead to some spirited discussions among the web development team. Since web services are now the most accessed form on the Internet, the next statistics to look at are which web browsers are most prevalent. The table below ranks' web browsers according to YAHOO usage statistics http://www.cen.uiuc.edu/~ejk/bryl.html:

BROWSERS HOSTS %
1. Netscape 46468 75.9
2. Mosaic 7985 13.0
3. Other 3650 6.0
4. Lynx 3092 5.1

Our discussions initially centered around which browser to support. Developing the web for use by Netscape browsers and their extensions would run the risk of losing individuals with other browsers particularly Lynx (text only browser). Knowing your mission goals will help answer this question. Our audience will be potential students and we want to reach as many as possible. We also need to consider that we want our site to attract viewers; therefore we need to design it to be graphical in order to entice the viewer. With these considerations in mind, we decided that we would develop the site with Netscape enhancements in mind but use version 1.2 enhancements. We can therefore cater to Netscape browsers (ver 1.2 or higher) and yet have the capability to serve other graphical browsers (background, various color commands and other enhancements will be ignored by browsers not capable of utilizing them). We incorporated ALT tags (ALT tags will display a message to text viewers that cannot load graphics) so that Lynx viewers can use our site (later versions of Lynx ver. 2.4.2, show the links inside a table though not the table itself). I must admit that at first we looked into having two separate versions. One graphical and the other text based but as the development progressed, we realized that two separate web sites would be physically challenging to say the least. Rule of thumb would be to go with the largest common denominator but if you can make minor changes to increase viewership, the more the merrier.

Developing a graphical interface spawned spirited debate among our development team. In the past, we developed web sites with limited graphics (buttons mainly). WashLaw is a legal resource service and in that context the need for speed is paramount. A user prefers a rapid delimitation of information and since we link to other sites, (we have no control as to the content or speed of their site), we felt that WashLaw should not add to the responsiveness bottleneck. Our law school web on the other hand, is intended to be a recruiting and information source. With that in mind, we plunged headlong into building a graphically intensive site. With our limited knowledge of graphical interfacing, we immersed ourselves into the project. Martin Wisneski, Head of Technical Services, developed much of the look for the law school site. It is a fine line to walk between graphics and text only. We looked at other sites and realized that the sites that incorporated graphics were visually more appealing as opposed to sites that had little or no graphics and used a structured list link layout.

Since we agreed to use a graphically enhanced site, we next looked at the image loading issue. We standardized on JPEG files (Joint Photographic Experts Group) preferably less than 20k. Large compression ratios are capable with JPEG files. There are a few older browsers that do not support inlined JPEG images, most notable Mosaic 1.X: the image can be viewed with the aid of an external viewer. We also used width and height information in loading our images. By transmitting the width and height information in the anchor reference to an inline graphic, the browser can instantly create a bounding box for the graphic without needing to examine the whole graphic to determine size information.

We developed our first page with minimal content (a link to the main menu and a mailto: menu), its main function is to ensure rapid connection delivery (less than 10 seconds) so that we can hook the viewer. Remember that yours is only one of thousands of sites -- websurfers have short attention spans. To increase system responsiveness we decided that no page should take longer than 20 seconds to load. We tested responsiveness on my home system (386/25 with 14.4k modem, if your system is less than that you have my condolences). Most studies on user response to computing system delays suggest that waiting times longer than about 20 seconds are intolerable in routine, repetitive computing tasks (Horton, 1994; Schneiderman, 1992).

A major development consideration is page design. We used a 640 x 480 on a 14" monitor as our screen size standard, settling on a 545 pixel horizontal display area. Anything more will make the title banner or other inlined graphics too wide to fit within the default window size of the browser. The document length standard was set to two to three 640 x 480 screens worth of information with local page links at the beginning and end of the page (we link to our home page, previous page and next page). One major disadvantage of very long WWW pages is that the user must depend on the vertical scroll bar to navigate. Very long pages have the undesired effect that small movements of the scroll bar can completely change the contents of the screen, leaving no familiar landmarks to orient by. This gives the user no choice but to crawl downward with the scroll bar arrows, or risk missing sections of the page. Additionally, a user may become disoriented when the basic navigational guides, such as linkages to other local pages disappear off-screen as the user moves through very long pages. If you take into account users with character-based terminals, they don't generally read more than a few screens. They often only absorb what is on the first screen; if that is not interesting, they won't be bothered to scroll down. We split our long document pages into multi-part documents, indexing the pages to aid navigation. As an added benefit of the indexing scheme we found that our document editing became simpler. Finding a section to edit is much easier in a shorter document and is less strain on the eyes.

Another developmental concern is layout style standardization. We wanted our site to have a homogeneous look to it. A carefully organized design grid that is consistently implemented across a range of pages will aid users in quickly finding the information they want, and will increase the reader's confidence that they are using a thoughtfully organized collection of information. We want to have continuity but we do not want to stifle the creativity of our writers. Therefore we developed a house style sheet that will contain information on our choice of color backgrounds, buttons, footers and images we will use. We incorporated the footer style recommended by the Web Style Manual from the Yale Center for Advanced Instructional Media. In our footer section we display the author's name (imbedding a mailto: link), copyright marks, copyright year, last revision date of the page and the URL for the page the browser is viewing (I was shocked to find out that there are viewers that do not display the URL!). The style sheet will be mounted on the web for all to view.

Now that we had a general outline of our web, we developed a rough draft of the site with two or three levels of content as our initial demonstration. We first presented the initial design to our web experts, the librarians that worked on WashLaw, for their opinions. We wanted input from the administrative personnel at the school as to content and design implementation. The presentation gave use useful web technique recommendations that we implemented. We then had several developmental meetings where the administrative staff along with the development team discussed the progress of the site. We used these meetings as a sounding board for content and visual development. This would give the individuals with limited knowledge of webs a reference point from which to start. We incorporated the suggestions of our first meeting into the site, presenting the revised web at our next meeting. After incorporating the recommendations from the second meeting, we had a final presentation meeting where we demonstrated the completed site. This structure generated consensus for our house style and gave individuals an understanding of web development concepts, preparing them for their publishing responsibilities.

Of concern to us is how to develop writers who are initially unfamiliar with webs. Graphic, Visualization, & Usability Centers 3rd WWW User Survey (conducted June 1995), gave us some peace of mind in that regard. The survey revealed that most users (82.0%) spent between 1 and 6 hours learning HTML. Many users learned HTML in only 1 to 3 hours (55.2%). CGI was rated the most difficult (5.0) followed by FORMS (4.0), ISMAP (3.9), and HTML overall (2.5). Interestingly, none of these averages are near the maximum difficulty rating of 9.0. Additionally, the survey looked at how people learned to write HTML. On-line documentation was consulted by 88.4% of users in learning HTML. The next two most popular sources, books and friends, were consulted by only 29.2% and 25.2% of users, respectively. We are currently investigating HTML writing tools to find the best one suited to our needs. I am most familiar with HTML ASSISTANT while other members of the development team have used HOT METAL. Using one of these WINDOWS based programs will generate the HTML and store it locally on their hard drives. It will then just be a matter of using an FTP client program to load the HTML to our RS/6000. An added bonus will be that we will have the web site stored on several computers for backup needs (a master copy will be maintained by the backup mechanism of the RS/6000 and I have prepared a nightly backup of the web site for added protection).

Now that the law school web site is ready for use, I will alter my role in the development process to that of technical advisor, overseeing the technical aspects (style layouts, new web development techniques and maintenance and troubleshooting of the site). This site will showcase the talents of all of our members of this school, giving the site greater creative diversity than any one person could develop. With this thought in mind, I would like to see students get involved in this project. It would be interesting to see their freshness and vitality infuse our site and it would also infuse our site with an appeal complementing our stated target audience.

I see web development as an outgrowth of desktop publishing, an electronic magazine with a potential readership in the millions. It is a fantastic information dissemination device which has just begun to be explored and its role in our society is yet to be foretold. We are at the beginning of revolution, and we are swept up in its fervor with no end in sight but its potential is giving the revolution its blood. Momentous times indeed.

Explore our new Washburn School of Law Web Site at: http://lawlib.wuacc.edu/washburn/school.law/welcome.html

I sincerely hope you enjoy and if you have any suggestions or comments, please feel free to e-mail me at zzherr@acc.wuacc.edu.

*Lloyd Herrera has worked at Washburn University school of Law as the Computer Services Technician for two and a half years. Lloyd has participated in all aspects of web development, from the initial design of the law library web server to publishing StateLaw; a nationally recognized state government information site. StateLaw URL is: http://lawlib.wuacc.edu/washlaw/uslaw/statelaw.html

Literature Cited:
Horton, W. K., Designing and Writing Online Documentation, 2nd ed. (New York: Wiley. 1994.)
Schneiderman, B. Designing the User Interface, 2nd ed. (Reading, Mass.: Addison D Wesley 1992).
Patrick J. Lynch, Web Style Manual (Yale Center for Advanced Instructional Media, 1995) (http://info.med.yale.edu/caim/StyleManual_Top.HTML)
Graphic, Visualization, & Usability Centers 3rd WWW User Survey.


Previous Article
Return to Automatome Table of Contents
Next Article


Created by lawlib@lclark.edu
Updated: 17-Apr-96
Expires: 1-Jan-97