This is a post about something that I'd thought had died out but I've started seeing it a lot again lately. Whenever a designer does a new website design, they rarely have copy to work with. So when creating promotional areas on the homepage, in sidebars, etc., you'll inevitably see something like this:

Lorem ipsum dolor sit amet
Quisque molestie tristique nulla. Nam porta cursus sapien. Duis ullamcorper porta tortor. Suspendisse vel enim vitae magna lobortis tempor.
Read More

The problem I have with this is the "read more" link at the bottom. Content creators use this template and typically add copy but leave the link unchanged. While it may look aesthetically pleasing to have 4 promo areas with symmetrical "read more" links at the bottom, it's terrible for SEO and for general web accessibility.

It's widely known at this point that search engines use the actual text of a hyperlink as one of the criteria for search engine rankings. Chances are people aren't googling "read more" and hoping to find your website so stop polluting your pages with those links. Instead, make the title of the promo your hyperlink, or at least use descriptive keywords in your link at the bottom.

If you're a designer, stop creating comps with these "read more" links because it encourages a bad practice.

If you're a content writer, start factoring this into your content creation. Whenever you need a link, be sure to include descriptive keywords.

If you're a developer, send this blog post to your designer and content creator team members and let's try to kill the "read more" link once and for all.

Permalink | Posted On December 2, 2007 Comments (1) | TrackBacks (0)

It's hard to believe it but it's been an entire year since I started the Code Scene blog. My goal was to catalog some of the tips and tricks I've picked up and share them with my friends, colleagues, and the web development community in general.

While I don't have as much time to dedicate to blogging as I'd like to, I hope that I've helped to contribute at least a little bit to the community I take so much from. For those of you new to Code Scene (and because I don't have much free time) I've compiled a list of my favorite articles from the past year.

Website Launch Checklist

Website Accessibility Checklist

The Problem with Content Management Systems – Part 1, Part 2

Search Engine Optimization

The Problems with AJAX

Missing the Point

Redirecting HTTP to HTTPS using IIS

Guidelines for Coding HTML Emails

The Design Triangle

Hopefully I'll have some more time in the next year to keep writing more of these. Until next time...

Permalink | Posted On December 6, 2006 Comments (0) | TrackBacks (0)

AJAX is the latest industry buzz-word and to hear people talk you'd think it'd have to be the best thing since sliced bread. I'll go on record as saying that I think AJAX is awesome but, since every other article touts how amazing it is, I'd like to play devil's advocate and point out a few of it's flaws.

JavaScript - AJAX functions entirely by using lots of client-side JavaScript to send requests to the server and update data on the page. No JavaScript means that none of your cool functionality works at all. Providing a non-AJAX alternative may require a lot of extra work.

The Back Button - This is fairly similar to what happens with Flash sites. The user does something, does something else, then wants to return to the previous task so they click the back button. When you're serving normal HTML pages this works great. In an AJAX application however, the back button is essentially rendered useless.

Analytics - Having standard HTML pages provides an easily mechanism to track what your users are doing. AJAX slightly complicates this by replacing some of the pages with asynchronous JavaScript calls. While not impossible, it does have the potential to add a layer of complexity to capturing analytical data. I should note however, that there are companies such as Crazy Egg that are actively working to solve this problem.

Accessibility - Having pages that rely heavily on JavaScript and updating dynamically has the potential to wreak havoc on screen reader type programs for users with visual impairments.

Search Engine Optimization - At this time it may be difficult for search spiders to properly index content returned through complex AJAX updates.

Pasting a Link - The page updates frequently but the address bar never changes. When you cut and paste the link to your buddy, they just see the homepage instead of the info you intended. (Google Maps solves this nicely with a 'Link to this Page' button that updates the URL)

I'm certainly not trying to discourage AJAX use as none of these issues is insurmountable. As with all new technologies however, I would encourage caution and careful consideration before deploying. It's important to understand why you're using the technology instead of using it just to brag that you built an AJAX site. Remember when everyone had to have an all-Flash site, or crazy DHTML? That was the cool thing to do but people quickly learned that it wasn't always the right thing to do. I would urge people to remember that lesson and use the same caution here. AJAX is a fantastic technology and can be greatly beneficial when used properly. Let's do our best to ensure that it stays that way.

