Archive for the ‘accessibility’ Category

Revisiting Conway’s Law

Monday, July 30th, 2012

I quoted Conway’s law, not so long ago on this blog:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

But now I think about it, it doesn’t go deep enough, I would add this:

Further to this, any organization with a strong hierarchy (defined broadly) will usually have a communication structure that represents the mental state of the highest node of the hierarchy.

What this means very simply is, in a strong hierarchy, if you have a leader with strong silo-ing of the faculties of the brain, so someone who doesn’t balance well between creative and logic, then you will have a company that separates itself into Silo’s of creativity and logic. If you have a leader that does not learn, then the communication structure will represent that in-ability to not learn by never improving. Conversely if you have a leader that’s for example well organized, or has a strong sense of social justice, then the communication structure of the organisation will be well organized, with good channels from top to bottom to allow the flow of communication.

The google toilet.

Sunday, November 14th, 2010

When I was small I used to have a soft toy puppet version of Gordon the Gopher from TV’s Going Live!

As Gordon was a fairly large part of my then life, I went to all lengths to make sure he was fully integrated into the family. Part of this involved me building Gordon several miniature versions of common house hold white goods. The Gordon sized versions were mainly built from Toothpaste boxes, old sewing thread spools, straws and colored card. He had a washing machine to wash his various different coats, a vacuum cleaner (unfortunately Dyson had not invented his yet so this was just a plain old Hoover style one) and finally, in a fit of reality, racked with concern that he did not have anywhere to relieve himself, I built Gordon a toilet. The toilet was a fairly anatomically accurate recreation. It had a bowl, a cistern, a pipe connection to the cistern, and a small flushing handle.

What does this have to do with anything? Well recently I was lucky enough to come across this:

20100904_0011

What.

What the Fuck is this?

I can hear your brain exploding now.

Yes, that’s right my friends. This image here. This, is the future of toilets. The cisternless toilet.

One must assume that the reason for a cistern, comes from tradition. To get an effective bowl clean, a reasonable water pressure is required. Maybe in the past common households did not have this water pressure available which lead to the design of the high-up cistern, which then was moved down to the low down cistern. But now, in modern days, actually all that’s required is a simple valve to the local water system, that is controllable by the operator.

So where the hell am I going with this?

This problem is a brilliant illustration of a common modern day coding problem. The problem, at the beginning of a project you have certain constraints (i.e. low water pressure), then someone designs a system (i.e. the high cistern) to deal with this problem. Then someone designs a better system (the lower cistern), and then someone else designs a better more efficient but more complicated system (the cistern with two buttons for different flush types). But in reality, all that is needed is time, to wait for the constraint to be resolved, and then careful thought on what is actually needed, in this case, the simplest most elegant solution is just essentially a on/off tap.

This is why I call it the Google toilet, because it’s simple, elegant, robust, easy to maintain and repair, and it does exactly what you need it to do, without complicating the matter by giving you different options and choices to make (do I need a big flush or a small flush? hmm let me evaluate…). It reminds me of a talk on usability given by Aza Raskin of Mozilla:

CSS Pre loaded - avoid FOUC with practical progressive enhancement using JS & CSS inheritance

Sunday, July 26th, 2009

Graceful degradation is an art form. The combination of XHTML, CSS and Javascript have never been one of coding beauty and will never win you any semantic accolades or the adoration of your clients or peers. Yet it is vital. In this day and age, progressive enhancement is a balance point between accessibility, usability and code optimization, on a large site you cannot afford to overlook it. So the question arises, what limited best practice can we draw up to make our lives easier and our products better? This article aims to offer a practical look at a set of technique’s used to help separate CSS and JS, to make apps more easily degradable, and to rid yourself of the dreaded FOUC (Flash of unstyled content).

I am a firm believer in separating out as much styling information as possible from JS to CSS. From a very basic level of having all static file references, colors & dimensions in CSS class selectors and NOT in the Javascript, to more advanced techniques of using CSS classes to control your animations (a feature native to Mootools and built in to jQuery using one of the many plugins). Anything to do with CSS in the JS needs to have a damn good reason to be there, otherwise rip it up, stop it from cluttering your logic code and put it in the CSS.

So to illustrate lets create a basic example of progressive enhancement with a standard tooltip on an element, where the behavior involves a div appearing on rollover.

