As a web standardista, my first and foremost response is that best practice web standards methodology is to separate content (HTML) from presentation (CSS) from behaviour (JavaScript) in web design. Moving presentation (CSS) to the behaviour layer (JavaScript), which is the fundamental idea underlying Less.js, is therefore something that I would never recommend regardless of any accrued performance benefits.

The benefits accrued through separation of these three layers far outweigh any performance response available by downloading yet another JavaScript file.

Best practice web standards methodology also puts forward the concepts of progressive enhancement and graceful degradation. This means you either start with the idea of building a basic user experience and enhancing it for those who have better browsers… or you build better users experiences that degrade well for users who have lesser browsers.

The benefits accrued from those two concepts are vital to providing high quality professional experiences to end users of any website. I would call them a baseline. Yes you can do great and wonderful things as long as the intelligence is in-built to adapt to the unexpected – because the crux of the World Wide Web is that we have zero control over user’s hardware / software / settings.

Even if the argument that only 5 per cent (or 1 per cent) of web browsers had JavaScript disabled that would equate to many millions of people on the World Wide Web. Add to that percentage the still huge numbers of lower end mobile devices, particularly when you look at developing economies. So I’m far from sold on the idea that everybody has JavaScript enabled.

For example, 10-25 per cent of screenreaders are JavaScript disabled. [This statistic simply serves as an example that we can never strategically take 'JavaScript enabled' for granted in our work.]

I’ve probably got other more technical questions… but I needn’t go further within my rationale. This is a smart solution using the wrong tools based on unsound assumptions about user capabilities. I have enormous respect for Dmitry and his capabilities but on this one I have to disagree. Less.js isn’t a CSS obsoleter by a long margin.

The reason I am writing this article and stating my opinion (comments off) is that I think its an unhealthy mindset for other developers to emulate. We’ll just have to agree to disagree, I guess.

Update: 21 June, 2010
If I asked you this question then – would you build a JavaScript main navigation on a website assuming that everybody has JavaScript capabilities? Or a JavaScript shopping cart on your ecommerce website? I think we’re having the 2003 DHTML conversation again.

Google has announced that Page Speed will be Factored into Google Search Rankings because it affects psychological outcomes of users and business outcomes – bailout rates and damage to perceived credibility. Google is telling web professionals the way forward is to discard our delusional worldview of a broadband utopia and face the facts.

WebSiteOptimization.com state the average web page size tripled between 2003 and 2005 from 93.7KB to 312KB with some home pages reaching 4MB to 10MB. While the average number of objects called on web pages in that period grew from 25.7 to 49.9 creating an object overhead cost.

In my opinion this is absolutely crazy at a time in technological history when mobile web browsing has begun to skyrocket. If devices like my kick arse desktop with 2GB RAM and a reasonable graphics card over an ADSL 2 connection in an inner city suburb find the web slowing down – then what about these guys? Mobile devices like smart phones? And dare I suggest the iPad, yes the iPad which is now a giant on our web design radar, might be an evolution? And what about non-broadband connected users?

The direction of innovation is arguably in mobile application not bandwidth consumption – examples like the rural cell movement in India and Eko banking in Africa.

What about the growing markets of Asia and Africa which may have a predominantly hand-held consumer because setting up mobile is a lot easier and cheaper than running a gazillion miles of fibre optic cable around China?

The question is whether web developers and designers are willing to start pulling their heads in on this topic.

Web professionals need to come back to the basic premise that a large part of our skill is in making design decisions that compromise between size and speed in our products. Its not about whether the designer’s portfolio meets a Hollywood expectation – projects are about meeting business outcomes including usability, accessibility and conversion of bums on seats to revenue / eyeballs / relationship buy-in.

If you happen to work for a manager or a team leader who is pushing 1MB web pages down your throat every day take this information to your next meeting. Large pages won’t meet the future of the web. The future is more mobile than desktop.

If my business was related to web technologies I wouldn’t hire OR work for anybody who didn’t understand that environmental reality. Google is just tapping on your office door telling you something similar – less is more, build smarter and faster websites.

Text Books – Management

