Here’s a list of often-overlooked interior page elements that designers should provide for every site:

Typography

Typeface

Traditional web design has relied on the big six (Arial, Times, Verdana, Georgia, Comic Sans, Courier) because of their inclusion in the Mac and Windows operating systems. There wasn’t much point specifying a font the user wasn’t likely to have. This is still largely the case, but with HTML 5 (and a progressive target audience) you can specify fonts your users don’t actually have using CSS3. Designers who go this route should be prepared to provide their developer with the font files.

Size and Line Height

It goes without saying that the developer will need to know the type size and line height, or leading (space between the lines of a paragraph). It’s very important to keep in mind here the wide variance of screen sizes and resolutions that will be viewing the design’s type. It shouldn’t be too small. Exceptions are always possible, but generally don’t specify body copy smaller than 11pt in Photoshop.

Note: Photoshop’s point sizes don’t translate directly to web point sizes. Copy set at 11pt in Photoshop will appear more like 10pt on a web page.

Paragraph Spacing

If left unspecified the developer will probably end up using default paragraph spacing. If additional spacing between lines is desired, the designer will have to let everyone in on it.

Headers (h1 – h6)

With today’s semantic markup techniques and Google’s weighting of header element content, it’s important to understand the traditional HTML header  system (h1-h6) and how it will be used in page layout. Designers should expect this, and build their design system accordingly. Developers will need to know typeface, size, line height and spacing for each of the six headers content authors will use. If left unspecified, the defaults will be used instead, which will probably not be pleasant for anyone. =)

Inline Links and Hover States

Developers need to know the color and style for links, both visited and unvisited. By style we’re referring not only to bold, italics, etc., but also to underline style. It’s common to have links underlined under normal circumstances, but then to disable the underline when the mouse is moved over the link. Any style cues like this need to be specified. This last state, when the mouse is over the link, is referred to as the hover state or mouseover state.

Lists (Bullets)

Developers need to know how the bullets should look, but usually prefer to leave this set to the font’s default bullet style because it solves a number of implementation gotchas. If the designer is set on having custom bullets, her or she needs to illustrate the expected wrapping and indenting appearance for both unordered (bullets) and ordered (enumerated). Make sure to demonstrate at least two lines so developers can tell how the wrapping should be handled.

Inline Photos

Your design will need to take inline photos into consideration also. Most likely designers will want their photos aligned right, with padding to the left and bottom of the photo. Just make sure the developers can tell what the alignment and padding are.

Footer

All too often footers don’t get the love that headers get, and that’s just wrong. A lot of print designers will provide mockups that treat the web page as if it were a 1024 x 768 piece of paper with the footer ending at exactly the bottom of the page. In reality, though, most web pages extend below a normal screen height (sometimes called the fold). If the design has an outer glow or drop shadow around the main content area of the page, the designer will need to continue this and show the developer how to resolve what happens below the content of the page.

Navigation Menus

If there are navigation menus in the design then the developer will need to know how to execute them. Key points to bear in mind here are: dropdowns, hover states, current section state, and nesting. If the design has dropdown menus the developer will need to know how it behaves in its various states. Does the list drop down from a main menu bar (usually called a suckerfish menu)? If so, does it expand hierarchically? The developer will need to know if each level looks and behaves like the last, and how an entry looks if it’s the parent of child menu items (does it offer a triangle cue?). Does the current section of your top menu stay highlighted? Then they’ll need to know the appearance and hover states for the section item. Is there a left-side nav? If so, make sure to think through how the nesting will look, how wide the column needs to be to accommodate the site’s menu structure up to at least three levels deep.

Callouts

If the site features callouts or display ads, don’t neglect a good place for them. Try to stick to standard ad sizes if at all possible.

Sidebar Items

If the design has sidebar modules (e.g. for Joomla, WordPress, etc.), the designer will need to provide a look for sidebar modules. That includes: headings, text, links, and any separators or other necessary elements. The developer will need to know the typeface, size, link colors, hover states, etc. of these items if they are not site-default.

Specialty Items

Tables

If designers know a site will display tabular data then they should go ahead and provide table examples demonstrating headers, cell spacing, text formatting, borders, alternating row colors, etc. Tables aren’t typical page elements, so this is not a requirement of many designs.

Blockquotes

Like tables, many sites don’t have any content inside blockquotes. But for blogs and discussion sites, they’re a must. Let the developer know how this should be handled.

Wrap-Up

Unfortunately, coming up with a complete website design system correctly is a lot of work. But by understanding what’s required for developers to actually make a design a reality, designers can help ensure the project stays on track, on time, and on budget. That’s when everyone comes out a winner, and that’s what we’re shooting for here. =)