<div id="links">
	<a href="#" class="tooltip_information">Link</a>
	<span class="tooltip">Something witty about this link</span>
</div>

Now, the basic initial approach may run along the lines of waiting for the DOM to load using a DOM load event, rooting through the DOM and finding all instances .tooltip and applying some CSS styles to them to position them and use the rollover behavior. As follows (all JS written in jQuery syntax) :

$(document).ready(function() {
	$("#links").css({position: "relative"});
	$(".tooltip").css({
		position: "absolute",
		top: "5px",
		left: "5px",
		display: "none"
	}).bind("mouseover", function() {
		$(this).css({
			display: "block"
		});
	});

});

Fine. It’s degradable, it works, but it’s messy and a bitch for anyone else to maintain and bug fix. Lets go through and see what we can clean up. First lets move our styling into the CSS.

.tooltip_Container {
	position: relative;
}

.tooltip_information {
	position: absolute;
	top: 5px;
	left: 0px;
	display: none;
}

.tooltip_information_visible {
	display: block;
}

This makes our JavaScript look like this:

$(document).ready(function() {
	$("#links").addClass("tooltip_Container");
	$(".tooltip").addClass("tooltip_information").bind("mouseover", function() {
		$(this).addClass("tooltip_information_visible")
	});

});

Sweet. Now I know this is a fairly simple example. You may want to have all kinds of fancy ‘fade’ or ‘movement’ effects going on. However this does show you, on a basic level, how much cleaner your JavaScript becomes if you move your style rules out into the CSS. Also, it means if you want to add more style changes, it’s a much easier process with a considerably smaller risk of breaking your JS logic due to missing a comma or semi colon. Consequently maintenance could even be taken over by folks who are less JS savvy, leaving you more time to build the next JavaScript implementation of coverflow or whatever it is UI coders do with their spare time…

Now, here’s where I change the paradigm and flip things on their head somewhat. The previous approach is fine for smaller web sites with limited interactivity, but once you add some other stuff going on and a heavy longer page, you start to run into speed and load time problems doing all these element lookups and events. So what can we do to mitigate these? Well, firstly, rather than using JS to add all these class names let’s leverage the power of CSS inheritance to help us out. Instead of adding a class to elements let’s add a generic one to the body, my favorite name is “JSEnabled”.

$(document).ready(function() {
	$(document.body).addClass("JSEnabled");
	$(".tooltip").bind("mouseover", function() {
		$(this).addClass("tooltip_information_visible")
	});

});

our CSS becomes :

.JSEnabled .links {
	position: relative;
}

.JSEnabled .tooltip {
	position: absolute;
	top: 5px;
	left: 0px;
	display: none;
}

.JSEnabled .tooltip_information_visible {
	display: block;
}

This allows you to deal with multiple JS CSS changes in a much simpler clean cut way and do it quickly in one hit using CSS inheritance, rather than multiple hits using JS to find all your elements. This does wonders for your IE6 load times and allows you to easily test what your site will look like without JavaScript enabled. It also further enhances the ability of others to easily extend the JS/CSS you have written without hacking around inside your precious code.

The final trick or fairy dust mentioned in the introduction is something that has long hampered progressively enhanced online apps. You are trying to build a progressively enhanced site but you’ve got a bit of an overweight lardy DOM, or more likely a poor web connection.
When this happens the DOM ready function just doesn’t cut it and often leads to a nasty FOUC side effect where the non JS page is rendered but the DOM ready doesn’t kick in early enough. Leaving the user with an ugly little animated scene of the page reordering itself to hide all the fun interactive bits - somewhat like the curtain coming up too early on the stage and the audience seeing all the props being put into place.

So how can we detect whether the page has JS capability before the content loads? We can’t just hard code the JSEnabled class onto the body, as this would break the progressive enhancement for anybody with JavaScript turned off. For a short and concise solution - see the following snippet to be embedded in the head of your HTML, before anything else:

var elements = document.getElementsByTagName("html");
elements[0].className += " JSEnabled"

Effectively this add the JSEnabled class to the html tag instead of the body, right at the beginning of the page load, allowing you to take advantage of your JSEnabled CSS right from the word ‘go’. It integrates particularly well with the new frameworks coming out at the moment that allow you to passivly download modules of your JS code post load for secondary functionality to speed up initial load time. But most importantly when the page does first load everything appears where it’s supposed to!

vote it on WebDevVote.com