• Fundamentals of Management (Pacific Rim Edition) by Danny Samson and Richard L. Daft
• International Business: Managing in the Asia-Pacific (3rd Edition) by Greg Fisher et. al.
• Strategic Management: Competitiveness & Globalisation (Asia Pacific Third Edition) by Hanson et. al.
• Cold Steel: Lakshmi Mittal and the Multi-Billion-Dollar Battle for a Global Empire by Tim Bouquet and Byron Ousey
• Managers and the Law: A Guide for Business Decision Makers by Lynden Griggs, Eugene Clark and Ian Iredale
• Essential Foundations of Economics (4th Edition) by Robin Bade and Michael Parkin
• Accounting 4: An Introduction by Atrill et. al.
• Principles of Managerial Finance by Gitman, Juchau and Flanagan
• Organisational Behaviour on the Pacific Rim (2nd Edition) by Steven McShane and Tony Travaglione
• Organisational Behaviour (5th Edition) by Robbins et. al.
• Marketing Principles & Best Practices 3e (International Student Edition) by Hoffman et. al.
• Internet Marketing: Strategy, Implementation and Practice by Dave Chaffey et. al.
• Human Resource Management: Strategies and Processes (5th Edition) by Alan Nankervis, Robert Compton and Marian Baird
• Writing for Journalists (2nd Edition) by Wynford Hicks et. al.
• Editing Made Easy by Bruce Kaplan

Text Books – Computing

• Artificial Intelligence: Structures and Strategies for Complex Problem Solving by George F. Fluger
• Operating System Concepts (7th Edition) by Silberschatz, Galvin and Gagne
• Your UNIX: The Ultimate Guide (2nd Edition) by Sumitabha Das
• Data Communications and Networking (4th Edition) by Behrouz A. Forouzan
• PHP and MySQL Web Development (2nd Edition) by Luke Welling and Laura Thomson
• Java Software Solutions: Foundations of Program Design (3rd Edition) by Lewis & Loftus
• Data Abstraction and Problem Solving with JAVA: Walls and Mirrors (International Edition) by Frank M. Carrano and Janet J. Prichard
• Data Structures and Algorithm Analysis in C (2nd Edition) by Mark Allen Weiss
• Object-Oriented Software Engineering: Using UML, Patterns and Java (2nd Edition) by Bernd Bruegge and Allen H. Dutoit
• The C Programming Language (2nd Edition) by Brian W. Kernighan and Dennis M. Ritchie
• Computer Confluence: Exploring Tomorrow’s Technology (IT Edition) by George Beekman and Eugene J. Rathswohl

Text Books – Not Mine (But Read)

• Management Information Systems: Managing the Digital Firm (International Edition) by Kenneth C. Laudon and Jane P. Laudon
• Electronic Commerce: A Managerial Perspective 2006 by Efraim Turban et. al.

Non-Fiction Purchases (Web Development)

• Designing with Web Standards by Jeffrey Zeldman
• The Zen of CSS Design by Dave Shea and Molly E. Holzschlag
• Transcending CSS: The Fine Art of Web Design by Andy Clarke
• Bulletproof Ajax by Jeremy Keith
• DOM Scripting: Web Design with JavaScript and the Document Object Model by Jeremy Keith
• DHTML Utopia: Modern Web Design Using JavaScript and DOM by Stuart Langridge
• The PHP Anthology: 101 Essential Tips, Tricks & Hacks by Davey Shafik et. al.
• Core MySQL: The Serious Developer’s Guide by Leon Atkinson

Non-Fiction Purchases (Other)

• Sketching User Experiences: Getting the Design Right and the Right Design by Bill Buxton
• Here Comes Everybody: The Power of Organizing without Organizations by Clay Shirky
• Monkeyluv: And Other Stories on our Lives as Animals by Robert M. Sapolsky
• Confessions of an Eco-Sinner: Tracking Down the Sources of My Stuff by Fred Pearce
• What the Dog Saw: And Other Adventures by Malcolm Gladwell
• Outliers: The Story of Success by Malcolm Gladwell
• The Limits of Power: The End of American Exceptionalism by Andrew J. Bacevich
• The Accidental Guerrilla: Fighting Small Wars in the Midst of a Big One by David Kilcullen
• No Standing Only Dancing: Photographs by Rennie Ellis, National Gallery of Victoria
• Impossible Nature: The Art of Jon McCormack by Jon McCormack et. al.
• The Fabulist: The Incredible Story of Louis De Rougemont by Rod Howard

Electronic