I'm out of town for a few days but after that I'll be back with some code samples on how to do some pretty neat things using ASP.NET 2.0 and Atlas.

Permalink | Posted On May 18, 2006 Comments (4) | TrackBacks (1)

One of the most overlooked aspects of web development has long been accessibility. More often then not the mentality has been "blind people don't come to my site so who cares?" To that end let me dispense with a common myth...

Accessibility is not about building sites for blind people. Accessibility is about making your site available to the largest possible audience. That does include blind people but also the hearing-impaired, those with motor-skills impairments that can't use a mouse, and those with only slight vision-impairments. Personally I happen to have pretty good vision, but if it's 7AM and I don't have my contacts in, I may want to resize the 9px font you used for the copy on your site. Building accessible sites means making the site available to everyone.

If you've done any work on government sites you've probably heard about Section 508. It's basically a law that requires any government site to be compliant with some basic accessibility guidelines. It's not yet a law for non-government sites but it may be one day. Overall accessibility is a good habit to get into.

Most web developers I know think one of two things:

• Making a site accessible takes a lot of extra time, effort, and/or money
• Adding ALT tags to site images will make the site compliant.

Both of these assessments are positively false. There's much more to making a site accessible than simply adding image ALT tags but neither is it expensive or time consuming. To help, I've put together a handy checklist of some of the things to keep in mind when building a new site. This isn't meant to be a definitive list, just some quick reference material on the basics.

Website Accessibility Checklist – - 24 KB
Website Accessibility Checklist – - 65 KB

If you're interested in learning more about accessibility, I highly recommend Building Accessible Websites by Joe Clark.

Permalink | Posted On February 19, 2006 Comments (1) | TrackBacks (0)

Testing and validating our pages is, or should be, a large part of the development process. It's no ones favorite thing to do but I've found a little tool that can make it slighly easier.

The Web Accessibility Toolbar is a browser plugin that provides a set of buttons which allow the developer easy access to functions such as:

• Validating HTML and CSS against W3C specifications
• Resizing the browser window to default sizes like 800x600 to see how the page will render on different monitors
• Easily turning CSS off to see how the page will render for old browsers, screen readers, and mobile devices
• Getting document info such as page size and estimated download time
• Seeing the underlying structure by highlighting table cells and/or div tags
• Checking the site for 508 and WCAG compliance

It's free, easy to download and install, and comes in very handy. While currently only for Internet Explorer, versions for other browsers such as Firefox are reportedly under development.

Download the Web Accessibility Toolbar

Permalink | Posted On February 8, 2006 Comments (1) | TrackBacks (0)

This entry will be a slight rant about a pet peeve I have. I’m reading some information on a site about a product I’m interested in. I see a link for more information on the product. I click it. My PC slows to a crawl as my browser loads Acrobat and attempts to open a 7meg PDF file. Why? Why would you not tell me I’m opening a PDF… a 7meg PDF?

I don’t hate PDFs. This one was actually quite useful and I’m glad I was able to get it. However, it would’ve been nice to know what it was so that I could right click and save it, rather than having it open in the browser window. Note to Adobe: I love your stuff but you need to make some serious improvements to the Acrobat plugin. I have 2.5 gigs of RAM, it shouldn't take this long to open a PDF.

If you’re a web developer… and you probably are if you’re reading this… I make the following request to you. Putting PDFs on your site is great but please let your users know that it’s a PDF. If it’s a large file, put the file size there as well. Format your links something like...

Download the widget fact sheet (PDF, 7megs)

Maybe use a little PDF icon... something. The same would go for Word Docs or Excel files to. If I'm clicking something and it's not another HTML page, then let me know.... please?

Permalink | Posted On January 10, 2006 Comments (2) | TrackBacks (0)