Web Musings by Alistair Johnson

Javascript - graceful degradation

admin — Mon, 27 Oct 2008 14:13:13 +0000

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

admin — Fri, 24 Oct 2008 13:29:47 +0000

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.

admin — Tue, 23 Sep 2008 06:21:58 +0000

My project involves creating a hypothetical employment website where job advertisers can post job listings and job seekers can search the database of these listings using various search criteria.

Don’t Make Me Think - Steve Krug

admin — Mon, 22 Sep 2008 14:34:36 +0000

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.

Create a clear visual hierarchy – it is of paramount importance to make sure the visual cues clearly and accurately depict the relationship between the items on the page. The more important something is, the more prominent it should be. Things that are related logically should also be related visually. Things should be nested visually to show what’s part of what (eg a subcategory).

Conventions are your friends – the feeling of familiarity that user’s have when they are presented with a web convention is very reassuring. Well-applied conventions make it simpler for users to jump from site to site without wasting effort figuring out how things work.

Make it obvious what’s clickable – this is closely related to creating a clear visual hierarchy and will save the user many wasted mouse clicks.

Omit needless words – “a sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts”. Don’t include words that are just taking up space and wasting the user’s valuable time ! Try to get rid of half the words on a page, then get rid of half of what’s left.

There is much more to be gained from this book. The above points are just those that stuck with me most. “Don’t make me think” is highly recommended reading for anyone interested in web usability and interface design.

References

Krug, S. 2006, Don’t Make Me Think : A common sense approach to web usability, 2nd Edition, New Riders.

Layout Decisions - Fixed, Fluid or Elastic ?

admin — Tue, 26 Aug 2008 07:02:37 +0000

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.

Fixed width:

Pros

Developer more control over layout and positioning.

Cons

Doesn’t make good use of available space. On large resolutions, designs created for 800 x 600 screens can appear tiny and lost in the middle of the screen. Conversely, a design created for a 1024 x 768 screen will cause horizontal scrolling on smaller screen resolutions.
Line lengths and legibility. Fixed width layouts usually work well with the browser default text size. However, you only have to increase the text size a couple of steps before sidebars start running out of space and the line lengths get too short to comfortably read.

when the reader increases the text size, the text will sooner or later may break out of a narrow column and lead to an overlap that can render the page unreadable.

Liquid Layouts:

Pros

very efficient use of space.

the reader will never have to scroll sideways, regardless of his or her monitor size.

Cons

At small window widths, line lengths can get incredibly narrow and difficult to read. However, you can use the min-width css property to prevent the layout from becoming too narrow.

At large window widths (on large resolutions), line lengths can become long and difficult to read. There is a max-width css property but unfortunately ie6 does not support it and ie6 is still too popular a browser to ignore. There are other more complicated potential solutions that exist.

more time and effort involved (and more difficult to get consistent results across browsers)

Elastic Layouts:

Pros

Solve the problem of line lengths becoming uncomfortably long or short

Cons

Layout can become wider than the browser window, forcing the appearance of horizontal scroll bars.

more time and effort involved (and more difficult to get consistent results across browsers)

Hybrid

Pros

can utilise the advantages of each method it uses.

Cons

introduces the disadvantages of each method incorporated

difficult to implement

certain issues can present themselves. For example, if a portion of your page uses fixed-width layout and another portion uses an elastic layout, you may get undesirable results when the user increases or decreases their text size.

In my opinion, if you can justify the extra time and effort required to build a liquid or elastic design, there are significant usability benefits evident. Just be prepared for some long nights, with plenty of coffee as you become acquainted with some glorious browser inconsistencies never encountered before.

References

Jakob Nielsen 2006, Screen Resolution and Page Layout, 26/8/2008, http://www.useit.com/alertbox/screen_resolution.html
Patrick Griffiths 2004, Elastic Design, A list Apart, 26/8/2008, http://www.alistapart.com/articles/elastic
Tommy Olsson 2004, Fixed vs Liquid vs Elastic, 26/8/2008, http://www.autisticcuckoo.net/archive.php?id=2004/07/21/fixed-liquid-elastic
Andy Clarke 2004, Fixed or Fluid you decide, 26/8/2008, http://www.stuffandnonsense.co.uk/archives/fixed_or_fluid_you_decide.html
Budd, A. 2006, CSS Mastery Advanced Web Standards Solutions, 1st Edition, Friends of Ed.

Doctype Declarations - First thing in the page, yet often overlooked.

admin — Sat, 16 Aug 2008 01:58:21 +0000

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.

The Anatomy of a doctype

Lets take a look at a typical doctype declaration and examine each of its components in detail:

The portion simply states that we are beginning a doctype declaration and that the html element is the root element of our page.

The word PUBLIC is referring to the fact that the DTD we’re referencing is publicy available

The string “-//W3C//DTD XHTML 1.0 Strict//EN” is an example of a Formal Public Identifier (FPI). In a nutshell, this outlines details about the DTD and the organisation that owns it (in this case the W3C). The inclusion of EN means that the language of the DTD is english in this case.

Lastly, the URL of “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd” points to the location of the DTD.

Available doctypes

XHTML 1.0 specifies three XML document types for us to use: Strict, Transitional, and Frameset.

Strict DTD - should be used when you want clean markup that is absent of any tags or attributes that exist for presentational purposes. That is, you are able to confine all presentational facets of your page to your CSS.

Transitional DTD - should be utilised when you have no option but to use XHTML’s presentational features because your potential audience may use a browser that does not properly support modern CSS.

Frameset DTD - should only be relied upon when you are using frames in the layout of your page.

In summary, as standards-aware designers and developers we should be striving to use the strict doctype in all of our work. By validating a page with a strict doctype, we have the comfort of knowing we have properly seperated our structure (HTML) from our presentation layer (CSS). We should only be resorting to the transitional and frameset DTDs in exceptional circumstances. Cases such as supporting legacy pages written using frames, or a web page targeted at a mobile device browser that does not support modern day CSS.

I hope this has educated you somewhat in the importance of a correct DOCTYPE and that you can now view the top of your HTML pages in a different light.

References

2008, HTML DOCTYPE TAG, W3C Schools, 15/8/2008, http://www.w3schools.com/tags/tag_DOCTYPE.asp

Haine, P. 2006, HTML Mastery Semantics, Standards, and Styling, 1st Edition, Friends of Ed.

Jeffrey Zeldman 2002, Fix Your Site With the RIght DOCTYPE!, A list Apart, 15/8/2008, http://www.alistapart.com/articles/doctype/