But before they went down that route I’d have offered some food for thought.

Some Contracts may resemble Toilet Paper

The first point to clarify is the country the contracts apply to… where they were signed… the jurisdiction of any legal resolution – where you have to appear in court if the contract comes to a dispute.There are three major legal systems and they don’t treat contracts equally – Common Law (the British System), Civil Law (the European System) and Islamic Law. Each individual country also has it’s own business context including political risk and economic profile. And specific countries offer unique challenges to doing business that should be considered.

If the contract is Bulgarian then you might have to hire lawyers and attend hearings on specified dates in Eastern European Civil Courts.

On the other hand, if this is an Australian contract then how do you force the Bulgarian web design firm to appear on a given date in the appropriate court in Sydney? And how do you force them to adhere to the Australian court’s judgement? If you were awarded AUD$20,000 damages then how would you enforce that fine in Bulgaria? Or African or Middle Eastern countries? Or the United States where you might be sued on that contract, have to fly to appear with US lawyers and fight an extended and expensive legal battle with huge monetary consequences if you lose.

Were you to have a legal contract with an Indian firm… any court would take between 10 and 20 years to hear the case due to stress on the Indian legal system. You may never see a resolution.

The bottom line is that a contract you can’t enforce or that has you at such a disadvantage is worse than toilet paper to your business. It might lead to your being sued in a foreign country under a different legal system and possibly in another language.

Client Privacy and Security Concerns in a Wire Canoe

The next consideration has to be privacy and security. Were you to send client data (ie. access to database content or client files) to another country then THAT COUNTRY determines the appropriate privacy laws and enforcement. This was true when Telstra sent all of our Australian accounts offshore to Indian call centres exposing their customer base to increased identity theft. If the Bulgarian web firm stole and misused this customer data then it could kill your business.

At the same time the entire infrastructure of the online business is exposed to an overseas business entity that, let’s be honest, you really don’t know anything about. What are their business motivations and relationships? Have they used black hat search engine optimisation techniques? Did they insert malicious code? Are your website visitors going to be installing malware under your name? These cheaper Bulgarian web designers are being provided access to your passwords, file structure, email accounts and sensitive information.

If that isn’t bad enough – what are the consequences if they betray your trust? You could go out of business. You may have no financial capacity to recoup the loss or pay for the damages out of your own pocket. Just as any 60 year old pervert can say they are a 12 year old girl in an Internet chat room… anybody can tell you they run a web design business in Bulgaria.

A Dollar Spent Elsewhere doesn’t turn the Merry-go-round

Believe me, I’ve got an MBA and understand the ideals of globalisation and free trade as much as the next guy. But the reality is that by chasing the budget option off-shore there are hundreds or a few thousand dollars no longer circulating in your local community. That’s a bigger deal than it sounds.

When you spend dollars at the local grocer to buy milk then the grocer can buy shoes for his child and the dairy farmer can buy the newspaper. In turn the shoe seller and the newspaper seller receive their portions of that dollar and can buy goods they need or want for their families. Money isn’t a one-time transaction, it continually renews itself through a community increasing the social value of it’s footprint. Not investing in local talent is shooting your community in the foot – less money attracted for business investment, less money for schools and infrastructure, less money for the merry-go-round of opportunity for your own children.

Because what looks like a good deal – getting somebody to work at $5 per hour – is at the heart of it exploitative anyway. It’s no different than a large company moving production to India to avoid labour laws or safety regulations.

I’m not saying never to outsource overseas… but do it for the right reasons and be prepared to pay the appropriate value for their work. Make that decision with an understanding of the inherent business risk that comes with the decision.

There’s a saying in business – “There’s no such thing as a free lunch.” Whatever decision you make about your web design services be prepared to grab your wallet.

Some Days I Slap my Forehead

However, some days I just slap my forehead and curl up in a ball because I read something like this great sounding inclusive idea… that in my opinion just doesn’t fly. The tweet (author’s name removed) read:

Your portfolio site adjusts for my mobile browser width, great. But for the love of @Zeldman, give me a link to view your normal site!

That tweet was followed up with a reply to my comment tweet that read:

@nortypig To be fair, one can simply add links at the bottom. Default to mobile, fine, but let me access a full-width browser window then.

Things Worth Thinking About Here

