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.

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).

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 first take-away from Christian Heilmann’s article on Smashing Magazine titled Web Security: Are You Part of the Problem? is that you need to make sure at least one member of your team is up to speed. Everybody else needs to appreciate the importance of what that person tells them.

The second take-away is that no matter how much the world looks like a rosy cake of graphic design skills in our industry, it isn’t. Its in the marrying of good interface design, graphic design, business acumen and coding skills that make a good website. Unfortunately we’re in a world that tends to judge almost entirely on the superficial 6 seconds after the user arrives on a website – how does it look trumps is it secure? In other words, there is always pressure to make things look good but nobody pressures about writing better code until after you’re butt-shovelled by a Russian spamster or three.

And the third take-away from Christian in this article is to trust nothing – all data needs sanitising before you use it – and that URIs should be treated with similar mistrust. This is where the crappy web person is vastly different from the great web person if you’re out there hiring, employing or getting hold of a freelancer… the crappy person being the one who comes out with phrases like but it works, doesn’t it? How often have you heard that smidgen of cop-out?

Seriously, when it comes to your business and the web professional then you need to know up front before everybody’s credit card information is compromised that the web solution more than works, it works effectively. Securely.

So my discovery of Web Standards was spoon fed from Mike through exposure to a huge number of resources that espoused a radical and unpopular theory – web pages should be quality products. While the web is a robust medium it doesn’t mean we should just create any old crap that works; we were all talking scientifically and justifying the business case (yes, I got caught up in it quite fast).

With revolution comes a certain passion. Web Standardistas seem to start out with a devout dogmatic passion of the inquisition to drag down and burn all the non-conforming everybody they can get there hands on. Right answers and wrong answers are black and white in that stage of the (R)evolution. I think we can all see a cringe-worthy moment from our past in that picture. At some point we commented on someone’s website telling them they were crap at their job. In fact, I’ve had a smattering of faymus web standards names tell me over the years, here and on other incarnations of this blog, that I’m a dumb anti-christ fucker upper of HTML and other sundry technologies… for example, John Oxton of the Rissington Podcast simply commented that the site was fucked. Brilliant. Take a lollypop and fuck off home, I guess… oh those were joyous times…

The next step of the evolution of a Standardista comes with a realisation of the true depth of the issues. There isn’t one way to do something in every situation. At this point it’s apparent that while we’re trying so hard to be perfect, and we actually know how to write POSH (Plain Old Semantic HTML) markup, there’s always something in our work that falls short of the ideal. Compromise exists. In our criticisms we move from the words must not ever to the words should not if possible.

The next step again in the evolution of a Standardista is maturation, the pragmatic stage. It’s a little less passionate. It’s a whole lot more effective. In the maturation stage the objective is to create working solutions within the constraints of real world problems (as opposed to idealic theories) and the medium for this embraces compromise. You simply cannot be all things to all people, and neither can your web application / page / widget / thingey. At this stage you might better appreciate the business case and the goals and objectives in the world of your client.

Another way of looking at these three phases are to replace them with the words ‘intolerance’, ‘intelligence’, and ‘creative compromise’. At stage two you’re aware of compromise; but at stage three it’s a part of your determination to be a better web professional. Web Standards aren’t about any one thing in isolation at the cost of everything else. But they’re about building web products in the best way possible – cutting edge professional products.

However, don’t mistake that third phase for the lack of an ability to provide valid critique and input into the conversation. That’s another story entirely.

Nate Koechley’s video explaining Professional Frontend Engineering (about 90 minutes) goes a long way to filling in those gaps. I’d also recommend listening to Bill Buxton speak about Design with a big D and the Design Ecosystem. The very nature of what we’re employed to do on projects is to minimalise most of those things you would have otherwise stumbled over.

The website you sit down and use is the tip of a very large iceberg, in fact. The better the team below that berg the better your user experience, the faster the rendering, the better the adaptability to other browser environments and platforms. If you don’t have to think then it’s probably because frontend engineers (whatever the job tag) considered the technicalities and implemented the solution. And when we’re really good you won’t notice our footprint at all.

Veerle’s post in defence of 24ways.org’s design innovation definately comes from the graphic designer as is clear from her comment reply regarding usability. I’d put forward tentatively that just because something is accessible doesn’t mean it can’t be beautiful, and the same should apply to usability. When we step beyond the user’s importance to weigh in with our trump card of design as art – that’s a particular kind of design arrogance. But that’s another discussion entirely, so back to 24ways.org.

