Five Things Web Developers Should Stop Doing

This may not come as a surprise, but I spend a lot of time on the Internet. Whether it’s browsing around for my own enjoyment or diligently working on a web-based application, I end up seeing both the end result and the inner workings of a lot of other peoples’ development work. And while a large majority of design elements are ultimately a matter of preference, there are certain web development techniques and implementation choices that I find myself shaking my head at, and I’d like to address a few of them here. The following is a list of five things that, in my opinion, web developers should simply stop doing.

1 – Including application code and HTML in the same file

Although many web scripting languages are tailored for alternating between application code and HTML by use of special tags, the failings of this architecture become apparent fairly quickly when developing robust web applications. Not only does this inline scripting method create messy, oftentimes confusing code, but it can discourage effective use of functions and introduce difficulty when delegating the roles of designer and programmer to different people who may not share one another’s skill sets. The answer here is to use a templating system to separate the application code from the HTML presentation. Templating functionality is widely available for any web development language, and is an integral part of pretty much any development framework (e.g. Ruby on Rails, CakePHP, FUSE).

2 – Embedding video with a technology other than Flash Full Motion Video

Until Flash FMV became widely available, a common method for video playback on websites involved encoding multiple versions of the same video, then asking the user which player he or she preferred to use (e.g. RealPlayer, Windows Media, or Quicktime). This was always a necessary evil, as developers needed to ensure that the site content was available to all visitors. However, presenting potentially confusing video preference questions to the user can often lead to abandonment, not to mention that encoding, uploading, and linking multiple versions of the same video can be a time consuming process.

Thanks to the introduction of full motion video capabilities in Adobe Flash, which has shipped alongside the most popular browsers for several years, developers now have some level of certainty that at least one video player will be available to the majority of users. Additionally, Flash FMV prevents the need to spawn an external application for playback, which is another scenario that can lead to abandonment if the site visitor is unsure of how to answer their browser’s security questions.

Although sites such as YouTube have unfortunately given many people the impression that Flash FMV is only capable of low quality videos with poorly synced audio, this is simply not the case. Adobe has even launched a “Flash HD gallery” (available at http://www.adobe.com/products/hdvideo/hdgallery/ ) that showcases Flash’s HD playback abilities. However, most embedded videos (news clips, etc) are short, small clips that download quickly, so even a medium or low quality encode will suffice. If your specific needs dictate that you must leverage the more advanced features of players like Quicktime or Windows Media, then you will have to use what best suits your end goal, but otherwise, stick with Flash.

3 – Implementing Flash pieces that introduce custom UI elements

Flash is a phenomenal addition to any developer’s toolkit, and well designed Flash pieces can significantly enhance both the aesthetics and functionality of a website or web-based application. However, one thing that many Flash developers fail to steer clear of is overusing Flash where it’s not necessary, to the point of introducing custom user interface elements that can end up hampering usability. As an example, consider something that’s unfortunately fairly common – a Flash-based block of text with a scrollbar that is also implemented within the Flash piece itself. Not only is this an unnecessary use of Flash, since the same effect can be accomplished with fairly simple CSS, but you may be alienating visitors who simply aren’t tech savvy enough to adjust their understanding of the browser’s UI elements on the fly. It may not be apparent to some users that they’re even looking at a scrollbar, especially if the bar is stylized or implemented in such a way that it doesn’t behave like the standard scrollbar. Your visitor is used to the way their browser functions and how they use its features to browse the web, so your best bet is not to alter basic UI elements.

4 – Using long query strings where they’re not necessary

Most web applications rely on the URI’s query string to bring in relevant data that is acted upon by the application code, but poor design choices often cause the query string to grow to unreasonable, unnecessary lengths. Long query strings can severely hamper the ease with which users can link to particular pages on your site, so you could very well be losing visitors because they didn’t quite get the full query string when a friend copy & pasted it over to them.

The first thing to do to clean up your query strings is simply to use small identifiers for both variables and values. Try to use numeric IDs instead of long text strings to identify a specific resource, and keep your variable names short. You should also avoid passing data that could easily be extracted from data you already have. For instance, don’t pass both an item name and item id through the query string – you can just pass the item id and pull the name from the database.

If you want to go a bit further in cleaning up or even eliminating query strings, look into URI rewriting. URI rewriting is a fairly simple process by which the friendly URI the user sees (e.g. /Blog/2008/01) is transparently translated into something more useful on the server side (e.g. blog_list.php?year=2008&month=01). Nearly all Model-View-Controller frameworks (Ruby on Rails, FUSE, CakePHP, etc.) have advanced techniques for rewriting the URI on the fly.

5 – Sizing images by means of the width and height attributes of the img tag

This one should be a no-brainer, but I still see it fairly regularly. While it’s quick and easy to force an image down to certain size by using the tag, you’re doing yourself a disservice in at least two ways by utilizing this technique. The first problem with this method of image sizing is that web browsers aren’t particularly good at shrinking or enlarging images. The browser doesn’t do any kind of resampling, so you often get a pixelated version of your original image, even when shrinking it. The second issue with sizing images by way of the browser is that you may be wasting a lot of bandwidth. An image that’s 1000 pixels by 800 pixels has a much larger filesize than one that’s 200 by 160 pixels, so if you’re forcing it to appear at the smaller size anyway, you’d be transferring a lot of extra data for no reason by resizing it on the client side. To resize images to the size you need, use any of the widely available free tools or websites that allow you to do so.

So there you have it – just a few things I’ve seen during the course of my Web travels that I personally think should be done away with. Especially as development trends continue to shift toward more user-friendly, AJAX-enabled “Web 2.0” applications, it’s important to remember to leave behind techniques that, although familiar, have either been deprecated or were never great ideas in the first place.