OK the reasons why this all adds two plus two to equal three, in my book.

• A “full width browser screen” is not defined
• Normal no longer exists in web design
• This is a demand for an edge case feature
• There is no longer a place for dogma

A “Full Width Browser” is Not Defined

Given that we design solutions that adjust to the user’s context – mobile, netbook, laptop, 17 inch CRT or 27 inch LCD to name a few – and we accept that their context may be sitting in their office, sitting on their sofa in front of the television or walking around the CBD looking for a certain restaurant… we have to admit we have no control. We have to relinquish this idea that we know what a full width browser could be, or even should be.

The only full width browser… or “normal site”… is the one provided to the context at hand. If you are on a mobile phone then you receive the relevant full width browser experience. Otherwise, full width browser screen is ill-defined if only because you can’t tell me how many pixels this empirical Shangri-la becomes?

In the same sense… normal no longer exists. We did have an era where we could rely on two browser sizes falling into normalcy but that is ancient history.

This is a Demand for an Edge Case Feature

But even accepting a worldview of a “normal site” that provides a “full width browser screen” this is a request for an edge case feature. It is also untenable to provide web solutions that attempt to be all things for all people. For example, this cruft link in the footer to appease one or two edge case visitors will be a part of the interface endured by the many – it’s about signal to noise.

This is where we move back to the business case (codified business plan) and revisit the target market segment being addressed by the design. How many people would use this feature? Who are these people and why would they want the feature? How does this translate to Return on Investment (ROI)? How can it be justified by the business case?

The danger of trying to make web solutions that are everything to everybody is that the design won’t be much of anything at all. Design (with a big D) is about compromise, it’s about weighing options and motivations and intentions and opportunities to connect with a specific audience to achieve real world outcomes.

When dealing with edge case requests… even the darlings… be prepared to throw them the .45 colt of goodbye. Even good ideas that are edge cases need the .45 colt solution.

There is no Longer a Place for Dogma

Not too long ago dogma said that all best practice websites should have an accessibility statement. But nobody read them even though they took time (meaning money) and effort to write and maintain. Again, a cruft link hung around the user interfaces that nearly nobody bothered clicking. And if someone clicked the link it probably signaled trouble with the design rather than their desire to understand the website.

And the visitors who clicked the accessibility statement link were usually web designers… and then every site used different access keys and yada yada so the idea that anyone would find accessibility statements useful became less popular. How practical was it to expect people to relearn how to use accessibility features on a site-by-site basis? It’s a dogma we seem to have shot with that .45 colt. Thankfully.

Because Every Web Solution is Unique

The answer is that every web solution is a unique proposition. Some will need an accessibility statement… most won’t. Some will need a link to a wider screen size on a mobile platform… most won’t. But the moment we pull anything in as design dogma with a large permanent marker underline then we’re in trouble. So I don’t know whether someone else’s portfolio might need to provide that link to a larger screen size… I know at this point that my portfolio wouldn’t.

In the words of Jerry Maguire – Show me the money! Then we’ll discuss that feature.

Call me old fashioned but I like to call a spade a spade… not a spade a shovel and a spade a shovel, garden fork, car hoist, jimmy bar and antique musket. To the average person on Earth this sounds like rubbish… as it should.

HTML 5 is now HTML and HTML5 now means HTML, CSS, SVG, JavaScript, WOFF, XML and anything that fits into the area I always understood to be called Web Standards… or what I’d agree to be called the Open Web Platform.

To make that smorgasborg of self-reference even more interesting… like someone spent a little too long on the loo after suspect vindaloo… the W3C is going to be releasing a snapshot of HTML5… which is and isn’t HTML… because HTML will be a live unversioned document that changes over time. Leaving the question… what is the real world use of the snapshot if it’s not the HTML specification?

I do know HTML5 (HTML) is a specification document meant for browser developers and not people like me… but how logistically viable would it be for anybody to read the live HTML specification with reliance on it’s validity even 2 or 3 days later? How do you have conversations about its content? A specification without versioning CANNOT BE RELIED UPON TO BE TRUE AT ANY POINT IN TIME. Because it can change. It probably has changed since you last read any part of it – the wording and / or intent of already complex ideas.