The problem is that in the great web tradition of trolling and flaming the comments about the redesign are often acutely negative. Part of the relationship between a popular site and high traffic will mathematically transpose to a higher number of negative comments, right? Well, sort of. The problem is that rather than critique, which very few of us are professionally trained to provide, we give opinion. As time short as we are that opinion can be reduced to a series of caveman grunts – don’t like, is shit, pull in your head. Personally, I’d consider just pulling those out in moderation simply because they don’t add to the conversation – water off a ducks back. But Veerle has a valid point, we ask for innovation but bowl anyone over in an instant who dares move outside the conformist circle (remind me tomorrow to do my graphic design post, by the way – I have similar issues with a lot of graphic design).

Personally I find the current design of 24ways.org difficult to use because it’s hard to read. There seems to be some disconcerting level of grey overlay that is purposefully trying to make my life more difficult. Usability, from my user perspective, is more important than beauty. After all, it’s an information site.

So let’s cut to the chase. What makes a successful website? Accessibility? Usability? Beauty? Functionality? Is it the slickness of the commenting system? Rather than criticism of the design I’d be interested in the statistical results and how those results meet the business case. Because web sites aren’t artistic silos, they’re business solutions to business problems. Does it make money? Does it meet it’s goals?

The criteria for 24ways.org would be reasonably simple. Has traffic increased or decreased this year? Are users staying to read the articles or bailing out? Next, ask yourself what is the purpose of 24ways.org – disemmination of contemporary best practice information? Is it about raising the profile of the website itself?

I’d suspect I’m far from the only person who finds the interface difficult to negotiate. But I’d have to concede that from a business perspective as long as the statistics are supporting this year’s design and the information is being effectively spread throughout the designer / developer community then it’s meeting those underlying goals. And, oddly enough, the controversy around the design itself can be (although a risky strategy) enough to raise the profile of 24ways.org to reach more of our industry radars. It’s better to be talked about than not mentioned at all. Right? So without knowing the brief it’s a bit hard to see if Tim’s met it – or pushed convention too far.

It’s always a little dangerous when the user is placed behind the importance of the graphic design. If that weren’t the case we’d be praising small grey on grey text along with mystery meat navigation, we’d have animated gifs and blinking text – try to read that man! Cool. But I think 24ways.org is a little more sophisticated than that.

The short answer to Veerle’s post would be that I agree, trolling and flaming are an industry bore. But it’s the web in a nutshell. Anonymity breeds a prolific audio-vomit we don’t meet in regular life. Delete those comments that don’t contribute critique, and move on. However, the design consciously impacts my ability and desire to read the articles. The page has been open on a Firefox tab for a week and I haven’t completely read a single one. That might not be so good a sign that it’s a great redesign.

At the end of the day market forces will determine the business answers to 24ways.org. They’ll survive for another year, the content ensures it. But for a lot of people expecting best practices it might eat at the street cred. That’s the innovator’s risk.

Progressive Enhancement with JavaScript (issue No. 271) explains the intelligent approach to including JavaScript in your work. Not as a fix all kludge but as something which gracefully enhances your website for users who have the browser support while not impacting those users with outdated browsers. He briefly explains the basic strategy of placing your JavaScript into external files and writing unobtrusively, as well as the need for maintaining style separation.

In nearly every experience on teams where I’ve been involved, or even entered the conversation, these concepts have failed to be fully grasped. And they need to be grasped. Managers need to ditch the myth of pixel perfection across browsers and devices in favour of setting an acceptable baseline that enables users to access websites, then provide progressively enhanced features that can improve the experience for those with browsers that can handle it. The trick is ensuring that data is available at the baseline level rather than writing it in with your scripts. Does the baseline case work? Does it work without throwing errors?

Because used wisely and proficiently JavaScript is an empowering language for the web development behaviour layer. Used wildly it’s the bane of users and site maintainers far and wide. The difference between class and arse, so to speak. Excellent series from Aaron that needs to be carved into hardwood and bonked on the heads of certain managers and acedemics repeatedly (with a soft cushion perhaps).

