So, we’re finally getting to the meat of best practice web development. This is what people are usually thinking of when they ask about best practices in web design or web programming: actually building the web site itself.

Web design best practices encompass a wide range of needs — everything from the visual look of the design and use of well-chosen markup to the implementation of alternate styles for mobile devices or print shows up in this area. Covering it in one article is, perhaps, ambitious. Fortunately, I’ve written on parts of this subject frequently in the past, so I’ll be providing a lot of links.

It’s important for best practices to clearly separate the structure of your web design (the internal labeling and definition of page elements) from the design elements (the appearance of these elements.) In the last article in this series, I discussed a few key elements of design: not in terms of color, layout, or typography, but in terms of communicating information.

Best practices ultimately leads to creating a universal or accessible design, and this practice hinges on two key concepts: web semantics and the separation of your structure from your design.

The Semantics of HTML

You can argue for days (or years, if you take look at the search results for “HTML semantics” or “web semantics”) on the detailed semantics of how HTML tags should be used. I’ve written on this several times, myself, including articles discussing the value of empty elements, the age-old debate between table-based or CSS layout, among many others.

Semantics are very important. However, when you really look closely at HTML you’ll inevitably notice that it’s not a strongly semantic language — the mark-up language doesn’t even come close to describing all possible uses of the tags. Many tags end up inevitably serving multiple functions.

So what web semantics really require is interpretation. The HTML specification provides one version of this interpretation, with suggested uses and meanings for elements. I’ve provided my own interpretation, as well. There are without question differences of opinion between those documents.

Obviously, you can argue very convincingly that any interpretation which disagrees explicitly with the HTML 4 specification is wrong. Feel free. The core of best practices in web semantics is to use them and make decisions: it’s about thinking, not specific rigor.

We need to differentiate, however, between the semantics of HTML and web semantics. The semantics of HTML are specific and defined: meaning as applied to the elements of HTML. This is a finite list of items, although the complete definition of meaning is less so. Web semantics, on the other hand, describe the application of meaning on the web. This is a more global concept, and applies to all aspects of your web development process.

Web semantics includes everything used to add meaning to your site, providing better comprehension of code and content. Using describe class and ID naming conventions, descriptive function names in server or client-side scripting, or providing helpful comments within your code can all be considered points of web semantics. Best practices means providing a site which is meaningful in both the front and back end.

For specific suggestions about element use, refer to my guide to semantic HTML.

Separation of Structure from Design

This is such an old question to harp on, but the importance of separating the organization of your page from the way it looks has never really flagged.

At a superficial level, it may appear that any markup you use has an effect on the appearance of your site. After all, there’s a clear visual difference between unstyled text marked as a heading and unstyled text marked as a blockquote! However, this visual difference only truly exists because the description “unstyled” is truly a misnomer.

If you disable stylesheets on a web site, you’ll see an extremely plain view of the site. It is not precisely “unstyled,” however — the design has simply been reduced to the default styles applied by the browser. In general, every browser has very similar defaults — but they’re not exactly the same. This is one of the reasons that it’s common to begin a stylesheet with a set of reset styles.

If you conscientiously remove the browser default styling, it can make your own development easier: the slight differences between browsers can then be ignored.

The point is that you should never place anything in your markup which exists purely to create a different appearance. Attributes or tags which define font faces, colors, or styles are obvious problems — but the use of small or strong can also be problems. It’s not that you should never use small: but your use of the element shouldn’t depend on the text being rendered smaller than the surrounding text.

It might not happen, after all.

This is one of the key complaints about using tables for design layout. A table is designed to organize information by providing easy access to it in a matrix. The columns and rows visual appearance of a table is a formality used because it is an expected way to view this type of data organization.

When you take a table and use it to layout your design, you are violating the separation of structure from appearance: your design is now dependent on the default organization of tables. Should somebody attempt to re-organize your table (for example, to linearize the information,) they may encounter a radically illogical data structure.

Fundamentals of Universal Design for the Web