• Blue Planet Run: The Race to Provide Safe Drinking Water to the World by Rick Smolan and Jennifer Erwitt
• The Public Domain: Enclosing the Commons of the Mind by James Boyle
• Remix by Lawrence Lessig
• The Future of Ideas by Lawrence Lessig
• Code: version 2.0 by Lawrence Lessig
• Web Form Design: Filling in the Blanks by Luke Wroblewski
• Mental Models: Aligning Design Strategy with Human Behaviour by Indi Young
• Build Your Own Ruby on Rails Web Applications by Patrick Lenz
• The Art and Science of CSS by Cameron Adams et. al.
• The Principles of Successful Freelancing by Miles Burke
• How to Make a Book by the Blurberati
• Street Photography for the Purist by Chris Weeks
• The Photoshop Anthology: 101 Web Design Tips, Tricks and Techniques by Corrie Haffly
• Tribes: We Need You to Lead Us by Seth Godin
• The Dip by Seth Godin
• 99 Cows by Seth Godin
• Bootstrapper’s Bible by Seth Godin
• Unleashing the Idea Virus by Seth Godin

Fiction

• The Collectors by David Baldacci
• Hannibal Rising by Thomas Harris
• A Most Wanted Man by John LeCarre
• All the Colours of Darkness by Peter Robinson
• Red Rabbit by Tom Clancy
• The DaVinci Code by Dan Brown
• Velocity by Dean Koontz
• The Darkest Evening of the Year by Dean Koontz

An article by Drake Bennett in the Boston Globe titled Easy = True discusses a number of research papers about the psychological importance of cognitive fluency. Its a term that basically means we like things that are simple to absorb (with a lower cognitive load) and we dislike things that are more difficult (a higher cognitive load). It means Don’t Make Me Think! as Krug would say. It means we prefer rhymes, we prefer cognitively fluent situations and are automatically wired to be suspicious of the cognitively disfluent and the incongruous.

Anybody who has read about usability or web design probably has a decent grasp of the concept behind cognitive fluency. However, the really interesting part of Bennett’s article on the Boston Globe revolves around the use of cognitive disfluency, rather than its positive relation. Because if disfluent things make us stop and think, and the research supports this assumption, then we can include elements of disfluency within our design to affect the stop-and-assess reaction with site users that may be appropriate. So rather than simply making it simple-for-stupid we can say that sometimes making it not-simple-for-stupid is the right approach; if only to slow stupid down with an increase in cognitive load. Purposeful slowing down may lead to less intuition-based errors on certain tasks that stupid needs to consider.

With the number of research papers mentioned in Easy = True I would recommend you took the 10 minutes to engorge yourself within the content of the entire original article. I’m not sure that I would do Bennett’s journalism justice in a fast-and-dirty blogger’s condensation for the masses. I simply wanted to point to the flip side of Steve Krug’s Don’t Make Me Think! with a second of thoughtful pause – unless you need to make me stop and think.

Sometimes increasing cognitively load might be an essential element in effectively affecting the user’s desired response. Which is pretty cool, in a way. While its no excuse to make things complicated to be cool, it does lead to more intelligent solutions.

Seriously, the World Wide Web is only around 6,000 days old. Its one of a number of applications which run on the Internet, a global backbone of ad-hoc servers and routers owned in the most part by private entities. Only a year or two ago the web was still basically locked into the keyboard and mouse for interface interaction but the mobile web hovered on our peripheral vision like a pimple waiting to pop. It became a small boil; then a carbunkle. Enter the iPhone and as Miles Burke at the Sitepoint Tribune points out, a recent Nielsen survey states that the most common Internet connected mobile device is the iPhone.

Enter the iPhone’s touch screen. Interaction designers had begun making real breakthroughs because technology has provided the ability to push the boundaries beyond the keyboard interface. Now we’re seeing the iPad and there are apparently some interesting touch screen technology patents that make it clear the interaction experience will be much more sophisticated than just a larger iPhone. OK we’re talking iPad version 1 – its still early days to build on product specifications and capabilities. Its less a computer and more of a media experience device – lean, mean and specialised.

As Miles Burke mentioned, we’re not looking at the 800 x 600 or 1024 x 768 resolution landscape anymore. We can’t guarantee our website users are running on any particular hardware / software configuration. What screen size they use depends on the context of their situation – desktop, laptop, PDA, mobile phone, iPad (and the list will only grow more interesting). This means, as web developers, we’re going to have to raise the interaction designer on our team from the bottom rung right up to the management level. Why? Because for successful web solutions to happen it will take more than a programmer and a graphic designer to create classic websites.

The key to the issue is context. How your website interacts with a user will be entirely different when they are on a bus using a PDA than when they are in a cafe using a laptop. Different types of users will use different devices. The iPad, for example, will introduce its own capabilities and expectations onto the market.

The real excitement of web design and development into the next decade isn’t that we’ll get some fancy new technology. Its that gesture and context will converge on a world we currently think of as buttons and static screens. Its time to start rethinking the construction of our web teams to consider these new competencies – that is, if you want to be successful.

