Sticky footer in Firefox 2 rendering issue fixed

I have recently been developing a sticky css footer (position fixed). In Firefox 2 (not 3) when the window is scrolled or resized, the footer renders crazily bad.

To fix this, I added overlay: hidden to the selector. The final sticky CSS:

div#footer {
position:fixed;
bottom:0;
left:0;
width:100%;
overflow: hidden; /* fix Firefox 2 */
}

@media 2008

A quick summary of my notes from @media london 2008:

Information Design by Jefffrey Veen

Turnining Data into information

• Adding meta data to data to aid understanding
• Adding labels
• Adding Visual design
• Beware of overdoing it – like USA Today

History of Data

• John Snow (Dr) - first mashup
• Charles Minard (Engineer) – plotted napoleons battle / troop numbers across a map  – mashup
• Harry Beck (Electrical Druaghtsman) – Tube Map
• All avoided overdoing it but made the data easier to understand
• More importantly it was what Harry Beck left out of the tube map that was more important
• Edward Tufte – coined the term ‘Chart Junk’

People and data

• User needs
• Talk to people – transcripts – pull out tasks
• What are they trying to do (good example: http://www.fsa.usda.gov/haynet/ )
• Use sticky notes – good visual clues – easy to create – visual
• When to talk to people – earlier the better – its cheaper!

Full presentation – http://www.veen.com/data-design.pdf

Writing as source material for web design by Bronwyn Jones

• Film adaptation of a book – first thing is to read the book
• Content should be available up front before design – not as last deliverable
• Writing is to Design as a Novel is to Film
• Some films are not respectful to the book: Golden Compass – becomes ‘folly’ (pretty with no purpose)
• Other films have just ‘filmed’ the book: Rebecca
• Good examples of sites designed around the words: briefmessage.com and alistapart.com
• Characters in a film are users for a web site – design for users
• Good examples of sites designed around ‘characters’: weekendsherpa.com and barrackobama.com
• Think about importance of typography
• Most important SEO is the body copy
• Make sure the ‘tone of voice’ is engaging

Content Management without the killing by Drew McLellan

Common attributes of good CMS

• Clean URLs (readable, reliable, hackable e.g. BBC – user can guess urls)
• RSS
• Open format (Data Storage)
• Customisable acessible admin interface
• Search
• Multi site support
• Multi language support
• Caching
• Web 2.0 (Tagging/microformats)
• User generated content

Types:

• Off the shelf (cmsrevewimatrix.org)
• Blog Management (chirp, wordpress)

Medium CMS

• Mambo
• ExpressionEngine

These offer:

• Hierarchy management
• Workflows
• Management
• Photo gallery, blogs, events
• Versioning

Enterprise Level

• Interwoven
• Documentum
• Vignette

Or build your own

• Django
• PHP
• Ruby

Designing User Interfaces: Details make the difference by Dan Rubin

• How does a design ‘feel’?
• Getting the right balance – too much / too little

Proportion

• Develop patterns for margin and padding
• Good – www.cnn.com/politics (6/12/18px)
• Bad – www.foxnews.com/  (much harder to read)

Typography

• Easy rule of 10 – 5,10,15
• Relative text sizes create balance
• Include margin and padding with relative size
• 9,12,15,18,21,34 etc
• Range kerning or letter spacing
• For headers  – add negative letter spacing – sometimes as little as -1px – this helsp word shaping
• Avoid ‘widows’ – one word on a line

Grids

• Grids are good but you can break out of it
• Good examples www.guardian.co.uk and www.monocle.com/

Texture

• Reality is rarely smooth
• Use of shadows and light effects
• Using photoshop ‘add noise’, layer blending, soft light

Lines and Gradients

• Whiite or black layer ontop of block colour – change opacity
• Always seperate bg colour on different layer  – allows for quick and easy changing
• Layer styles – copy and paste, aim for consistency and reuse

 

 

 

 

onElementReady

Here’s a very quick JQuery plugin for detecting progressively loading elements.

I am aware of Bennett McElwee’s JQuery elementReady plugin (thanks Mr Silver).

After a brief review the above is useful, but restrictive in a key area – ids.

onElementReady hopefully is more defensive and a little more flexible.

Features:

• Element polling does not clear on domReady so that script can be used to check for dynamically created elements.
• Non chainable to prevent overuse (performance consideration).
• Reduces selectors to first element only, to prevent over use.
• Default timeout and polling interval can be overriden
• Checks for siblings to avoid Internet Explorer operation aborted error – many thanks to Lawrence Carvalho

To do:

• Cater for class based selectors in JQuery that return multiple DOM elements (still think this could end up being messy – sorry Adam O)
• Allow chaining?

jQuery.extend({
	/**
	 * Licensed under a Creative Commons Attribution 3.0 License
	 * Rozario Chivers January 2008
	 * version 0.8
	 * http://creativecommons.org/licenses/by/3.0/
	 *
	 * Fire an event when a specified element is created. If multiple elements
	 * are found, only the first element will be used.
	 * @param query {String} selector, can be a class name, id or tag name.
	 * @param callBack {function} event fired when element is created
	 * @param timeoutValue {Integer} optional, exit time in miliseconds
	 * @param pollInterval {Integer} optional, time interval for checking if
	 * 						element is created
	 * @return nothing returned
	 */
	onElementReady: function(query, callBack, timeoutValue, pollInterval) {
		var _pollInterval = pollInterval || 100;
		var _timeoutValue = timeoutValue || 8500;
		var elementPoll = null;
		var elementTimeout = null;

		var endPolling = function(condition, element, callback) {
			if (condition && ( $(element).siblings().length > 0 ||
					$(element).text().length > 0) ) {
				clearInterval(elementPoll);
				clearTimeout(elementTimeout);
				elementPoll = null;
				elementTimeout = null;
				if (callBack) callBack();
			}
		}

		// poll element and execute callback if found
		elementPoll = setInterval(function() {
				var element = $(query)[0];
				// if element exists execute callback and handle IE
				// operation aborted
				endPolling(element !== undefined, element, callBack);
			}
		, _pollInterval);

		// exit if element not found after timeoutValue
		elementTimeout = setTimeout(function() {
				var element = $(query)[0];
				// handle IE operation aborted
				endPolling(element === undefined, element);
			}
		, _timeoutValue);
	} // end onElementReady
});

// examples
$.onElementReady(".test1", function() {alert("onDomSpanThing 1");}, 10000, 250);
$.onElementReady(".test2", function() {alert("onDomSpanThing 2");});

Efficient organisation of UI files

I have seen various approaches to organising the usual assets which make up effective modern user interfaces. Namely they are: XHTML, CSS, JavaScript and images.

A simple way to decrease the amount of code that needs writing on day-to-day basis is to create folder structure which is short and quick to reference.

Personally I am fan of the following organisation for the above named technologies:

c (CSS)
    i
        comp
        head
        foot        

j (JavaScript)
    i
        comp
        head
        foot

i (images)
    comp
        promo
        special
        main
    head
    foot
    buttons

Nothing special here, just the fact that there is less writing to do for referencing images within CSS or XHTML. We are having a ‘lean’ structure to the folders with least amount of writing involved, while images and bigger folders in general are split up into sub folders with meaningful names, making it easy to work out what has been created already and what not.

Mobile web design best practices

While I don’t claim to be a guru on the subject or even had that much experience in this area, I have collated a few links to resources that are a good source of info on the subject for anyone who is interested…

W3C Offers Online Training Course: Mobile Best Practices – The Web Standards Project

I attended one of these e-seminars over a year ago now and found it a great intro into front-end development for mobile devices. The presentation I saw was by Cameron Moll (more on him later…), I’d definately recommend signing up for this especially as it free. Looks like its already booked up now though

W3C Mobile Web Best Practices 1.0

As the webinar above is already booked up it’s probably a good option to check out these guidelines instead.

Mobile Web Design – The Series, by Cameron Moll

As mentioned previously, this guy knows his stuff and there is loads of useful info in this article and basically sums up the W3C seminar he did a while back.

Your mobile device on acid

A test suite allowing you to visually check your mobile browser to see what technologies and techniques it supports.

---

You’ll notice I’ve not covered iPhone (other mobile devices are available) application development here, the reason being that I’m focusing on techniques that allow content to be open to as many devices as possible as per the web standards/accessibility driven approach rather than the “walled-garden”, specific device only option which is more software development than web development in my opinion.

I’ll add further useful links into this post if any good suggestions come through in the comments, cheers.

Image organisation on a large web site

Often overlooked, or not even considered, aspect of making larger web sites, is organisation of images which are to be used as part of the user interface.

Typically, what happens during development process is that the image directory is ‘populated’ in an ad-hoc fashion by developers as they work on building each page, or component for the web site.

Typically, also, the image directory becomes too large and virtually unmanageable, with same type of image starting to repeat itself with an non-standard formatted file name, etc.

This tends to lead to: time waste in finding relevant images, bad organisation and scalability of the end solution, unnecessary double work being done by developers creating same images twice or three times, inconsistent and therefore trickier to maintain and scale upon end solution.

In my experience, following are the good practices when it comes to image creation for large scale web sites:

• Make decisions from the start about which image files types will be used for which purposes
• Assign one person to be the ‘image master’ and keep the images directory nicely organised
• From the very start utilise sub-folders within ‘image’ directory based on some sort of common approach (i.e. based on: project stream, component type, page, etc.)
• Understand from the start which images are likely to repeat over and over and create those in stone from the outset and agree them, if at all, possible with designers, as these can waste loads of time if they need changing later on and they have an impact on CSS files
• Keep the CSS background images in a folder under the CSS directory (such as css/i) or at least in the images sub-folder (such as images/css) as they will be directly associated with the CSS style sheet
• Try and keep a regular check on which images are still required and which are not and mercilessly delete the ones which are not required
• Understand which image types work for web the best and what the advantages and disadvantages are for each file type

Utilisation of back end for UI optimisation

Just came across an interesting post from someone at WSG who mentioned a link to dynamic CSS tool (this one is in PHP, but it could be made in any language).

Essentially it enables the following:

• Fixes browser PNG handling (or non-handling) from the back end, so no PNG hacks are required in CSS or JS and PNGs work
• Compresses CSS/JS via Apache GZip
• Enables dynamic variables within CSS files, with common variable declaration up top for things like color and background-color
• Does browser sniffing and based on the result servers up relevant CSS code (within 1 file!) by utilising include functionality, since the CSS files are now dynamic files

Outcome using this script is:

• Much higher flexibility with CSS and potentially much quicker implementation times and consistency
• Reduction of CSS files by up to 80% via GZip compression
• Possible reduction of JS related browser sniffing hacks and checks as this mechanism could be propagated into JS files nicely as well (one for you JS gurus to comment on here)
• Cleaner, leaner and better quality code, which is potentially much easier for maintenance later on
• Maintaining the use of one CSS file in order to create fewer server calls, which slow down UI performance the most

Comments, ideas, suggestions and additional points are welcome as usual.

Users without JavaScript

I guess nobody really knows the statistics with regards to (non-developer) users who browse with JavaScript off, but here are some reasons for making sure a site’s content is fully accessible without JavaScript.

• Some companies strip JavaScript at the firewall
• Some people choose to turn JavaScript off when browsing a web page to remove annoying adverts and other such mess.
• Many mobile devices ignore JavaScript completely.
• While screen readers do execute (some if not all) JavaScript we may not want them to for accessibility reasons.

I have recently been involved with a project that caches (quite rightly) the page “header” to improve server performance. The header includes:

• user status (logged in or not etc)
• navigation
• shopping basket information (items, value)
• bread crumbs

Some of these parts change per page – to get around the caching issue, these parts are stored in a cookie – JavaScript reads the cookie and builds the components by manipulating the DOM. If the user doesn’t have JavaScript they will have to navigate to the shopping basket page to find out what’s in the basket etc.

I know there is a balance here between server performance and accessibility but this doesn’t feel right to me.

Accessible Image Replacement Techniques

After beginning to write a fresh post with regards to all this I decided to surf the Google and found this article.

In addition I would like to mention SIFR (Scaleable Inman’s Flash Replacement) and what I am calling the “classic <img> element” technique.

SIFR

advantages:

• Maintenance is almost as easy as CSS.

disadvantages:

• The user needs Flash and JavaScript enabled.
• There is additional load on the client, which depending on the number of SIFR instances, can severly increase page load times – you also get JavaScript flicker once the DOM has loaded etc.
• Styling the flash text accurately is quite difficult at times, depending on site design.

For more information see http://novemberborn.net/sifr3

Classic <img> element

An image can be described by it’s “alt” text so why not do something like <h1><img src=”heading.gif” alt=”Heading text” /></h1>.

This will work without images turned on and screen readers will read the alt text. This technique gathers a little fuzz when thinking about SEO (Search Engine Optimisation). I personally have not made/had the time to run 2 identical sites with <h1>Text</h1> vs <h1><img src=”text.gif” alt=”Text” /></h1> to see which one is more dominant (if any) in Google etc but this would appear to be an adequate option keeping the mark-up lean, which is what we love as Interface Developers.

and finally…

If you use an image replacement technique there will be an added maintenance cost and increase the size of the page.

From a purist point of view I would recommend not using any image replacement as I am a firm believer the site can still look great and have clear branding without using image replacement. Now I have just got to convince the client, and all will be wonderful but we know that is the easy bit!

Using CleanCSS to optimise web site performance

In at least one major project which I worked on so far I have managed to successfully utilise CleanCSS within development process. CleanCSS is based on CSS Tidy.

Main reason: it can reduce CSS file size by 10-50% (before GZipping or minifying), without affecting page styles and design in any negative way (if used properly and with understanding of its weaknesses)!

Other reasons for using CleanCSS:

• It’s quick, automated and easily accessible on-line
• It beautifies the code making it easier to read
• It can order properties in alphabetical order
• It highlights invalid CSS declarations bringing about awareness of the overall validity of CSS file
• Can remove CSS comments if necessary
• Support for 5 levels of compression (default being ‘medium’ which is a balance between size and readability)

Known weaknesses:

• Sorting properties can cause problems if IE _ hacks are used within the stylesheet where the tool will put the _ hack first in the declaration order, which is often not desired
• We have also observed it converts zoom: 1 to zoom:1px which is easily rectifiable by doing a search and replace, as are other known problems like the _ hack issue

How to utilise within a team:

There are probably two main ways to utilise CleanCSS within the development process:

Ongoing utilisation would make use of the tool, say, once a week to clean the CSS files regularly and keep them down in size throughout the development process.

I would advise this method as it shows developers throughout the development process how ‘lean’ their development is as well as points out any potential subtle issues with using the tool early on, rather than at the last minute before site launch.

One-off utilisation would mean that CleanCSS would be run on all CSS files just before the launch of a web site in order to decrease CSS file size as much as possible so site can run as optimally as possible regarding CSS.

This means that slightly less time is consumed optimising CSS files regularly and having to remember to use the tool once a week, but it could be a little more ‘dangerous’ as some subtle issues might creep in.

My final thought on the question of ‘do I want my CSS files to be up to 50% smaller in size without jumping through major hoops in order to achieve it?‘. The answer is: ‘Yes please!‘.