There exists an abundant supply of articles on the internet aimed at making 404 error pages more helpful and informative. They often suggest web designers include a search field, common links, and generally avoid being too convoluted or too technical in nature. All excellent tips that promote usability and accessibility.

Frankly, I could care less about reading an error page. I’ll go look elsewhere. I don’t need suggestive links. Give me access to your navigation system and I’m good. I’d rather just fall back on Google or another place for the content. Internal site searches often produce irrelevant content or poorly presented information. In any case, I don’t like using internal searches and can’t remember the last time I’ve had to rely on them (or better yet, the last time they produced anything remotely close to what I was looking for).

Furthermore, the only sure fire way to avoid the problems those pages often cause visitors is to monitor crawl stats, either through your server or through Google Web Master Tools. If you see 404s, clean them up by fixing the code (if you broke something), or simply by adding permanent (301) redirects to your .htaccess file. Packing an error page with links or miscellany is a waste of time in my opinion. It’s a bandaid, not a cure. Fix the problem and you’ll likely never need one (provided it’s not a 403 or a 500).

So I decided I would take a different approach and pack my error pages with wisdom instead of the usual drivel.

404: Not Found

Cannot find your file
As the reed bends in strong winds
Be resilient

403: Forbidden

You may not enter
The king is without mercy
Respect is divine

500: Internal Server Error

Something went awry
Be wary of vanity
Practice modesty

We all love ads. I mean, what’s not to like? They’re obtrusive, compete for our attention, distract us, slow down our browsing, sometimes crash our browsers, and generally frustrate us to the point of madness. And can I get everyone to raise the roof for Flash ads? Awww yeah, baby! Adobe in the house! Mo’ crashes, mo’ crashes.

Seriously, advertising is still a scourge of the internet. Usability mogul Jakob Nielsen discovered a long time ago that people pay little, to no attention, to advertising in web pages. You actually have to trick them to look, by making the ads appear to be “a part” of the website. Still companies and budding entrepreneurs pack their website full of banner ads. But is their overzealousness myopic and ultimately fuelled by a “sledgehammer to crack a nut” mentality? I did some digging into the effects adverts have on general load times, performance, and subjective feel.

Enter www.engadget.com (my testcase for this study), a great place for any tech-junky. I subscribe to their RSS feed. Sometimes making a comment or two, but for the most part, I avoid their actual website as it is glutenous and a bear to pull up (especially on my iPhone). The wait times are killers. And apparently I’m not alone (pdf link). So I ran some tests.

First, let’s look at the general size of the home page, with and without advertising.

Less than half the size. Minimizing the number of files reduces HTTP requests. As Yahoo has discovered, browser spend most of their time negotiating requests, compared to actually downloading images and HTML. It is actually much more efficient for a browser to download one 500 KB file, than a hundred 5 KB files. Since the nature of advertising can never make use of CSS sprites (combining into a single file and then adjusting their position using Cascading Style Sheets), they will always clog up your browser.

Now let’s look at DNS lookups. The more lookups that need to be done, the slower the page load. Yahoo has some “best practices” and explain why they have a detrimental affect on page load times.

While DNS lookups spanned across 4 domains, regardless of whether advertisements were blocked, the actual number of hostnames dropped, from 17 to 10.

Finally, page load times went down. It took 8.83 seconds to load the home page, sans banners. That number went up nearly 20% when ads were visible (10.34 seconds). While most people may not see this as a drastic jump, this was done on my PC. A 2.0 GHZ Macbook Pro. Think about devices like the iPhone, or Google’s Nexus One. These machines pull in full featured websites, but don’t have 4 GBs of RAM or processors that can crunch billions of operations without breaking a sweat. Moreover, mobile phones don’t have access to WiFi all the time. Many of us have to make do with 3G service that is not nearly as fast as the DSL and Cable lines provided by our respective ISPs. Regardless, it’s about wait times.