But hey… I’m not a specifications expert. I know my limitations (vomit in a bag would smell better than trolling through W3C specifications in my world). I’m just a little worried about having a versionless live document as a W3C specification because versioning is a fundamental principle of software engineering. Would you like PHP to take that route, or C++ or Ruby or practically anything else you can think of in software? A versionless Photoshop? A versionless operating system?

Not to mention the overall ambiguity of trying to jump on the marketing buzzword of HTML5 as though it can be captured for all time. Buzzwords fade… Ajax became a dirty word in conversations simply because buzzwords don’t mean the same thing in everybody’s mind and can’t be captured in neat little jars like butterflies. At least Web Standards meant something… and if that lost efficiency due to it becoming a buzzword then at least the Open Web Platform is what it says it is – a spade that is indeed a spade.

Its only my opinion but I think the problem is that HTML5 could not contain itself due to the idea that it could be all things to all people through a Utopian democratic approach via a benevolent dictator. The more you offer a greedy child the more they will ask for and expect – which is why HTML5 (HTML) will never be complete. Which is why HTML5 (HTML) has to remain a live document – the alternative would be to say ENOUGH and draw a line across the pages of Hixie’s Empire with a timestamp for approval. And in Hixie’s Empire that was no alternative… all dictators are benevolent until you try to resist.

So that left the term HTML5 hanging in the wind… the pennant of the Empire. The pennant that had been so maligned by marketers over the last few years that it came to mean nothing much at all. “Here’s your HTML5 hotdog, sir, and could I run you a HTML5 bath in HTML5 water”? OK I’m labouring my point.

HTML5, the marketing buzzword, suddenly becomes the official stance of the W3C and the Empire’s benevolant dictator. The pennant flies… all hail the benevolent dictator.

You might think what is happening makes perfect sense. I don’t. My opinion is that the flaw of HTML5 isn’t that it doesn’t end… that’s a symptom of a problem. The flaw is that a never-ending democratic process is a crap way to do complex things. Versioning documentation is important to software. Badging everything up in a marketing buzzword that’s past its used-by-date is counter-productive.

All hail the benevolent dictator. And those who bow with right knee to the ground are either soldiors or the afraid. Yep, that’s what I think. It will be so because Hixie told you… you will like it because you must. That grit in your eye will sting for a moment but you’ll be back on parade before the bell tolls. HTML5 (HTML) my arse. And don’t get me started on that HTML5 logo / tshirt campaign (my arse has its limitations without that same vindaloo).

Contracting versus Consulting

If you’ve read those articles then Jared’s clarification of the hands versus brains metaphor is also essential. Good… now we’re all on the same page, so to speak.

Basically the metaphor runs like this… contractors (the hands) are the guys / girls who get brought in to build stuff – whereas consultants (the brains) are brought into work on strategy. Contractors work with their hands and consultants work with their brains, effectively explaining why contractors generally get paid less than consultants (if you read the final article). Of course, you need to be a master at hands to be good at being the brains. Jared argues the disparity between contractors and consultants is such that you will find it difficult to succeed at both hands and brains simultaneously.

Why you Shouldn’t be Hands and Brains

The first problem is that doing both means you over-or-under charge for one-or-the-other. The second is encapsulated in the following quote:

Doing one basically traps you for that client—once they see you as Hands, you’ll always be Hands to them. Same for Brains. It’s important to make your choice carefully.Jared Spool

This is my Hands versus Brains Situation

I have some experience and knowledge in the field of providing web solutions for clients in the low end of the market. I’ve been a hands guy – freelancer, contractor and in-house web developer. However, my qualifications sheet and Curriculum Vitae have significantly changed my value proposition for clients – I have industry qualifications in web design and web development, a Bachelor of Computing and I am about to graduate with very very strong marks from a Master of Business Administration with a further six month specialisation in Journalism and Media Studies.

I also believe in and practice continuous learning and therefore will continue to up-skill well into the future (on my own dime). For example, I hope to embark part-time next year on a Master of Fine Art and Design postgraduate qualification, rather than pursuing a PhD I’m not really interested in working on at this stage. And if I did another three units part-time I would earn a Master of Marketing (although I may never take that option… but then I just might take it on).So you see my point – am I hands (which I really haven’t been for around two years now)… or am I now overqualified for hands and should become the brains?

I am Probably now Brains Material