But first, a little background… Web designers are always looking for new and better methods to present content in more efficient and user-friendly ways, and two of the best practices borrowed from desktop applications are “tabs” and “slides.” Tabs allow for multiple content items to be displayed in the same document window, while slides allow portions of the page to expand/collapse on demand. Both provide the designer with a method of allowing the user to quickly get to additional (i.e. supplemental) information without requiring a page load. This idea is pretty common in sites where there is an initial product description above a series of tabs for technical data, comparison charts, related items, etc.; clicking one of the tabs changes the content below the tab set while keeping the product description above. With the advent of freely available JavaScript frameworks like jQuery and MooTools, the bad old days of programatically cumbersome and SEO-belligerent tabs and slides are gone, replaced with elegant DOM- and CSS-based solutions.

A stock Joomla 1.5 install has no built-in facility to display page content in tabs or slides, and so developers must either cobble something together from scratch or use a third party plugin. And that’s what takes us to our first plugin of the series… Joomla Tabs and Slides (in content items). Like most plugins, Joomla Tabs and Slides provides a non-invasive method of adding its functionality without the developer having to add any code to his or her templates or touch the core Joomla code at all. As with most well-written plugins, simply install the Joomla Tabs and Slides ZIP archive in the Joomla Control Panel (Extensions > Install/Uninstall) and then make sure it’s activated in the Plugin Manager (Extensions > Plugin Manager). At this point, you need only add some simple inline tags to your articles, so let’s talk about those.

When Joomla renders your site’s content, it passes through the filters of a number of plugins, each getting the opportunity to do something to the content. Joomla Tabs and Slides simply takes its turn at your content, looks for its special “tab” tags (see example above), and outputs the CSS and JavaScript necessary to turn them into tabs. To begin a tab set, simply add a new paragraph in the Joomla article editor and type “{tab=xxxx}” replacing xxxx with the name of your tab (don’t type the quotes; spaces and special characters are allowed). As you can see, the tab tags begin and end with braces. Then type the content of your tab. It can be just about any properly formatted content (tables, paragraphs, images, etc.). When you’re ready to close your tab and begin the next one (assuming there is more than one), simply create a new paragraph and type “{tab=xxxx}” again, replacing xxxx with the name of your next tab (no quotes). Continue this until you have finished the content of your final tab. Then, create a new paragraph and type ”{/tabs}” (no quotes). This tells the plugin to close up the tab set. In the example above you can see how this looks in the WYSIWYG and source editors, as well as final page render. Note: In the source editor, it’s possible to use wrapper tags other than paragraphs (e.g. h1, h2, h3) but paragraphs seem to be the easiest for content authors to manage.

Hopefully this paints a clear picture of what the plugin can do and how to do it. You can see it in action at one of our sites and also at the Joomla Tabs and Slides plugin page itself. Enjoy!

Such was the case when we recently launched Group3Solutions.com. We’re usually on the other end, launching sites for clients or helping them relaunch an existing site and dealing with the search engine issues that arise from changed URLs. This time, we were the client. And, though Group3Solutions.com is a brand-new site and not a redesign, we there are still lots of things that need to be accomplished to hit the ground running for search engine purposes.

So before going live, we got out the Site Launch Checklist we often use with clients and started putting our recommendations to use. Thought we’d share it with you. Some items deal more with new sites than relaunches, or vice-versa, but it’s all good to know.

1. Create an XML sitemap with the new URLs before the new site goes live. Immediately upon launch, the new sitemap would be uploaded and the search engines notified.
2. Take advantage of blogs to announce the launch. Consider submitting a news release to PRWeb or a similar service to get the information out in an automated fashion.
3. Keep your site’s URL structure as simple as possible, and use keyword-rich words in URLs when possible (if separating words with punctuation, use hyphens instead of underscores). Dynamic URLs with multiple parameters can cause duplicate content issues where identical or similar content has multiple addresses (think “Printer Friendly” pages, for example). Bots may consume much more bandwidth than necessary, or may be unable to completely index all the content on your site.
4. Canonical Tags help tell search engines how you want your domain indexed (Group3Solutions.com vs. www.Group3Solutions.com, for example). Some search engine tools also allow you to tell them which version you prefer.

If your site will stay at the same domain but URLs will be changing, keep in mind that bookmarked pages, deep-links into your site, and URLs in the search index will break. Here are some additional tips.

1. The XML sitemap is very critical here. Make sure the new map with new URLs gets uploaded with your new files.
2. At least for the highest-trafficked pages on your site, create one-to-one 301 redirects to automatically and seamlessly send visitors (and bots) to the page on the new site that they were trying to visit on the old one. The 301 code tells the search engines that the page has moved permanently, so the new page will be added to the database and the old one removed (over time). Links from third-party sites to the old site will continue to mean the search engines try to index the old URL, but the 301 is the best option to eventually straighten out the issue.
3. A custom 404 page offers a softer landing for those pages that don’t have a 301 redirect. The 404 carries the same look-and-feel of your site, but with a structure that allows users to more easily find where they were trying to go. Note: the page does need to return a 404 code, and not a 200, or the sitemaps won’t work for some engines.
4. If possible, notify key sites that link to you. Provide them with the new URL for the page(s) they link to on your site. Good Webmasters don’t like broken links, so most will be happy for the notification.
5. Pause AdWords campaigns during the initial transition (first few days), in case any technical issues come up. During this time, changing both Display and Destination URLs is also required.