Broadband doesn’t give web developers the right to inflate load times. And let’s not forget about the human spirit. We have this tendency to become spoiled. The faster we get content, the faster we expect it, and the less likely we are to stick around if don’t get what we want. Making load times faster ultimately makes us less willing to sacrifice those speeds. Think about a guy who went to rags from riches. I bet its much harder to lose that wealth than to have never had it!

I agree this article may not be an expansive breakdown on the issue, but there is certainly some food for thought here.

People hate ads, and while bandwidth may not be an issue in the home, it is certainly something to consider when using mobile devices. Just ask AT&T about their predicament and what they feel is the cause. Yet this is just the start. More and more phones are catching up to the iPhone and delivering online content in all its rich, glory. Soon it won’t be just the iPhone that guzzles bandwidth.

Then there is the question of stability and 3rd party plug-ins (viz., Flash). Flash drops any browser on Mac OS X to its knees. Even on Windows, it’s not all that terrific, churning out those CPU cycles to display its meagre videos. So developers that loose Flash ads are real braggarts. As if it wasn’t invasive enough to have ads plastered throughout content, they now animate and degrade system performance and stability.

So what do those banners give you in terms of income? And is it ultimately worth it? It seems I have been making an unconscious decision to steer clear of banner ridden websites. And while I may be a minority, I’m pretty sure that one some level, all visitors have the same sentiments (perhaps choosing not to act on them).

Every 3rd rate designer, charlatan, scam artist, and wannabe is going to tote about W3C valid code, high usability, and SEO, yet few will probably deliver on their claims. After all, most of their clients probably won’t have any clue they’re getting everything they paid for. These smarmy “designers” will probably flaunt their online portfolio, chalk full of cherry picked work that exemplifies their phenomenal skills and abilities—some may be truly inspirational. In fact, a well put together site from these unscrupulous individuals may look downright appealing, almost too good to pass up. But is it all smoke and mirrors? Are they truly legit artists that are going to provide bang for your buck?

Find out with a little bit of investigating. Just 15 minutes of digging can save you loads of cash, time, and ultimately your sanity.

Coding Standards

First off, check their code. First thing I do when I visit a competitor that claims valid code is to put their own website to the test. If they aren’t taking the time to implement proper, valid code into their own website, then there is a good chance, they won’t do it for you either. After all, any good designer will use their own personal website as a testcase—a practice arena to hone and fine tune their skills. You can do this by seeing if their website validates.

Visit the W3C Markup Validation Service, a free service provided by the World Wide Web Consortium (W3C). The W3C is responsible for making the internet into a coherent and usable place. They have outlined and set forth countless guidelines so that ultimately web pages show up exactly how they are intended to, regardless of what kind of browser or operating system a visitor is using. If you’ve ever been to a website that said it didn’t support your browser or was broken beyond repair, you will appreciate their vital service.

By visiting the W3C validator, and entering a designer’s website address, you can see if they meet the requirements, and indeed have a valid website. Note that entering www.szilveszter.ca, for example, only tests that single page, and may not give you an accurate account of the entire website. But it’s a good start. If their home page validates, you can always dig deeper (and probably should at least test a few of them), but if it doesn’t, well, chances are none will, and you can just move on.

Search Engine Optimization (SEO)

Another way is to check the code itself. This really applies to SEO over valid coding, but since that is actually a huge deal these days (and they are really intertwined), it’s something to be mindful of if you contract a web designer (especially one that totes: SEO).

Simply right click on an empty portion of their page, and select “View Source” (or equivalent) from the menu. You’ll be greeted with a new window full of code. Don’t worry if you have no idea what you’re looking at, that’s not important. What you should be focusing on is the meta stuff (metadata is essentially the data of data, like dimensions, file size, and colorspace of a jpeg, for example). Things like “description”, “keywords” and “title”. Below is an excerpt from a working designer from my local area (I have a client that has dealt with this so-called expert in the past—the word “nightmare” was used without restraint).

<meta name="description" content="This is where you add the website description." />
<meta name="keywords" content="keywords, for the site, go here, separated, by commas" />

