Jerry Lawson is a lawyer and author of The Complete Internet Handbook for Lawyers (ABA LPMS 1999). Mr. Lawson operates the Internet Tools for Lawyers Web site.
Brenda Howard is the owner of CreativeWriting.com, LLC, a Web design firm in the Metro DC area. Ms. Howard is also a Corporate Software Trainer specializing in the Internet.
Dennis Kennedy is a lawyer in the Intellectual Property and Information Technology Department of Thompson Coburn, LLP in St. Louis. Many of his articles on Internet and technology topics may be found at his web site.
Link to LLRX.com Marketing Resource Center for previous issues of the Internet RoundTable
SIDEBAR
Becoming an Effective E-Lawyer,” LaVern Pritchard
“Getting Started with ASP,” Akshay Luther
Guide to Cascading Style Sheets
“Why XML Matters,” Ben Gottesman
Designing Web Usability, Jakob Nielsen
Choosing a Database for Your Web Site, John Ashenfelter
Dennis Kennedy (DK): I’ve always felt that what distinguishes a great web site from an ordinary web site is that the owners of the great sites treat the sites as if they really matter to them. On a great site, you get a sense of passion, involvement and commitment. On the ordinary site, you get a sense of half-heartedness, obligation and detachment. Since we believe that you want to have a great site, it’s important to think about how you set up a site so that it can grow and evolve. Obviously, it will cost more to revamp or reprogram your site completely each time you have a new idea. How can you build a great platform or foundation for your site? How can you evaluate wisely the technologies that are now available? Will spending a bit more money now save you money in the future?
Brenda Howard (BH): Dennis, this is an excellent topic because I often have clients that come to me with an existing site that is costly to maintain. While it may have been inexpensive to create, it’s a monster to update. In a recent example, a client had to make their site handicap accessible. Since the site was originally created without any site management tools or templates, we had to make changes to every single page in order to meet the accessibility requirements. If a template had been used, we could have make modifications to the master template and it would have updated all the other pages automatically. This original design decisions cost the client more money down the road. Jerry, what do you think is at the top of the list?
Jerry Lawson (JL): The single most important technical thing that will help save future headaches is probably avoiding proprietary technologies. For example, stay away from “Active X.” This is a label used to describe a variety of Microsoft-specific methods for making web sites interactive. It’s already incompatible with many Internet users, and alternatives are on the horizon that may make proprietary Microsoft technologies even less attractive in the future.
BH: Proprietary technology is a definite warning sign. I don’t use Microsoft’s Active X components, but I do use ASP (Active Server Pages). Active X components are files created by Microsoft and Active Server Pages is a scripting language where you write your own scripts. Both technologies are Microsoft driven, but one can be used easily and the other cannot. Needless to say, research the technology being used before jumping in with both feet. Aside from a specific technology, aren’t there simpler decisions that will decrease the maintenance cost for a site?
DK: A number of decisions can make your life easier as your site grows. While easier does not always mean less expensive, in most instances it does. From setting up logical directory structures to using standard templates to choice of technology tools, there are ways to standardize your procedures and make it easier for a new person to come in and maintain your site or re-design it. Putting some time into setting up a logical file structure and establishing standard page templates is an inexpensive approach that will pay off greatly later. Although many people think of Microsoft FrontPage as a web design tool only, it’s real value, in my opinion, is the way it helps you manage and structure your web site. Would you agree, Jerry?
JL: FrontPage’s site management features are extremely useful, though I wouldn’t underestimate the time FrontPage helps save on individual page layout. Unless you have an extremely low-ambition site, I recommend avoiding the standard templates (“themes”), however. In the later versions of FrontPage, it’s not that hard to make your own themes.
BH: Unfortunately, the FrontPage themes have been used quite a bit by many sites out on the Web. FrontPage does an excellent job of allowing a person to create a highly customizable, yet efficient site. Most clients that create or edit their sites in FrontPage, do not fully utilize the tool by creating a “web” within FrontPage. They simple use it as an HTML editor. If one is going to use FrontPage as a site management tool, I highly recommend attending at least one class for learning to fully utilize the software.
JL: Dennis mentioned the importance of a logical site structure, and I’d like to underline this. Keep it in mind from the very beginning. Many designers start out putting all their files into the root directory of their web site. This is one of the surest marks of an amateur. It will become impossible to manage when you have thousands of files in there.
Give yourself space to grow. Avoid changing your directory structure and file names, because this will cause links that have been built to particular files to go bad. Smart site operators expend considerable energy to encourage the deployment of pinpoint links, and deservedly so. Changing your directory structure destroys the value of that effort.
BH: That’s a tough lesson to learn. I had a client change a file name of one of the top-level pages. Needless to say, thousands of links were broken. The proper amount of planning, in the beginning, allows the Webmaster to keep top-level file names and folders names the same throughout the life of a site. Some times this is unavoidable. For example, a law firm may discontinue an area of practice and remove that section of their site. In this case, I suggest that the file remain in place, but the text on the page indicate that the page no longer exists and allows the visitor to go to some other choices. Planning the site architecture and using a Web site management tool are great time savers, but what if you’ve written your code by hand?
DK: Never underestimate the value and time saving of clearly written HTML code. Taking care with the coding, indenting and inserting comments to describe what you’ve done can make a world of difference when you work on a site at a later date.
JL: If you are marking up pages by hand, inserting comments and laying out the markup with indentions and so forth is definitely helpful. On the other hand, I’m not sure adding comments and carefully formatting your code is as important if you are using good WYSIWIG page layout software.
BH: Even using an HTML editor, I like to comment in the code. Sometimes I add scripts, like a newsletter sign up, and I need to clearly see where the code begins and ends – for deleting it in the future. It comes in handy as a site ages and you forget what you did 3 years before with regard to a particular script. It’s really about saving time as a site ages and grows.
DK: As you advance to second and third-generation sites, there is no question that you are talking about moving to a database-driven site. Most of the most popular web sites are database sites. There are a number of approaches to database-driven sites. The general concept is that when someone requests your page, information is pulled from a database into a page template that essentially creates the page the person actually views “on the fly.” Updates are easy because you do not have to update each individual page and you can alter the page template without changing hundreds or thousands of individual pages. We’re talking about a very powerful technique. Brenda, at what point do you start to recommend that people go to a database site?
BH: I recommend a database solution any time there is more than 50 records of information that change continually. An example is an office directory. It’s easy to go in and change a name and phone number for one entry in HTML and upload a new page once every six months. However, when you have 200 attorneys and multiple changes each month, then you need a database with a Web-based administration panel that would allow a data entry person to go in and make changes daily or weekly. This would eliminate calling the Webmaster every time a phone number changed. It costs a little more upfront, but will save many consulting dollars in the long run for editing information that changes continually. Generally, databases would only be required by larger firms.
JL: Databases are the only way to go for sites like Amazon.com that have truly gigantic amounts of information to keep track of and can afford to have expensive teams of professional programmers on staff full time. Database-driven sites also make sense for very low end, assemble-online sites like the free ones that Findlaw,com used to offer before Westlaw bought them out, because someone else is handling the programming and other overhead. However, whether they are good for most law firm sites is another question altogether.
At the risk of sounding untrendy (a cardinal sin in this crowd), I have to flash a major yellow light here. While database development is more complicated, I think it is a major mistake to assume it is also “better.” The power comes at a cost: a great increase in overhead, not just money, but added complexity, increased development time, and more difficult troubleshooting when things go wrong. Sometimes simpler is better.
BH: Jerry, you’ll always be “trendy” in my book, but this isn’t really about being trendy. While I do understand the caution, I’m an advocate of database driven Web sites. It’s okay to hand wash one load of laundry each week. You hire one person and they do the job. However, when that laundry increases to 15 loads a week – it’s time to buy the washing machine – you don’t want to pay the salaries of 15 people.
DK: LaVern Pritchard wrote an excellent article ( http://www.lfmi.com/tech/ELawyering.cfm ) that covered the use of databases for law firm sites. I highly recommend it.
JL: I worked with LaVern on the ALI-ABA video series The Lawyers’ Guide to Using the Internet and I picked his excellent “Lawmoose” site, http://www.lawmoose.com as the “MVP Site of the Month” for June 2001 at Internet Tools for Lawyers, but this article didn’t convince me that databases are right for most law firms. Just because something is trendy, or more “elegant” in a technical sense doesn’t mean it’s the best way to go.
DK: While there are several different ways to do database sites, it’s safe to say that a database approach will take your site out of the “hobby” realm and you probably have to go to a professional web designer for best results. That said, some web hosting services offer simple database sites using Microsoft “Active Server Pages” for $25 a month and will even allow using them in connection with a Microsoft Access database. I’m actually considering this approach for my own site. One concern these days, though, is that ASP sites run on Microsoft’s Internet Information Server and IIS has been plagued with major security problems. Other approaches include Java Server Pages and Open Source options. Pritchard’s article does a good job of listing the alternatives.
JL: You can get the major benefits claimed for database-drive sites (like being able to update thousands of pages at once) through regular HTML pages incorporating simpler techniques, like cascading style sheets and server side includes. I would be glad to hear additional arguments in favor of database-drive sites, but based on my experience and study so far, few law firm sites are better off with database-driven sites.
BH: Egads! Jerry, database-driven functionality is even practical for the smallest law firm, assuming that there’s a need.
Here’s an example. A client has me create the web site and it is in FrontPage, but the client decides that they do not have the time to maintain it – which happens more often than not. This client wants all of their customers to be able to follow the status of their project on a 24/7 basis. (Their customer may be up in the middle of the night worrying about their project.) My client uses an administrative panel to add new entries to each project. The customer uses a log on and password to access the status of the project. My client can see all the entries and the customer is limited to viewing their own project data.
If my client had to pay me every time she needed to add an entry or new customer to the system, then she would be paying me my hourly rate for many hours. Instead, she invested $650.00 and has a database-driven system that she administers through web based control panels. Even at an hourly rate of $40/hour, this system pays for itself in 16.35 hours.
Another client had a calendar of events that changed each month. Again, had decided against learning how to use FrontPage and was having me do all the updates. We created a database driven calendar that allows her to type the dates in herself and have it dynamically published each month. The calendar system paid for itself in 2 months time.
In both of these cases, most of the web site never changes (most of the pages are static), the clients did not want to learn FrontPage or HTML, but they did want a cost effective and “simple” way of entering data that allowed them to control the content on specific areas of the site. It is best to pay $1,000 for a database driven solution that will save you $4,000 over the course of a year and subsequent years.
Even though I’m a believer in database driven solutions, the correct solution is the one that is right for each law firm, and that does not always involve a database. Dennis, where do you think the “happy medium” exists?
DK: Combining a database approach with a flexible form of “templating” is a great way to build a platform for the future that will allow your site to grow and change in an inexpensive way. You must be sensitive to using technologies that users of older browsers can’t use, but techniques such as “cascading style sheets” are clearly the way the web is moving. Cascading style sheets allow you to define the look and feel of your individual pages by defining a “style sheet” that is incorporated into each page on your site.
JL: You don’t need to use a database to get the benefits of templates and cascading style sheets.
Because of the backward compatibility problem, I used to recommend avoiding cascading style sheets. I changed my mind when Jakob Nielsen endorsed them in his book, Designing Web Usability. If someone who is as pro-user as Nielsen thinks they are now OK, who am I to say no?
One technical point: style sheets can be incorporated into each page of a web site, as Dennis mentioned. These are called “embedded” styles.
“Linked” styles are much more powerful. Each individual page merely includes a reference to a file that defines a style. When you want to change the way your site looks, you merely change the style definition. All the pages that refer to it will then adopt the new look. Again, no database programming is necessary.
Linked styles have an additional advantage: faster downloading. The style definition page is downloaded only once. All other files contain only a reference to the definition, not the entire definition.
BH: I also like style sheets as a way of “global” formatting throughout a site. It improves standardization – especially when content arrives from different people and is formatted differently. You don’t have to worry about content that looks different from article to article.
DK: If you are doing a lot of content, and you should be, then you will want to think about moving to XML (Extensible Markup Language) and moving beyond standard HTML. Think of XML as the next step in the evolution of web programming beyond its HTML roots. Web programming is definitely moving toward XML and, to keep it simple, the way XML allows you to work with content creates lots of flexibility in terms of both display, including creating versions for cell phones and Palm devices, and content management. Again, you’ll need to be aware that users of “pre-version 5.0” versions of the major browsers do not have XML capabilities, but I think that it is wise to look hard at adopting XML in the case of a serious site that has a lot of content.
JL: At the risk of sounding like a wet blanket, I think it’s time for another yellow light. Certainly the concept of XML has enormous potential power, and it has the great strength of not being a proprietary technology. Among other theoretical advantages, XML makes it easier to separate form and content. However, my sense is that there is no point in law firm web site developers worrying about XML today.
XML does not work in a vacuum. For it to be more than marginally beneficial, there must be widely accepted DTDs (Document Type Definitions). As far as I know, there are no widely accepted DTDs that would be particularly useful for a law firm web site. FindLaw and the Georgia State University Electronic Court Filing Project are sponsoring a group called Legal XML (http://www.legalxml.org) that is trying to develop DTDs for the legal industry, but as far as I can see, their work so far does not have a lot of relevance to law firm web sites.
BH: Jerry, you are correct. The DTDs have yet to be defined. Having said this, the National Archives and other governmental agencies are looking at XML as an archival standard for storing information in the future.
In addition, it’s important to note that anyone who creates a document in Word 2000 and performs the function, File to Save as Web Page, has created an HTML document that contains XML. Microsoft moved to XML a couple of years ago and the documented created in this example will have formatting that is defined by XML tags and not HTML tags.
All technology must be considered. It’s moving into our lives – whether we need it or not.
DK: The important point is that by spending a bit more now to build a strong foundation, you will have flexibility in the future and save money because your site will not have to be reworked over time. Look at approaches that embrace web standards rather than proprietary approaches. Treat your site as if it matters to you, go into the design process with the idea that your “problem” will be how you will deal with success, and think about ways of creating a framework for the site to grow and evolve. It may cost you a bit more in the near term, but you’ll be way ahead over the long haul.