The goal of universal design is very simple: make the information in your website available to every person or device which attempts to access it. This includes mobile devices, search engines, assistive technology, disabled users, and standard desktop browsers.

Universal design is where we bring everything above together. Attention to web semantics and a strong separation between structure and design give your web site at least a fighting chance of being universally usable. Obviously, you can still screw things up!

In the same way that following web standards doesn’t mean that you’ve made a web site accessible, following best practices for general web development doesn’t mean that you’ve made a site which will be great on a hand-held device or with a screen reader.

Different devices (like people) have different special needs.

Creating a web site which is truly universal requires you to be aware of the special needs of every device you’re working for — but a few basic principles will get you 95% of the way there.

The Principles of Universal Design provided by The Center for Universal Design at North Carolina State University are a good guideline for thinking about universal design. Although these principles are truly designed to be universal, in that they are intended to be applied well outside the realm of web development, the basic principles are sound in any context.

If you break the concept of universal design down to a single core issue, it could be that dependencies break access. Whenever you set up a situation in which a specific technical or design element must be present (a dependency on Javascript, a requirement that a control matches the description provided, or a requirement that a user must see a given image, for example,) then you are creating the potential for design failure. Avoid creating anything which depends anything out of your control.

Knowing what is and isn’t in your control (and, more importantly, what seems like it’s in your control, but really isn’t) is critical to best practices in web development. Acknowledging that although you can set the color of the text, you can neither guarantee that a visitor will be capable of seeing that color nor that the text will in fact be that color at the point that a visitor sees it is a critical step in understanding universal design.

Best Practices in Web Development: Part 5 (published on Friday, September 5th) covers interaction design, error management, and long-term site administration.

You could say that this part of the series is really breaking the concepts of information architecture down into components immediately relevant to web development. Practically speaking, I’m going to cover the necessities of navigation design, the concept of “scent of information” and the question of design “noise.” (Canonicalization was supposed to be covered in this part of the series, as well, but I’ve moved it.)

Navigation design is obvious: the primary organization of all aspects of site navigation. This is an area of web design and development where it’s very easy to go massively and devastatingly wrong — like most best practice concepts, avoiding the pitfalls is 90% of the battle.

“Scent” refers to information design which provides “clues” to help show the user where they are, where they’ve been, and how to get where they need to go. Planning your site should include careful planning to think about these processes.

“Noise” is a term I’m using to describe the opposite of “scent.” Noisy elements of design are those elements which detract or distract from a user’s needs. They may generate confusion or prevent users from following the path of action they need.

Navigation Design

Navigation design has two parts: organizing the documents and sections of your site into links, and generating the visual and interactive method which will be used to access that navigation. It’s important to do this in the correct order — and this is the point in the development process where you simply need to know the scope of content on the web site.

It’s neither necessary nor desirable to actually know every single item which will be on the site. In fact, it’s usually not even possible. A website should grow after it’s initial development, so you should always provision for the addition of future documents. What you need to know now is as much as possible about the documents which will definitely be on the site.

To get started, ask your clients for this information:

• A list of content categories,
• A list of representative content titles and summaries,
• A list of additional features which will require access.

Ideally, you’ve already got a lot of this information from the contract phase. But, if not, now is the time to get it.

For the first steps in navigation design, you’re going to focus exclusively on the content and features.

The organizational needs will be different from site to site. Obviously, a site which is focused primarily around a specific tool will need to primarily concentrate on getting people to that tool. Text content, such as help files or related articles, will automatically be relegated to a secondary position in the navigation. In general, however, this article is dealing with text and content oriented sites: sites which need to communicate certain types of information to users.

A classic method for categorizing documents is to perform a simple card sort. You can perform this test with as large or as small a test group as you feel comfortable with. Restrict users to people who have a reasonable chance of being able to use the information — you may not want to use your grandmother to sort documents on structural engineering. (Depends on your grandmother, naturally.)

Ultimately, you may want to perform two separate card sorts: an open sort (with no established groupings) and a closed sort (using the client’s requested groupings.) For the sake of brevity, I’m assuming that you’ve worked with the client to refine the requested categories.