She obviously didn’t even code the website herself. Some “experienced designer.” Looking at the footer shows exactly where she got it from:

<!-- <div id="footer"> <a href="https://www.coffeecup.com/store/themes/">Web Templates by CoffeeCup Software</a> -->

While she changed the home page description and keyword tags, she failed to do so on the other pages. Sloppy and stupid—nice combination. Would you feel you’re getting your money’s worth? I know I wouldn’t. Ideally, you want a designer to design around your personal needs, and not use some “cookie-cutter” design. I may seem overly harsh towards this person, but I know she has inflated her prices, downright robbed clients through exorbitant fees, and has unlawfully accessed her client’s email accounts (for starters). Truth be told, she is the direct inspiration for this article.

What you are looking here is the basics. If fields are missing, that’s a good sign they aren’t optimizing for search engines. Looking deeper requires knowledge in the area of SEO, but at least you can find flagrant violators.

Affiliates

The next thing to look for are the affiliate links. Many charlatan’s claim they have worked with high profile companies. Big names like IBM, Microsoft, Sony, Apple, or Fox. But what proof do they have? Other than a link and their word, do they present any evidence of their high profile contract, or the work they did for these Fortune 500 companies? Obviously a little bit of common sense will get you a long way, but it’s always nice to see concrete work that was done. A link to a live website. Some example of the work that are readily available to those that use the product. If you claim you’ve done the interface for xyz, then I should see it in action when I install the program.

And this gets me to my next point: See their work, live. Most of these unscrupulous individuals show fancy portfolios, but none of them link to the live website. I perused a local design firm that showed a lot of classy stuff. I thought they were inspirational, until I tried to visit one of their client’s websites. There was no direct link, so being the sleuth that I am, I uncovered the address through Google. When I went there, I noticed all the links pointed back to the design firm. What this company did was purchase an entirely difference domain name, create a home page, subsequently linking everything back to their own wesbite

Here is the entry in their online portfolio. And now the address for Landscaping Victoria, their so-called client.

Things look kosher right? Click a link on Landscaping Victoria. Wait what? Yep. It heads right back to the design firm. They have artificially inflated their portfolio and their listing on search engines. Smarmy.

In Closing

Keeping these small things in mind can lead you to filter out many of the assholes that make things difficult for qualified designers that take the time to fully deliver what they promise. When every website claims the same thing, it can be maddening finding a legitimate designer to contract and provide you with quality work.

MacRabbit (of CSSEdit fame) has loosed another version of their “vapourware turned legitimate program,” Espresso, unto the suspecting public. Version 1.1 expands on the “skeleton-like shell” of former iterations by adding several new features, a lot of polish, and some general refinements to the interface and operational program behaviour. Admittedly, I have given little time to this program in the past (yet I’ve always strangely wanted to like it, despite its many failings), as it proved to be quite buggy, and just too eclectic for my taste. However, this new iteration seems to tie a lot of loose ends together and is getting to be an attractive alternative to the already popular Coda. It generally feels a lot snappier and much more refined than previous versions. There are still some rough spots, but it’s certainly starting to come into its own. So I decided to give it a good, solid evening of testing.

So without further ado, let’s run through some of the most prolific components that grabbed my attention, for better or for worse.

The Navigator

The navigator, with its nested and collapsible tags, is something MacRabbit absolutely did right. Adapted from the popular CSSEdit, it really does make combing through your code quite less tedious. Working in unison with the code folding in the Text Editor (read below), it really does set itself apart from Coda in this respect (that regrettably behaves more like a text editor on steroids than a true, enhanced coding environment).

In addition, the tags are draggable, allowing a user to quickly reorganize the structure of the webpage in a matter of seconds. No longer does a designer have to grudgingly peruse their code. A quick scan, a few clicks, and the structure of the page unfolds before their eyes. This is something Espresso does exceptionally well and is a welcomed addition to any coders arsenal. Additionally, the structure and layout of the navigator are clear, intuitive, and well implemented.

The Text Editor