Just at a pinch I’d say that hiring me as hands would be a waste of your time and my time… hiring me as brains will get you better bang for your buck. Maybe I should be looking at setting up a consultancy next year, rather than a web design company. But I take Jared’s point… I can’t do or be both services. And to complicate matters, all those clients and employers who have hired me for hands are never going to see me as anything but the hands they previously employed.

I’m left wondering how everyone else thinks about this one – are you happy being hands? Clap if you’re happy OK, I’ll hear you.

One thing that you may not know is that this website looks entirely different in IE6. That’s right, when I last performed a major redesign I said IE6 is going to look different – and not in a bad way. I did this to highlight how simple it is to feed IE6 any corrections… and I did it because I really believe the IE6 haters who just cut this browser off are misguided (even malicious).

Internet Explorer 6 Gets a Different Experience

IE6 is just another browser of many in the web landscape… sophisticated solutions try to overcome this impediment. Lacking a full page screen grabber for IE6 here is a header area screenshot of what IE6 users experience.

The IE6 Footer is also Different

And you will notice that the footer area is structurally and aesthetically different than the ‘better browser’ alternative.

Better Browsers Get a Better Experience

So this website after recent tweaks to the aesthetic (for those reading this in IE6 thinking I’m a mental patient) supports a totally different structural and aesthetic approach.

This Was to Prove Several Points

Developing in Firefox and then fixing IE6 after the fact is not only more logical and economical but you have more power as a designer to achieve a sophisticated solution. You’re basically playing with the shit that falls out of the funnel instead of hacking your way through the development hoping your spaghetti code isn’t too injurious to future maintenance.

Eventually if IE6 doesn’t appear on the commercial landscape I can just cut that IE6 stylesheet away like a scabby old band-aid. This is a real benefit of using web standards methodologies from the beginning.

Also, there is no rule that says a website must look the same in every browser – take mobile platforms as a good example.

Minor Changes in Recent Days

Regular readers of this website using better browsers will notice I’ve recently incorporated CSS3 opacity, rounded corners and shadows and I’ve changed the dark background image that caused the annoying flickering effect. You will also notice that I don’t much care if these are not supported by some older browser and that the luxury of not caring comes from ensuring that it gracefully degrades for lesser capable browser experiences.

None of this even affects the IE6 stylesheet so it’s simply not an issue.

Mobile Users (Hopefully) Get a Usable Experience

This website is also intentionally designed to degrade for smaller screen browsers so that it becomes a single column layout. For example put this URL into this iPhone emulator – http://iphonetester.com/ [If any iPhone users have feedback about the right of wrong of this simulator I'd really appreciate knowing if it's worthwhile or completely useless]. The website should be at least readable. I’ve got a few tweaks that need to be done again for Opera Mini but I’m leaving that for the next step in the experience evolution…

Enter CSS Media Queries

Rather than continue with the clunkiness of this approach to mobile browser experience, I’m considering the article published on A List Apart by Ethan Marcotte on Responsive Web Design which has inspired Simon Collison and Jon Hicks to pursue responsive web solutions. The trick is to incorporate CSS media queries… although I did read somewhere that CSS media queries have inherent processing inefficiencies. But there you go.

Ethan has a conversation about CSS media queries on the The Big Web Show episode 9: Responsive Design with Dan Benjamin and Jeffrey Zeldman. While I don’t agree with much of what they discussed about large file sizes on websites it does lend some insight into strategically pulling off the technique.

With the mad growth in mobile web experiences we’re bound to be drawn into mastering the mobile web design information space… it’s a part of the industry evolution we’ve all bought into as ‘web professionals’.

I guess like everybody’s weblog this one is just another work in progress. We’ll see how it goes in a few days as I find the time to rework the code. As always, expect a bumpy ride.

Update: 25 June, 2010
CSS media queries are currently partially implemented… highly recommended and not that difficult to achieve.

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.

The problem is that we are unlike most industries in that we actively send interested applicants away until they have developed a portfolio of commercial websites. This does not happen in most industries for a reason – these free agents working at no cost and often for little or no reward are low-end competitors. That, on the whole, is a bit of a web design industry problem.

Imagine that the profit pool for web design related businesses is a giant pie. The pie includes web developers, graphic designers, information architects, usability experts, hosting providers, technical support people, receptionists, managers – and a whole lot more. The pie, however we like to imagine it, is nevertheless finite in size. Or, more accurately, it has a maximum size that is limited by the number of potential clients requiring our professional services.