The guidelines for the process are simple: write the document titles (and brief descriptions, if the title is ambiguous) on index cards. Give people a pile of cards (usually between 30 and 100), and ask them to sort them into groups of like items. This is an excellent way to gain insight into how potential users of the site might expect to find information.

A card sort certainly shouldn’t be your only method to find a logical navigation structure, but it will provide valuable clues concerning what might be expected by visitors. You should also realize that disagreement between sorters doesn’t mean that you need to pick one option: it may simply mean that additional lists of information using different sorting mechanisms may need to be available.

Your ultimate goal in sorting information is to avoid requiring users to look in more than one place: the apparent likelihood that a given document will be found in one category should always lean in one direction.

The second step is relatively simple: building and designing the navigation. Best practices pretty much insist on accessibility and the use of web standards to construct navigation. I’ve written an extensive article on accessible navigation design already, so I’m simply going to refer you to that article for this section.

Scent of Information

Providing a strong scent of information is a good follow up to categorizing your information. Having spent all this time filing information away, I’m sure you noticed that some information just flat out belongs in more than one place. A classic example (for almost everything, actually) is the iPod. Is it computer equipment? Is it audio equipment? What about entertainment equipment?

Ideally, you want to provide enough information about your categories to help users visit the right category first — and not by using the site-cluttering cop-out of putting your items in all relevant categories.

Seed your navigation with extra information

When there’s a possibility of doubt, one of the first steps you can take is to add information which describes your category. Instead of just listing “Computers” in the navigation, say “Computer: Laptops, monitors, mice, keyboards.” You can’t (and shouldn’t) list everything in the category, but providing a representative sample can help users target their navigation more accurately.

Provide navigation to related information

A second method you can use it to provide links to related information. When you have a site set up where there’s a possibility of confusion, you should be able to identify most of these potential problems in advance. Using the same example, you may want to provide a link to iPods and digital music players if somebody is browsing under sound cards or audio software.

Use descriptive linking

A link which tells you precisely what it links to is far more valuable than a generic link text. It’s more likely to attract the eye, more likely to result in an action by the user, and will help your users quickly target the right document.

It’s not just for accessibility that you want to avoid repetitive or meaningless link texts. From a usability or marketing perspective, the right words can make all the difference.

Use meaningful trigger words

What behavior do you want to encourage? When somebody writes “Click here,” they are obviously interested in the short term: they want a click. If somebody writes “Read ‘The biography of a whale’ Now” they’re asking you to read the document. Similarly, using words like “Buy,” “Explore,” or “Hire,” you’re providing a specific, task-oriented clue within the text of the link. Because of this, the user knows better what to expect when they follow the link — and are more likely to follow the link they really want first.

Or, thinking persuasively, are more likely to want what you’re trying to offer. It goes both ways.

Design Noise

On the opposite side of the coin from scent, we find noise. Bad information, information pollution, stink — whatever you might want to call it, the end result is the same. This is information which leads the user the wrong way.

Identify your primary goal

If you’re a sales-oriented site, the strongest scent should be provided to guide users to products and along the purchase path. You may want to provide a lot of essential and valuable information about your products, about your business, or about the industry you’re working in — but if information isn’t your primary business, you should let these parts of your site take somewhat of a back seat.

Link to your documents accurately and understandably

Make sure that whatever you’ve used to link to a page is accurate. If you’ve stated that an article contains certain information, or has a certain product on it — it bloody well better! This seems like it should be obvious, yet I can’t even begin to count the number of times I’ve found myself following a seemingly valuable link just to be stymied by the document itself.

Following a related logic, you should be careful to link the document in a manner which is readily understood. If you’re providing a tool for people to estimate what the salary for their desired job should be, don’t link it using “Proximal Salary/Earnings Indices by Region.” Instead, link to it saying “What should you earn where you live? Find out here!”

Using easy language may sometimes be less precise, but will almost always be more useful.

Don’t try to give everybody everything at once!

Too much information crammed into a finite space means only one thing: you don’t know what your users need. And as a result, your visitors probably only need one link — the back button in their browser.