Code writing is pretty much standard in Espresso. It has all the goodies: Predictive code creation (called CodeSense), spellcheck (which needs to be tweaked as to stick to the text and not so much the code), colour formatting, and current line highlighting (which, like Coda, is implemented very poorly).

It also features code folding: The ability to collapse and expand blocks. This highly simple, yet powerful feature really does make coding a lot less manic. It greatly helps improve productivity by making things manageable. No longer does a coder have to rely on tabbing for organization. With code folding, collapsing and expanding blocks of code is a mouse click away, and makes managing lines upon lines effortless. This feature is a great addition to any web design program in my opinion and really does turn a program into a “true” coding platform, as opposed to an enhanced text editor. I’m a progressive person and see no reason why we have to continue writing code in basic document editors. We desperately need to drive innovation in this area, and I’m glad developers are starting to bounce around with various ways to improve efficiency.

The Sidebar

The workspace doesn’t actually provide tabs, but instead, merely lists items. Thus, the instruction to “drop or double-click files to open them in tabs here” seems somewhat misleading. We all know what tabs look like, yet when I propagate my workspace, I see nary a tab in sight. Either the directions need to be re-worded, or a true tabbing system needs to be implemented (I’d prefer the latter rather than the former). Or better yet, devise a system that can incorporate both listings and tabs, to circumvent the problems of “tab hell” (faced by their competitor, Coda).

Firstly, Espresso doesn’t support active scripting (php, server side includes, etc.) which is actually a pretty big failing if you typically code in something other than HTML/CSS. It took several version for Coda to implement and it’s still very buggy several iterations later. Hoping the guys over at MacRabbit not only provide similar functionality, but do a much better job of it.

Preview doesn’t denote what file a user is currently viewing. An entry in the workspace entitled Preview pops up; however, no clear identification is made between which file is actually being previewed. Moreover, each preview adds another listing under your workspace. In fact, Espresso really suffers from exploiting the sidebar with superfluous listings, or rather entries that perhaps should be presented to the user in other ways. Previews, for example, could be made visible by using an icon rather than a brand new entry in the workspace (similar to the “blue dot” that identifies when a file’s changes have not yet been saved). This would prove to be a much more logical and less intrusive way of handling the task.

Remove Server Settings from the sidebar. Considering the settings are made available using the standard right click (on the server of choice), the extra listing seems rather like an oversight or a bug than an actual, legitimate entry. System settings of any kind should not be mixed with concrete listings (such as user files or in this case, designated servers). Again, we have needless entries in the sidebar.

My biggest criticism of Espresso is certainly the haphazard way the sidebar has been implemented (this version is said to improve on previous versions, which actually frightens me to think what preceded it). A user can select an item from the files list and begin to modify its contents. Once a change is made, the respective file propagates into the workspace listing. I am, however, at a loss why this is the case. Would it not be easier to identify the file using an icon that its contents have been changed (which Espresso currently does) and leave it at that? What benefit does a user gain by propagating the workspace section (other than having newly modified files listed at the top of the sidebar)?

There is, however, one benefit from adopting a list view over a true tabbed system: It remains usable even under heavy file load. Coda’s traditional tabs quickly become irritating and cumbersome to use when multiple files are open. As the tabs compensate by incrementally getting smaller, they also become less and less functional. Organizing the files in a list does workaround this problem, albeit it does suffer from its own set of drawbacks (viz., an unintuitive feel). But ultimately, I am still left wondering why my files are moved up into a workspace? Navigating a list hierarchy doesn’t seem to be a problem, not enough to warrant such a quizzical approach to organizing currently modified files.

The sidebar is basic and tries to keep things simple, but often fails by inexplicably listing items whenever the program wants to communicate with the user. This implementation is either unintuitive to downright senseless. This area is by far the most crippling component of Espresso and is probably the area that needs the most refinement and attention. Sadly, it also draws away from all the things Espresso does so well. It also doesn’t help that the sidebar is probably the most interfaced component of the program, thus increasing its prevalence.

Find in Project (New Feature)