We shrink that profit pool by actively encouraging low-cost competitors to come back to us with their commercial portfolios.

We also encourage in that ‘web designer’ culture the plethora of bad products sold into the marketplace by untrained and low-skilled future professionals. At the same time, we actively engage in a practice that detracts from consumer confidence in our value proposition.

Consumers think less of our abilities because they get free second rate products built by low-end unprofessional competitors.

In a sentence: we trash our industry brand through our continued exploitation of the employment model that expects our future employees to be pre-trained high grade experts in their parent’s basement.

I want each and every web professional to think about this for a minute. A few years ago Molly Holzschlag started a web professional organisation… they also need to consider these points.

Ours is a highly competitive saturated market with the public perception that it can be achieved by a 15 year old on the weekend.

So now you – the web designer reading this – know where that large slice of the profit pool is going… why there is less business than there should be… and why there is so much crap work on the Web. Take your part in that responsibility and stop complaining about it. Who plays your part in that problem? Oh you do.

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

The answer, as many others have suggested over the last few years, is to adopt the low-tech approach of honeypots and invisible form fields. Traditionally the honeypot strategy is where you put something yummy and juicy in front of a target to lure them to the bait for capture. An example of honeypot strategy are the fake crime and sex websites created by law enforcement to track and convict offenders. But our honeypot in the case of a form isn’t so bold… its more a strategy to find out who is human and what is a bot. Needless to say, bots are the target of our honeypot strategy.

The approach I’d recommend can be thought of as a simple ditch followed by a hurdle and its even simpler to implement. Below is an image which shows the visual layout for the user of this strategy.

And the following (X)HTML should be compared to the users view to assess the subtle difference.

<form class="contactform" method="post" action="../wp-content/themes/candidav2/process/emailcontact.php" id="con_form">

<fieldset>

<label for="name">Name *</label><input type="text" size="35" maxlength="35" name="name" id="name" /><br />

<label for="email">Email *</label><input type="text" size="35" maxlength="35" name="email" id="email" /><br />

<label class="age" for="age">Do not fill this out (spambot defence)</label><input type="text" size="3" maxlength="35" name="age" id="age" /><br />

<label for="subject">Subject *</label><input type="text" size="35" maxlength="35" name="subject" id="subject" /><br />

<label for="test">What is 1 + 4 *</label><input type="text" size="35" maxlength="35" name="test" id="test" /><br />

<label for="comment">Message</label><textarea rows="8" cols="30" name="comment" id="comment"></textarea><br />

<input class="button" type="submit" value="Send Message" name="submit"/>

</fieldset>

</form>

Comparison of the two should lead you to notice two things:

1. A field for Age which does not appear visually
2. A sum of 1 + 4 which is to test the user’s non-botness

The Age field (or whatever you wish to insert) is simply deprived of it’s visualisation through CSS – you might use display: none; or margin-left: -3000px; or other simple trickery to prevent human beings from seeing it. This field is the ditch; if anybody fills in the invisible field then you know they’re not human and you can kick their sorry ass aside – obviously a simple PHP check to ensure the field is empty is enough.

Next, the test field asks a simple question such as what is the sum of 1 + 4? Or you might see the more common question on other websites of what is fire – hot or cold? It might sound lame but at the present time bots have a hard time dealing with random quizzes of logic – and they are so easily replaced with a new question if there’s a sudden breakthrough. The test, in this case, is simply to reject all submissions that do not contain a correct answer for that field.

The issue of form security on your website is beyond a trivial issue so its irresponsible to place forms online (any forms) until you understand the nature of form hijacking and other security issues that must be dealt with responsibly. I have in the past balked at the suggestion that simple email (mailto:) links are an option, but unless you’re really competent in creating secure web forms then the mailto, with all its attached flaws, is your better option. Just realise that one of the mailto flaws is that the user may not be able to use it to contact you (although that probably isn’t a large swathe of your readers).

But, to date, the most effective bang for my buck in getting sleep has been the technique described in this article – the ditch and the hurdle. It won’t lock out humans inputting spam but it pulls the power back home when it comes to bot-attacks. I hope it makes your life easier, too.