The reason for information organization, at heart, is to reduce the problem of information overload. It’s certainly possible for people to find information given a page of 700 links, but is it an efficient way of working? No. Ultimately, it’s far faster to follow two or three links with a strong scent than to have the possibility of offering a single-click path to information.

Additional Resources

• Information scent: helping people find the content they want
• Deceivingly Strong Information Scent Costs Sales
• Card Sorting: A Definitive Guide

Web Development Best Practices: Part 4 (published on Wednesday, September 3rd) covers semantics, separation of structure from content, and the fundamentals of universal design for the web.

No legal definitions established today, I’m afraid to say. Although this is a victory on behalf of the claimants, who were awarded substantive damages on their claim, there was no establishment of any kind of legal precedent.

This is primarily due to one singular item in the settlement:

2. No Admission of Liability. By agreeing to and voluntarily entering into this Agreement, there is no admission or concession by Target, direct or indirect, express or implied, that Target.com is in any way inaccessible or that Target has violated the Unruh Civil Rights Act, California Civil Code §§ 51 et seq., the Disabled Persons Act, California Civil Code §§ 54 et seq., the Americans with Disabilities Act, 42 U.S.C. §§ 12181 et seq., or any other federal, state, or local law, regulation, order, or rule.

National Federation of the Blind vs. Target Corporation, Final Settlement

This statement clearly delineates a complete denial that there were any contradictions of law involved in the Target.com suit.

Ah, well. It is still a victory!

Once you’ve established your needs document, you should take the time to pick the right server set-up. Different sites need different services — but the right hosting package should always offer certain key elements. Hosting is an integral part of good web site performance, so you should pay close attention to what’s offered.

Hosting and Web Serving Expectations

Although a lot of what I discuss here primarily effects you as a developer, there are always corollary issues: the more time you spend dealing with problems, the less time you’re spending making sure everything else is done right. A slow server is frustrating to your users. Catching these problems in advance can save a lot of everybody’s time.

Big hint: the most important issues aren’t bandwidth, disk space, or cost.

Although making sure that your hosting offers sufficient bandwidth, disk space, and doesn’t break the bank is obviously important, it’s more important that you can do everything you need to with your hosting.

1. Is your web hosting adaptable? Can you easily change your services as your needs change? It’s not uncommon for a hosting company to only offer a couple of plans — if your site grows, this means you’ll need to change hosts. While this isn’t exactly the end of the world, it’s an inconvenience you shouldn’t need to deal with. If you pick the right host to begin with, you’ll be able to move up the scale as you grow. Give some thought to your need to scale, however - if you’re creating a small website for your local restaurant, it’s unlikely that your site will grow significantly.
2. Are there “invisible constraints” imposed on your hosting? This is a nasty one, and can be very difficult avoid — but if you know a few key questions to ask, it can help. Among the problems I’ve seen are limitations on the number of emails sent per hour (50 — impossible for the company of 12 who used this hosting,) server process constraints which caused sites to be abruptly shut off because they exceeded a maximum percentage of processor use, and restrictions on use of server-side programming such as not permitting scripts to send e-mail.
3. Do they have current version script or database engines? Is your hosting using older versions of PHP, Perl, or other server side scripting languages? Yes, this may not effect you most of the time. However, when it does you’ll be very frustrated.
4. Do they offer URL Rewriting support? One of the main reasons I frequently recommend that my clients use Linux/Apache based hosting is in one word: .htaccess. Admittedly, there’s a lot more to .htaccess than a few redirects and some URL rewriting, but that is an extremely key functionality. With Windows hosting, URL rewriting can be available through ISAPI Rewrite…but it’s along the lines of “pretty much always” with LAMP hosting and “maybe sometimes” with Windows.
5. Are databases readily available? Whether it’s MySQL, Posgresql, or anything else, databases are a key element of modern web development practices. If databases aren’t readily available from a hosting company, they shouldn’t be in the running.
6. Are their servers snappy? It’s nothing special to offer vast tracts of storage space or gobs of bandwidth. Most of the time, hosting services are gambling that the majority of the 400 sites on a server will only use 10-50 MB of the 100 GB of storage they’ve been allowed. Realistically speaking, most sites are very small — hosting companies can easily get away with this. However, no hosting company can get away with slow servers. If you can check the server statistics, that’ll help you know what you’re getting into.
7. What’s their backup policy? Does the company offer backup service on your files and databases? How easily available are the backups? How frequent are they? In case of an emergency, how long would it take to restore your website?
8. How’s their support? The single most important element from your hosting company. Period. Quick response times, professional attitude from the support team — written messages using full sentences, spoken interactions easy to understand, etc. Good support should completely read your request and respond to what you’ve said, rather than guessing at the problem from the subject line.

