Javascript - graceful degradation
Tuesday, October 28th, 2008 | javascript | No Comments
In the context of javascript, ‘graceful degradation’ involves ensuring that your site will still function for users that do not have javascript enabled. After reading a plethora of pro web standards literature and books such as Jeremy Keith’s DOM scripting, the importance of graceful degradation is drilled into your mind. When I commenced my project this semester, ensuring graceful degradation was a high priority.
However as I have read more web development material and tested many of the world’s largest sites with javascript disabled in my browser, it has become apparent to me that not everyone in the web development community considers graceful degradation important.
Over time, my opinion on the matter has also relaxed somewhat. Sure in a ‘web utopia’, every web site would support all possible combinations of browser set ups that a user may have. In reality however, there are other factors that come into consideration. According to the W3Schools website (http://www.w3schools.com/browsers/browsers_stats.asp), less than 5% of browsers have javascript disabled. If you are spending a large amount of time and resources ensuring compatibility for this minority group, a simple cost-benefit analysis may be useful. You may deduce that the benefit of supporting this minority is simply not worth the added cost of doing so. Especially considering that javascript adoption on all browsers (including mobile devices) is increasing each year. Although we may be passionate (and stubborn) about web standards issues like graceful degradation, sometimes it is necessary to sit back and consider other factors before making such decisions. If you agree, disagree or have any other thoughts on matters like this, please feel free to comment.
My favourite Firefox extensions
Friday, October 24th, 2008 | Uncategorized | 1 Comment
I thought I would share with you a summary of the firefox extensions that I have found to be invaluable for work on my project this semester (in order of usefulness) :
Firebug
This is the ultimate firefox extension for any web designer/developer. It’s functionality includes:
- Inspect and edit HTML & CSS – firebug allows you to easily scan through your html source code and CSS and make changes on-the-fly. This is a great way to make test minor changes to your html and css to see the effect immediately, without the need to change the content of the actual files. In addition, if something in your page doesn’t look right but you can’t locate the required css or html in your code, simply hover over the offending element in your page and firebug will instantly display the html and css relevant in that context.
- Box Model shading – as you hover your mouse over an html element, firebug will display the elements margin, padding and content in different colours on the page. It’s a great way to visualise the effect of margins and padding on different elements.
- Debug and profile javascript - Firebug includes a powerful JavaScript debugger that lets you pause execution at any time and have look at the state of the world. If your code is a little sluggish, you can use the JavaScript profiler to measure performance and find bottlenecks fast.
Web Developer Toolbar
Thanks goes to Alastair for recommending this extension. Among other things, I find It most useful for:
- outlining elements on the page to assist with alignment and/or padding issues.
- Providing a ruler so that I can get a general idea of the measurements I have to work with for various elements, divs and images
- providing a quick link to conduct html and css validation of the current page
- a menu to resize the viewport to a set of common screen resolutions (this was particularly handy as my final project uses a liquid page layout and needed to be tested at various resolutions)
- the option to quickly disable javascript, so that your site’s functionality can be tested under circumstances without javascript available.
FireFTP
This is a really nice lightweight ftp program that presents a really simple intuitive interface for your ftp needs. No need to download a stand-alone ftp program when this simple extension will fulfill most people’s requirements.
UrlParams
This extension will show any GET or POST parameters that are sent between pages of a website. I found particularly helpful when testing the functionality of the forms on my site and useful in debugging any unexpected form behaviour.
Livehttpheaders
This extension will display all http header information as you browse a website. Although not very important within the scope of this course, it helped improve my my understanding of how http operates.
If you have not played with any of the aforementioned extensions, I suggest you give them a try. They can really improve your productivity and general understanding of internet technologies.
Form validation using javascript, liquid css layout, mysql search queries.
Tuesday, September 23rd, 2008 | Uncategorized | No Comments
Don’t Make Me Think - Steve Krug
Tuesday, September 23rd, 2008 | usability | 2 Comments
I’ve recently finished reading Steve Krug’s web usability book titled “Don’t make me think” and thoroughly enjoyed it. I thought I would share some of the points the author made that resonated with me most:
Common sense – much of web usability is just common sense. “Like a lot of common sense, though, it’s not necessarily obvious until after someone has pointed it out to you”. In a nutshell, web usability should be focused on ensuring that a person of average ability and experience should be able to use your site with minimal frustration.
Don’t make me think – this is Steve’s first rule of usability and is the overriding principle when deciding whether or not something works or doesn’t in a web design. When a user looks at your page, it should be self-evident, obvious, self-explanatory. They should be able understand it without expending much effort thinking about it.
Web users don’t read pages, they scan them – it is a well-documented fact that most web users tend to spend little time ‘reading’ web pages. Instead, they scan them browsing for words, phrases or icons that draw their attention.
Users don’t make optimal choices. They take the first reasonable option – It’s best not to assume users will scan the page, consider all of the available options and choose the best one. In reality, users don’t choose the best option, they choose the first reasonable option. The reasons for this ? Web users are usually in a hurry, there’s not much penalty for guessing wrong and weighing the options may not improve our chances.
Layout Decisions - Fixed, Fluid or Elastic ?
Tuesday, August 26th, 2008 | css | No Comments
When you commence the planning of a web project, many of your first design decisions will be related to your page layout. Essentially, you will need to decide to incorporate one (or any combination) of the following design styles:
- Fixed width - A fixed-width design is one in which the widths of the pages elements and various components are defined in an absolute unit of measurement (almost always pixels). The main characteristic of such pages is that the user cannot adjust the width of the page elements, either by resizing the browser window or by changing the text size. Despite this, fixed-width layouts are still the most common in practice.
- Liquid – a liquid (or fluid) design is characterised by the width of all page components being specified as a percentage of the user’s viewport width. In other words, liquid layouts scale in relation to the browser window. If the user makes their window wider or narrower, the design will adapt.
- Elastic – an elastic design works by setting the widths of page elements relative to font size rather than browser width. This layout will expand or shrink as the reader changes their text size, but will remain unaffected by any changes in the user’s browser window size.
- Hybrid – any combination of the aforementioned layout styles.
There is a plethora of detailed material on the web that gives detailed descriptions of the disadvantages and advantages of each design style. Instead of reproducing that here, I aim to give a succinct summary of what I consider to be the pros and cons of each method.
Doctype Declarations - First thing in the page, yet often overlooked.
Saturday, August 16th, 2008 | HTML | No Comments
Considering this is my first post, i thought what better way to start than with the first element on a typical html page, the doctype declaration (usually referred to as the shorthand ‘DOCTYPE’). Most designers and developers would admit to simply cutting and pasting this crucial snippet of code from an external source without understanding its true meaning or purpose. It is beneficial to have a basic understanding of the DOCTYPE because it can be the source of rendering issues and is often the last place you would look to rectify a problem. A DOCTYPE essentially informs the browser as to which Document Type Definition (DTD) you intend your markup to conform to. A DTD being a specification of the rules and guidelines as to the structure of the markup you write.
DOCTYPE options
In terms of web standards, a DOCTYPE informs the validator which version of (X)HTML you’ve incorporated, and must appear at the top of every page. DOCTYPEs are an essential component of standards compliant web pages: your markup and CSS will simply not validate without them.
In fact, using an incorrect/incomplete DOCTYPE - or no DOCTYPE at all - leads many browsers to render your page in a so-called “Quirks” mode. Essentially, in this event the browser assumes that you’ve written outdated, invalid markup characteristic of the late 90s. To cope with this, the browser will try to render your website in a backward-compatible mode, displaying it as it might have appeared in antiquated browsers such as IE4. This is usually not what you intend and will result in all kinds of problems.