The history of science is crowded with stories about competitive researchers sprinting for new discoveries. First place gets patents, research money, and sometimes a Nobel. Second place gets a snarky note in the sidebar of junior-high science textbooks. While competition can foster innovation, scientific progress is retarded when researchers delay the publication of groundbreaking cancer research data in order to secure the most advantageous patents, or when research teams refuse to share information for fear of a licensing double-cross.
Happily, web development isn’t genome science. Your reputation may be solidified if you work out a zingy new CSS technique or write a persuasive article on standards-compliant bicycle sharpeners, but there’s not usually a lot of money or international acclaim available to the first person who gets that horizontal drop-over aligned correctly.
This is good, because it means that we’re free to collaborate. The amount of information on new and exciting web stuff is far too huge for anyone to keep track of, particularly with thousands of design and development weblogs thrown into the old-school mix of message boards, e-lists, and the occasional online magazine.
Sometimes ALA can help make this enormous amount of information and innovation more accessible to more people by providing a place for related ideas to interact.
One kind of success
In one of our recent issues, we published an article that produced a design effect that we hadn’t seen on the web. The markup wasn’t ideal in anyone’s mind — certainly not the author’s — but we decided to run it anyway because it felt like a specialized instrument that many of our readers might like to have handy.
One of our readers left a comment about his own method of tackling the problem. With that helpful reader’s permission, the article’s original author developed a new technique that married the best points of both before pushing the technique further to see what he could do with it.
This is a particularly clear-cut example of the kind of collaboration we strive for, but it’s not unusual. This is the way it’s supposed to work.
Prescription vs. experimentation
A lot of the articles we publish are intended to persuade people — designers, developers, content people, clients — to do the right thing. Some of these articles, thanks to the generosity, skill, and insight of our authors, have inspired really positive changes in the way people make websites.
This is also the way it’s supposed to work.
We also like to share experiments — articles that aren’t intended to persuade anyone to see the light and adopt CSS hacks. We publish them when we think they’re interesting and potentially useful to a sizable portion of our readership.
When we do, we know going in that while Method X could be the beginning of a series of exciting design and development conversations, it will almost certainly produce another batch of “ALA has really gone downhill” comments and arguments about purity vs. practicality. We still publish them because we think it’s worth it if some of them turn out to be useful.
We would, therefore, like to invite everyone involved to relax. We’re going to keep publishing articles on accessibility, usability, information architecture, client relations, project management, and — oh yeah, plug-and-play, standards-compliant XHTML, CSS, and scripting innovations. We’re also going to keep publishing articles that include CSS hacks and the occasional non-semantic element because we believe that our readers will have the good sense to know when to use them and when not to.
Introducing the ALA experimental / controversial content warning
Think of it as the soothing voice that announces, “This is a test of the emergency broadcast system” before you hear the earsplitting beep. Except without the beep.
It doesn’t mean that we’ve suddenly forgotten that the web is not print or that we think everyone should stop worrying and learn to love the kludge.
It’s a warning that the article that it precedes uses experimental techniques to do cool things that we’d like to do more simply but haven’t managed to yet — or suggests better ways to do things that give a lot of people hives. If you see the icon, you’ll know that you should consider the implications and read the suggested alternatives or improvements in the forum before blithely implementing Method X on every site you work on.
It’s a chance to take what you can use, improve what you can, and leave the rest. We probably won’t publish experimental or controversial techniques any more frequently than we did before, but this way you’ll know what you’re getting into. We hope it helps.