What brought me to read Sketching User Experiences: getting the design right and the right design by Bill Buxton was an IXDA Keynote Bill Buxton did several years ago. The audio is still available but unfortunately the video has long since failed to work. Nevertheless it was solely on that conversation with interaction designers that drew me to this book.

If any of you have heard Bill speak you will quickly notice that the presentations complement his writing and vice-versa. The passion Bill has for fostering innovation in the business context drums through from start to finish with some invaluable ideas along the way. It challenges the reader to rethink a few essential components of your own methodologies and you will no doubt recognise many of the frustrations and issues incumbent in the teams you’ve already worked alongside. Because its through fostering innovation and daring to fail that great products are made. Too often we fall into the box of comfortability, we start to code on the first day alongside design… not a great outcome.

Also fundamental to the concepts in this book is the term sketching – not meaning pencil sketching so much as ideation sketching. Cheap, fast, to the point design experimentation. You’ll need to get your head around the difference between sketching in this context and fast prototyping along with the literacy to distinguish when each is useful or redundant. And ultimately you have to shift your perception of what we do – for example as software developers and web designers – from product creators to experience designers. Because the whole ballgame starts to change when we rethink our definition…

Another key takeaway from this book is that Design (with a big D) is about exploring multiple paths throughout ideation – not to be confused with prototyping and developing around a core single branch. We most often get caught up in the latter. Design is about finding solutions to problems rather than trying to fit something to a pre-determined path… simply get pen and paper, get fast and cheap materials to test ideas and do so way before you ever write a single line of code. Things are cheaper to fix and will wind up as better products if you think through the questions and obstacles before committing to the implementation. But that should be obvious…

The next time you’re challenged with a web solution and are tempted to start coding templates I dare you to ask yourself this question – what experience do you want a user of that website to take away? I don’t mean how should it look aesthetically, nor what type of shopping cart should be utilised or the flavour of JavaScript interaction. Simply, if you don’t understand the experience you’re designing then you probably aren’t designing. In fact, I have to say there has been very little actual experience design in my presence in any of the teams that I’ve worked beside.

So I like Bill Buxton’s worldview of design and it runs alongside many of the thoughts I’ve taken away from projects. I think that’s the appeal of his work in Sketching User Experiences – I think we all know there are flaws in how we’ve been operating. The bigger the business it seems the bigger the stagnation and fear of risking failure.

Were I to be running a business at present, whether or not it was a software enterprise, this book would be available for all staff to read. Because its about a way of doing business as much as a way of making software. For those in the business of designing anything – its about the experience… you don’t design mountain bikes do you? No, you design that feeling that a biker gets hitting the bottom of a big hill and rushing through the shallow stream with water spraying everywhere. This is how we should be looking at everything… from the experience outward.

Two small criticism that I would put forward are (a) the small font size: at times and in some circumstances this was a little difficult to read; and, (b) four or five images were missing so that a caption appeared on an empty page. However, the book itself is a catalyst for new ways of thinking about what we’re out to achieve. Or are they the old ways?

I hope you all read Sketching User Experiences: getting the design right and the right design before the year’s out and we see some awesome creativity as a result.

Update: 9 January, 2009
You might find Bill Buxton’s 25 minute day one keynote Sketching User Experiences for MIX09 worth watching.

Not only aren’t all buyers the same – a single buyer isn’t always the same buyer. Now that may be a new idea to some people so consider what I said for a minute. When you walk around as a buyer you are not always the same buyer. In fact, as the context changes your intentions, reactions and perceptions change too. Seriously, when you get your head around that small anomoly things can get interesting.

Take a walk with me for a moment. I’m off Christmas shopping and I buy a toy for a child. What do you think my expectations are for this experience? How much money am I prepared to spend? Is brand important to me? What amount of time am I willing to invest? I’m a buyer of children’s toys. Then I leave the toy store and enter the bank because I need more cash. As I do so my buyer hat changes from the toy store buyer context to the get-money-out-of-the-bank context. My expectations change, the amount of crap I’m willing to tolerate changes, the relationship to the money transaction alters and so does the time I’m willing to invest. I leave the bank and go to a pub to buy a few beers. Again, with the change of context the buyer behaviour and associated paradigm changes along with it.