If you don’t have a strong foundation for your web site, you’re going to run into some trouble later on. Of course, it’s a regular event to have to work on sites where you had no say in the hosting. Sometimes, that won’t be a problem. You may need to work with an unfamiliar set up, but the hosting itself will be entirely adequate.

Sometimes, it’ll be incredibly frustrating.

Be prepared to discuss changing hosting with your clients — prepare your arguments and know the issues. With truly inadequate hosting services, you might be prevented from doing your job well.

Introducing Web Security

I didn’t mention looking at your host’s security policies and background above. That’s largely because this is an issue that goes well beyond being one of a checklist — this is a core issue for web site best practices.

I also didn’t mention it because there’s little point in asking. No host is going to tell you that they don’t really pay attention to security and have regular problems! Similarly, many hosts won’t tell you any serious details about what they’re doing to protect your security — this is, itself, protection against social hacking; but it could also mean that they don’t know what you’re talking about.

Ultimately, you can’t expect perfect security on any shared server environment to be made available by default. When a hosting company needs to make a generalized environment available which will support a wide variety of software and scripting languages simultaneously, they’re unlikely to be able to lock things down the way you might prefer.

This isn’t to say that you should ignore issues of security when you’re selecting a web hosting company — by all means, find out whatever you can! Look for reports of security violations; complaints from customers who’ve been hacked, etc. It’s good to know. However, more important is knowing what you can do to increase the security of the server for your own use.

1. Can you use PHP.ini (or equivalent) to customize settings? If a host doesn’t permit you to change their default settings on an account specific basis, that’s not a particularly good sign. You should check and make sure that their reason isn’t because they’ve already maxed the security and they don’t want anybody weakening their protection; but it’s always helpful to be able to customize your needs.
2. Can you restrict access to administrative pages? It’s frequently a good idea to restrict access to admin areas fairly stringently. Personally, I usually restrict by IP — only people at the client’s office or home (whatever’s relevant) have access to the administrative areas at all. This can help crack down on problems.
3. Can you see other user’s accounts? This is an ugly one. Logging into an account and seeing other user accounts means just one thing: they can see yours. This hosting service is obviously not separating accounts appropriately.
4. Is SSL encryption available? Not every hosting service supports SSL. If you don’t have the option for secure sockets layers, e-commerce is out of the question right away. Even if you don’t think you’ll need it, you might want to avoid any service where it’s not even an option.

A significant part of web site security is related to the scripts and software you install on your site (which will be addressed later); but even before you’ve put a file on the server, there’s potential for security problems. It’s worthwhile to take a close look at potential security problems before getting too far into a project. Hardening your security may not be a priority now, but if you don’t even have these basic options you’re walking into trouble.

Web Development Best Practices: Part 3 (published on Friday, August 29th) covers navigation design, and scent of information. and canonicalization.

This is the beginning of a five-part series highlighting the entire process of developing web sites for clients. Best practices don’t just start with construction: for a small business or independent contractor, they start long before that. Through the course of these articles, I’m going to cover issues including:

• Preparing a Contract,
• Establishing Site Requirements,
• Information Architecture,
• Hosting,
• Security,
• Navigation Design,
• Scent of Information,
• Canonicalization,
• Semantics,
• Separation of structure from content,
• Fundamentals of universal design,
• Interaction design,
• Error management, and
• Site Administration.