You could understand your website as a scone which by itself and straight out of the oven might be oh so yummy! But you could enhance that with butter if you weren’t lactose intolerant and jam if you weren’t diabetic. So you can hand out scones quite freely as your baseline while those with knives and lactose tolerance can enjoy buttered scones and so forth. Does that make sense? As long as everyone gets the scone then you’ve provided a valuable service. What you need to avoid is depriving a lactose intolerant person of the scone simply because they don’t have a knife or can’t swallow the enhancement.

JavaScript, like a gun, doesn’t set out to harm anyone. The power is in the hand of the JavaScripter to appreciate the technology at hand and use it with discretion.

It’s Our Design Problem

The key thing to take away from this post is that JavaScript runs on the client side. The server doesn’t run the script, the client does. That means in most general real world situations you, as a designer, have to consider the wider case of whether or not the user can be expected to have that capability on their machine. Seriously, what if they don’t have JavaScript enabled (I’ve heard statistics over the years that this demographic can be as high as 10%). And, if they do have it, what version? This isn’t just a binary black and white answer – maybe JavaScript is disabled because of security concerns at their company; maybe they don’t have the latest version; and, maybe they’re not in a position to change the state of that paradigm right at that moment. So, you can see that it’s not their problem – it’s our design problem.

It’s a part of our job to design around constraints and limitations in elegant, intelligent ways.

Just Because You Can Do Something…

The dumbest thing ever said to me by an academic was this year at an assessment for a 3rd Year Bachelor of Computing unit – KXT301 Software Engineering Project A. Our code did all the major validation of a contact form in the PHP (Hypertext Preprocessor) on the server side – we actually used Jeremy Keith’s Hijax technique. However, a 4th Year Honours student invited to contribute to assessing our team’s work kept asserting to me that all our validations could have been achieved in JavaScript – WTF? This included checking the MX value, port 25, and anti-spamming checks using regular expressions – is this a real user with a real email address that is active? He marked our project below a pass mark for his worthy opinion (I still got a High Distinction). Now, when you think about that in the real world do you appreciate that any spamming form hijacker isn’t going to realise that and just turn off JavaScript? Please tell me that everyone can understand the difference between server side and client side validation… because that was academic bullshit! But it’s something we see a lot in real world web development as well – simply not considering the whole picture.

Just because you can do something with JavaScript doesn’t mean it’s the appropriate technology for the task.

We Have No Control Over the User’s Environment

So, JavaScript ain’t magic. It’s got a strong role to play in what we do but we have to realise that we have no control over the user’s hardware / software configuration so a large part of what we do as designers is to work smarter – we care about these what ifs. We use JavaScript appropriately in the context of the big picture, instead of just saying wow cool this is snappy – remember the DHTML (Dynamic HTML) crap from a few years ago?

When Not to Use JavaScript

The second point then is that JavaScript is also not the magic bullet for some things. Understand the flaws of running code on the user’s computer instead of the server – would you use it for a shopping cart on an e-commerce site? No. Would you use it for search on an information site? No. In fact, you’d be a little naive to use it for anything critical to your site’s functionality or for security or for processing information like the prices of products in a shopping cart.

When to Use JavaScript

So when to use JavaScript? As the behaviour layer of your website it’s obvious that JavaScript has it’s place. You can use it wisely to enhance the user experience, you can use it to pre-validate input fields to save unnecessary page refreshes for minor form errors, and you can manipulate the DOM (Document Object Model) to do lots of other great things. Just not site critical things. And you should do JavaScript unobtrusively – in external stylesheets, without inline event handlers, use object detection before running the script, and do your work via the DOM. Think about the experience for users who don’t have JavaScript. Consider the broader question of usability – is this just a swishy navigation enhancement that gets in the way of the user’s goal, or does it enhance and speed up their progress?

What About Ajax Applications?

Yes these have their place. But Ajax (Asynchronous JavaScript and XML) should be used responsibly. If you’ve got an application where user response times could be slick and you’ve thought about how to deal with issues like updating the user of page changes, and you’re aware of the down side – hey Ajax can be brilliant. But the same rules apply. If you’re going to use some fancy Ajax widget on your site like a fancy calendar – the same criteria applies. Usability? Accessiblity? No JavaScript? Wrong version JavaScript? Security? Efficiency? Necessity? And, is there a business case to support it?

No, It Ain’t Magic