Given that we’re now aware – how does this inform our work as web designers? I’m not entirely sure. But we have to be able to get our head around who our buyers are and the context they’re responding to… a buyer isn’t just a buyer. A buyer on a desktop computer moves to the iPhone and his context changes… his buyer hat alters to something quite different. His task may have been to order restaurant tickets… as the buyer moves through the door of the restaurant he changes again. Just like somebody on holiday is a different buyer to somebody who is on their way home from work; we can be both buyers.

Designing solutions for human beings isn’t about making generic containers with a one-size-fits-all strategy. For heaven’s sake, one-size-doesn’t-fit-one very snugly. Maybe we need to spend more time thinking about the context of a buyer… and build solutions from there.

Gerry McGovern poses a very good argument based on real life experiences in his recent article When online is better than face-to-face. In fact, as any good expert will tell any layman about anything important – the answer is it depends. Sometimes face-to-face is better, and sometimes its the computer interface.

In Gerry’s example, he urgently needed to fly his family across the country and their tickets hadn’t been processed so how were they going to make it? Repeated requests to the human-interface airline employees failed to obtain any tickets – they were told none could be obtained. Then Gerry got online and purchased the tickets via the Web in a round-a-bout way and at some expense, but the tickets were obtained. He asks, which was better in that context? The human interface, or the web interface?

So don’t let anybody tell you that your job as a web designer is making second rate interaction solutions in some less real version of the work world. You create experiences. You create the tools which allow people to create experiences. Taking that to heart, how will that new knowledge affect the way you design for that user? There’s a question for you… because that user is looking for an expedient solution, not necessarily the prettiest one or the one with bells and whistles.

The real trick with interface design is understanding the motives, abilities and context of that user. When does your website offer an advantage? That’s its purpose, by the way. Run with it.

In fact a published interface design expert with a PhD and a tome of credibility told me in frustration that we need to train people to use the metaphor correctly. Needless to say, I was floored by that idea. He had no idea that I’m a window maximiser. The idea someone can even arrogantly tell me how to use my computer display is something I found immediately offensive.

Of course, were you to design websites in such a way as to provide my maxed out window an unpleasant experience what would be my response? Would I start using the windows paradigm as it was intended – or would I vote with my feet and never come back? Hey that’s a simple answer, yes I’d be gone for sure.

What does the windows metaphor really mean? Well I suggest that it means whatever the individual using it at the time intends it to mean in the context of their worldview. Its the ultimate challenge of web design. Not only can’t you dictate what size monitor or resolution that the consumer of your product uses, you can’t even dictate what proportion of that display they use for viewing your page. It’s something to think about seriously… are your expectations guiding your work? Or are you creating something malleable and flexible and resilient to the challenges of the medium?

Its an interesting article because rather than discuss the finer technical esoteric points of W3C specifications – just enter a debate on serving XHTML 1.0 as text/html and you’ll get what I mean – Jeffrey is discussing design of the specification. Its a bigger picture concept. Because, and he’s correct, if something is too complex for the common person then the specification is not going to be used by the common person. Does the web work because of an elitist .001 percent of developers crazy enough to troll the tomes of standards? No. It works because its simple to use and any nonce can get a website up without much drama.

Draw a horizontal continuum line across a piece of paper… somewhere on the left side you will have a point called the person’s ability where they have the skills and knowledge to achieve a given task. Then draw further to the right another point called the point of complexity which is the true state of the task they need to be able to achieve. Between those points lays the knowledge gap – the place where all those usability issues and accessibility issues and so forth cause users problems.

As a designer, our job is to bridge the knowledge gap for the user of the design so they hopefully experience as small an obstacle as possible. That’s good design. If we’re good at what we do then the user of our design does not even notice the gap at all. When that happens we’ve abstracted away the complexity of the problem through design. That’s the whole point of design, and it should probably relate to the way we look at designing web technology specifications. Unusable tomes of technical crap are actually going to be pretty much pointless – would you read it? Would you act on it? No. What you need is a concise document of instructions to achieve simple objectives in chunks.

Of course, going back to Professor Bill Buxton in his IxDA 2008 Keynote, this topic came up in the first five minutes. He discusses the threshold of complexity (or complexity barrier) – he points out that any feature which sits above the threshold of complexity does not exist in human terms except for a statistically insignificant few people who don’t count. This is the threshold of frustration for users. And, as designers, we need to be aware of where this threshold of frustration lays so that we can design beneath it.

By the way, if anyone knows where to find a video of Bill’s keynote from IxDA 2008 could you drop a link into the comments. I’ve searched and can only locate the mp3. I find its an incredibly powerful presentation for getting team members onto the same track about design and doing business. After all, we’re designing software when we develop web solutions. Not magic boxes of complexity.