Friday, January 25, 2008

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.

11 comments:

Anonymous said...

6. Tables for layout is not the best choice. But it doesn't mean that tables are bad for tabular data. When I see product listings or statistics that looks like tables but are pure CSS I just feel bad for the designer.

Alexander Malfait said...

Just one remark about the "long query strings": I don't think it's bad bad practice to put the title of the page in the link (as in the URL of this bog entry). Lots of people actually look at URLs to determine if they should follow a link or not, so a descriptive URL is always helpful.

Brian Rock said...

I agree whole-heartedly about the separation of php and html. It's easy to integrate the two in small projects, but large projects (or distributed software, like CMSes) should always use a templating system.

I was a bit wary of them at first when I created a site using CMS Made Simple and had to use Smarty, but I quickly realized that it makes it so much easier to re-design templates later on.

Anonymous said...

note about image height and width, if you are using an image then you should specify the exact size attribute (height/width) of the image (nothing smaller or bigger). By setting the size attribute allows the browser to pre-allocate space for the image while loading which is faster than readjusting the whole page to fit the image only after the image is loaded.

Jim Keller said...

>But it doesn't mean that tables are bad for tabular data.

I'm inclined to agree. I'm of the opinion that you should always use the best tool for the job, and for tabluar data, that's tables. I do still find a lot of people trying to make excuses for using tables for layout, but I don't think there are any good arguments for table-driven layouts left at this point.

Also, thanks for reading, everybody!

Anonymous said...

The ONE thing that web developers should do is to avoid Flash like the plague.

Flash is evil. Flash is a huge security hole. Just because 'everyone else is doing it' changes nothing.

When I see a website that 'needs' Flash it is permanently on the bozo list.

Flash is for losers and teenage 'webmasters' who need to go out more.

LOSE THE FLASH

Anonymous said...

> but I don't think there are any good arguments for table-driven layouts left at this point.

Well, you may be right in general and in most of the cases we meet in dayly routine. But doing my job as web engineer for many web designers for many years now, I still come over layouts that are hard to implement in a cross-browser fashion. Mostly, this layouts had been made up by some designer that were not too web-afine. And mostly, one key requirement was exaxt per-pixel replay with various browsers on various systems. Yes, such requirements are quite common if you work for some bigger companies. In fact, most of these layouts could be implemented without tables - if you investigate and try and test long enough ... and at least therefor no customer wants to pay. :-(

This make three probems you might encounter when trying to do EVERY job without layout tables:
1) You run out of time and out of money in some cases ...
2) Some Designers do not care about the technical basics of (X)HTML and CSS - and you are left do fix the mess ...
3) Somebody else demands a layout made by (2) to look the same (each pixel!) with (nearly) any browser on (nearly) any OS ...

I know, these points are not realy good "arguments", but real life sometimes is not as nice as we would like it ...

Anonymous said...

Right on.

I really hate when movies are embedded in something other than Flash. I've had trouble getting some of the other proprietary formats (Media Player, Real Player, etc) working on my Ubuntu machine. Flash works... stick with it.

As for the images, I was surprised at how easy it was to write a php script to re-size images on the fly. It looks better and saves bandwidth over having the browser do it.

Wow Gold said...

WOW GOLD from randyrun. Most cheapest wow gold supplier.More than 10,000 online satisfied customers bears to the fact that we are genuine and fastest wowgold provider!

chicago web developers said...

This is nice blog. I like this blog…
Web Developers Chicago show about SEO Services and Provide SEO Services.

Web Design Cheshire said...

This is nice blog. I like this blog..I agree whole-heartedly about the separation of php and html.Plz give me some suggestion onWeb Design Cheshire.Thanku