I’ll probably touch on other issues as I think of them or they appear relevant, but these 15 points will be the bulk of the article series. Although these articles are written as if the actions are performed in a strict chronological sequence, it’s important to realize that the real process of building a web site is much more fluid than any written description. Some issues can be dealt with at any point in the process, others need to be addressed repeatedly — don’t take the order I’m writing in as any kind of commandment!

Preparing a Contract

Your project starts with a contract. Before the contract is created, there may be a variety of proposal aspects — either the client delivered a request for proposals, requested your services specifically, or chatted you up in the pub…but the project doesn’t start until you have a contract.

There are good ways of going about contracting a project, and there are bad ways — this is well outside my area of expertise, but it bears mentioning: don’t work without documentation, however casual.

Now, one of the challenges of establishing a work contract in many web development projects has to do with how much work you should really do prior to going under contract. There’s a bit of a Catch-22 in place purely by the nature of the process: in order to establish an effective and project-specific contract (which you should have,) you need to undergo a discovery and requirements phase. However, this process is time-consuming. You should really only undergo this process when you’re already under contract!

Hence the establishment of a contract with two parts: the first part, signed prior to discovery phases, should establish the terms of discovery and requirements establishment, and note that the complete terms of the contract will be appended in a separate appendix following the discovery phase.

Now, this isn’t altogether necessary for small projects: a basic website can usually be estimated without a complex process.

Regardless of the scope of project, there are various terms which should always be covered in your contract:

1. The scope of work: what’s included in this contract.
2. The process for extending the contract, should additional requirements be established. (It WILL happen.)
3. Estimate of costs with a statement of the terms of the estimate.
4. Notification of late payment fees and deposit required.
5. Ownership of end products. By default, your design work and other materials produced by you in the course of a project are yours. However, it’s a good practice to turn copyright ownership over to the client. Many clients will require it!
6. Responsibility for creation or purchase of content: video, audio, photographic, written.
7. Definition of the completion of the contract. (I usually specify the launch of the site.)
8. Terms of maintenance, warranty coverage, correction of errors.

In addition to these issues, you should give a close read to a few articles by Sarah Bird at SEOmoz. She’s published several articles recently on contract clauses she recommends — although she’s speaking from the perspective of an SEO firm, most of these issues are highly relevant to a web design and development company as well!

1. Limited Liability Clause
2. Indemnification Clause
3. “Opportunity to Cure” Clause
4. Manage Client Expectations: Include a Warranty

Establishing Site Requirements

Before spending any significant time working on any development aspect of a project, you should sit down and establish a list of site needs. (Actually, you can do this standing, too.) Sometimes clients have little concept of what their web site can do; sometimes they have totally unrealistic concepts of what you should easily accomplish. Either way, you need to sit down with them and find this out!

1. What does the site need to do for them? Find out what business model this site will be reflecting. Is it advertising driven? Sales driven? Lead generation?
2. What is their plan for growth? Do they intend to build a community around their business? Will they be offering online support for products or services? Is AdSense all they need, or do they need to be able to manage advertising at a more granular level?
3. What kind of dynamic information might the site be able to offer/use? Will the site generate an RSS feed? Will it be articles, product information, service updates — or all of the above? Do they want to import information from an external source?
4. What will their relationship be with their user base? Will the site be exclusively used to allow visitors to communicate to the business, or will it be a two-way conversation? Will they offer additional features for their users — widgets for their own websites, applications, etc.?
5. What kind of site integration might be required? Do contact forms need to connect with a pre-existing database? Will integration with existing business systems be part of the process?
6. Who will be responsible for updating the site? Do they have a professional web person to deal with updates? Will you be expected to take that on? Will they be taking care of it, but with untrained support staff? Do content edits or new content items need to go through editorial review?
7. What kind of media might they use on the site? Images and text can be assumed, but what about audio and video? Streaming or static? Do they have the facilities or personnel to take care of captioning and transcription?