The Find in Project feature is done quite well and certainly deserves a notable mention. It is snappy and lists results using site structure, something that really helps identify location at but a glance. The Coda guys could learn something from this way of implementing find and replace. It is clean, intuitive, and feels quite snappy.

Conclusion

Espresso is becoming one to watch. If I was not already immersed in Coda, I may consider migrating, but at this point, it’s just too early to make the move. However, the new features in v1.1 really brings things together. It still needs work, mind you, and there exist elements that certainly need to be rethought entirely, but at least it’s progressing, and I’d say a solid contender (albeit it a little steeply priced) for anyone shopping around for a design program on the Mac OS X platform.

We’ll see if the updates steam along, or whether the project gets “shelved” again (from my understanding this program is maintained by students, which sadly means time is not usually a luxury). Time will tell. While it may fall short in its current asking price, it seems like the team is at least on the right track. Let’s hope they devote more time to getting this program up to snuff; choice is always a good thing.

I’m sure I haven’t covered everything Espresso has to offer, but it should give you a rough idea of what you can expect from this web development program. Hit up MacRabbit and have yourself a look. You have a 15 day trial should you wish to do your own testing.

After a recent meeting, we finally made the decision to drop support for Internet Explorer 6.0 and its predecessors (IE 5.5, IE 5.0, and IE 4.0). The browser was loosed onto the world on August 27, 2001, shortly after the release of Windows XP. Security firm Secunia lists 142 vulnerabilities, 20 of which are listed as moderately critical. In May 2006, PC World rated Internet Explorer 6 the eighth worst tech product of all time. But the decision to block the browser from our website was not related to security concerns, rather it was strictly to do with its rendering. IE 6.0 consistently broke our layout, and failed to support a number of common protocols that all modern browsers are capable of handling.

If you are one of our very few visitors that still uses this ancient and deprecated browser, you will be greeted with this screen. (Based on our data, less than 1.2 percent run IE 6.0, and no visitors were found to be running IE 5.5 or lower.)

We feel a great weight has lifted off our shoulders. Internet Explorer 6.0 has been around for nearly a decade. It’s about time we here at Szilveszter.ca help put a nail in that coffin. We hope that the one percent of our visitors takes this news as a sign to improve their lives and upgrade to a modern browser. Both Firefox and Safari are two solid choices that adhere to web standards and provide unparalleled security.

Addendum: Interestingly enough, it appears we are not alone. It looks like YouTube and Digg are pushing for the same thing. Why IE Sucks chronicles this and more.

Skip to the break if you just came here to learn about 301 redirects. I frequently check my server logs, looking for problems with my site. But a constant worry are 404s. I belong to several bulletin boards and frequently upload content to a temporary storage repository found on my server. Themes, icons, graphical changes to popular programs and most of what I upload, I don’t often add to my website. Why? Because, quite frankly, I’m too lazy. I also don’t see much worth in packing my portfolio with titbits, or odds and ends. But every now and again, I do manage to put up content and not being one to leave duplicates on my server, pull it from the storage repository mentioned earlier. Sadly, this leaves the links on the boards orphaned. I do go in and try to modify the links, but I’d rather spend my time doing, you know, fun stuff. Yet my concern for my visitors (yes, I love you guys; group hug!) is always lurking, and I don’t want them to be greeted with the dreaded 404: Not Found. So I started to employ 301 permanent redirects.

First thing to do is pull up your .htaccess file (should be placed in the root directory of your website (e.g., /public_html/.htaccess). Open using your favourite text editor and add the following line:

redirect 301 old-url.html http://www.url.com/new-url.html

Where “old-url.html” is the outdated page or link (it can be any link, for example, /tmp/files/pictures.zip) and “http://www.url.com/new-url.html” is the new url. Note that should you have a link with a space in it (e.g., “old url.html”), you will need to place the url in quotations:

redirect 301 "old url.html" "http://www.url.com/new url.html"

It’s that easy. So dig through your logs and do your visitors a big favour. There is nothing more disheartening than jumping to a site, only to be greeted with disappointment!