Used wisely JavaScript is arguably the most exciting layer we get to work with as front-end web designers. We can use it to create slick, magical experiences OR we can blow our site users away with insecure, unusable rubbish. It’s our job as designers to understand the difference. The key points are that it’s run on the users computer (client side), and the flow-on is that we therefore have no control over the environment. For resources on writing great JavaScript and using it wisely the best places to go are:

• Jeremy Keith on Adactio
• Peter Paul Koch on Quirksmode
• Robert Nyman on Robert’s Talk
• Chris Heilmann on Wait Till I Come!
• Roger Johansson on 456 Berea Street

If you start from there with an open mind you’ll become a JavaScript megastar and a way better designer.

In real life this fear just isn’t founded and the last thing you should be doing is trying to hold your users captive. If they want to leave then let them, for Christ’s Sake! It’s repeat visitors and conversions that make a successful site not keeping your window open in some sub-level dungeon on the task bar. You’ve probably figured already that pop-ups confront users with a back button that isn’t going to work. And sometimes the window is chromeless. It’s obtrusive, offends a large number of your users, and will confuse the hell out of sighted users let alone someone using assistive technology. And they should never EVER occur without a warning! OK the rant is over for now so we’ll carry on (we understand that pop-up windows are bad for usability and shitty and considered industry worst practice). About the only thing you should be popping up in a new window is a PDF (Portable Document Format) file in its native application.

But sometimes you’re forced with your back against the wall to suck air and implement the suckers! You’re handed deprecated target="_blank" attributes on external links that smack the users in the forehead [Steven takes forefinger and pokes each reader three or four times firmly on the forehead saying "How do you like that?!"]. Delete all those target="_blank" attributes for a start, its a behaviour not content and you’ll oneday have to go clean the suckers out of there eventually so now is the best time to do it. They’re even the most primitive way of achieving popup windows, so get the fuckers out of there now! Begone shite. Don’t you loathe the way target="_blank" instantly throws up a full sized new window – Whoa, where the friggen hell am I again? WTF (again)? How about letting me, the user, make the decision about whether or not to open a new window [ranting again!].

OK the torture is getting prolonged here. If coerced into doing this, you need to look at pop-ups as a behaviour layer issue. If it’s this or target="_blank". Yes it’s sucky, but at least you can implement them in a sensible way if you’re ever coerced by the prospect of unemployment. So you’re looking for an Unobtrusive JavaScript solution, not a content solution to achieving your result. The benefit of this is you can at least provide for graceful degradation (if they don’t have JavaScript they get a normally functioning link to a new page), window size (definately not full screen) and browser features available to the user (preferably all of the features enabled).

I’m not sure where exactly this snippet came into my arsenal (mainly because I have hardly ever had a call to use it). But maybe it will come in handy for your coerced situation. There’s no crime in trying to make an intolerable thing out of an abject bad situation. Name this script popups.js (I should metion this code wasn’t written by me) and call it from an external file in the head section of your document. Then when you want your external link to open in a new window just include rel="external" as an attribute of the link. In that way, only links you specifically want to open in new windows will do so.

function prepareLinks()
{
    if(!document.getElementsByTagName) return false;
    var links = document.getElementsByTagName("a");
        for(var i=0; i<links.length; i++
        {
            if((links[i].getAttribute("rel") == "external") ||
               (links[i].getAttribute("rel") == "pdf"))
           {
                links[i].onclick = function()
               {
                   popUp(this.getAttribute("href"));
                   return false;
              }
          }
    }
}
function popUp(winURL)
{
    window.open(winURL, "external", "width=420,
    status=1,scrollbars=1,toolbar=1,
    location=1,menubar=1,
    directories=1,resizable=1");
}

Roger Johansson has another script using class instead of rel to trigger the opening of new windows. My preference goes to the rel attribute, but you’re free to choose. Either way these scripts fall back nicely for non-JavaScript enabled users. So, overlooking the suckiness of having to implement a feature that continuously turns up as one of the 10 biggest web design mistakes, and was identified as long ago as 1999 by Jakob Nielsen as having usability issues – there you go. You can run along and shoot your foot off with it.

If I recall where I picked this script up I’ll put a link here, it’s a rather short list of suspects. Best of luck. And doesn’t it strike you as odd that since popups have been criticised now for at least 9 years at a high professional level we’re still having to do this shite? I’m friggen bowled over. Another WTF moment brought to you by the letter K and the numbers 3, 4 and 25. Exit and run…