Now, the vast majority of sites require very little of this. A standard site might consist of a blog, 5-20 content pages, and a contact form. However, it’s always better for your sanity — and your contract — to have any additional needs figured out in detail before any work is done.

Once you’ve established what is required from a functionality perspective, you can sit down and convert that into a technical requirements document, specifying software required, custom programming to be done, programming languages required, databases needed, and any external information the client will need to supply.

Information Architecture

With this information, you can dive into planning your information architecture. Information architecture is, on a grand scale, a rather theoretical concept of modeling the organization of information. However, from a practical perspective, information architecture is the process of deciding how to organize the documents on your site. Depending on the type of information stored, the organization of the documents may be radically different.

The most important thing about information architecture is to think like a visitor: somebody who doesn’t already know everything about the site. This is one of the reasons it’s best to deal with content organization early in the process: you can think about content in the abstract, rather than thinking about the actual content documents you’ve spent the last month dealing with in reality.

Considering the documents in the abstract allows you to easily focus more on issues of content relationships, subject areas, and organizational logic instead of getting wrapped up in notions of familiarity.

I can’t really tell you how to organization your information — it’s fundamentally an issue of content categorization and labeling, and will depend tremendously on the information you’re working with. You can organize by type of information (Photos, Video, Articles, etc.); you can organize by section (About the business, Services offered, Contacting us, etc.). You can do both, and cross-reference between sections — it depends on your needs and the needs of your users.

Information architecture doesn’t merely apply to the organization of pages and sections of your site, however: it also applies to the organization of information on the page. This is equally important, allowing you to generate a logical map of information on the page. This will be covered in more detail in a later article in the “Best Practices” series, however!

Web Development Best Practices: Part 2 (published on Wednesday, August 27th) covers hosting expectations for a high-quality web site and introduce issues of security on the web.

Following the publication of a brief article on Search results design by Adaptive Path, I decided that revising my database search script was a valuable goal. Specifically, meeting the checklist in that result was probably not a bad idea!

It’s not that the previous version was terrible, but I knew perfectly well that it could be much better.

The additions to the script are pretty straightforward:

Additions:

• Added: Made row highlighting available in both tabular and list-based search results.
• Added: Search terms are now highlighted in search results.
• Added: The default sort is now to order results by query relevance.
• Added: Paginated navigation of search results is now available.
• Added: Translation base file [English], so translating the script is easier.
• Added: Basic Spellchecking [English]
• Added: Default stylesheet

Changes:

• Changed: Text excerpts are now truncated at word boundaries, rather than in the middle of words.
• Changed: separated results template information into external include files for easier upgrading or modification.
• Changed: Included the search form as part of the script so that search terms could be automatically returned to the search input.

The spell checking is the most exciting addition in my view. It’s hardly complete, but it’s based on a list of 4,068 common misspellings available from Wikipedia. This addition has significantly bulked up the total download size, since I’m including the spell-checking database as part of the download, but I think it adds a lot of value to the script.

I’ve also added a translation base file to the package, to make it a bit easier for users of the script to port it to their own languages. Unfortunately, I haven’t yet had time to seriously work on the internationalization of the search script itself, so (to be entirely frank) this is an area which the script isn’t really well suited at this time.

Internationalization is next on the list, however. It’s a high priority at this point, since internationalization ranks as one of the most reported problems with the script.

With spell-checking in mind, I think it’s appropriate to provide a healthy reminder of the limitations of spellcheck:

Candidate for a Pullet Surprise

by Mark Eckman and Jerrold H. Zar

There are numerous articles pointing out the business advantages of accessibility. Many of these reflect the similarity between accessibility and SEO. However, despite the close technical relationship between the needs of disabled users and the technical requirements of search engine optimization, the fact remains that the two goals are not the same, are not equivalent, and do not reflect the same ultimate goals.

At their hearts, web accessibility and SEO are focused on optimizing different aspects of your web site: accessibility cares almost exclusively about the disabled user and their experience whereas SEO is focused firmly on your bottom line and your experience, as site owner, in the online aspects of running your business.

Read more: Web Accessibility is not SEO