blog

In the early days of web design there wasn’t a great deal of difference between a web designer and a web developer. A lot of organizations took the two roles, threw in a few skills like network administrator and content editing and termed the whole thing a “webmaster”, a virtual wizard of all things Internet, a magical being of tech. And while there are still plenty of these arcane heroes amongst us, a gradual transition away from the all-in-one approach due to concepts like separation of content from presentation and layered tiers of programming have divided these aspects into defined roles performed by different employees with rather more mundane titles like “engineer”.

At Beaconfire, the Information Architects (IAs) are distinct from the Interface Engineers (IEs), who are distinct from the Software Engineers (SEs). Since we’re also technology agnostic, our Interface Engineers try to cut portable HTML that can be used in any system or language, and our programmers try to make that HTML work with minimal changes in the Content Management System or custom application they develop. As Web 2.0 interfaces utilizing RIA technologies like AJAX become more ubiquitous, it’s natural to assume that the separation of interface and programming roles would continue to expand and solidify as the skills become more specialized and exacting to master.

And yet… two very different modern technologies that heavily leverage CSS are bringing design and development closer together again: JQuery and Microformats.

JQuery is, at its most basic, a Javascript library designed with a lot of utility functions to make programming quicker and easier. Every Javascript library says it does that. But thinking of JQuery as simply “yet another library you don’t want to deal with” marginalizes its strengths — in practical terms, it serves as both an AJAX engine and a HTML document object model manipulator. Its selector methods are replacements for all those getElementById calls you’ve been using to toggle div elements open and close; its abstraction layer keeps you from pulling your hair out when you need to show all the links below the active page in your fancy DHTML menu; its querying syntax lets you work with the HTML of your page with the same ease a master of XPath does with XML. It’s also the reason our developers suddenly start asking not just what the IE named the class that highlights a menu-item, but how many places it shows up, whether it’s used on DIVs or SPANs, what the element right above it is called and “Couldn’t you just completely rewrite the CSS using classes instead of ids?” And it’s the reason our IEs are wondering, since when did you start caring?

At its heart, JQuery transforms the CSS class designations used in the past almost exclusively for styling purposes into object attributes to facilitate finding elements and manipulating them. Of course, those object attributes were always there, but working with them was trying due to browser inconsistencies and clumsy syntax methods – thanks, Javascript, but the chances I need just one element called #imTheOneYouWant or every single table cell element in the whole page are pretty slim. JQuery alleviates that problem by allowing simple, single-line query statements that pick out the exact elements you need – every checkbox that’s been checked in a section of a form where a text field hasn’t been filled out, or every hidden div inside the selected row of a table. The items that programmers used to get by using naming tricks and looping over every element whose name starts with “elementsWeCareAbout_” are now much easier to get based on what element the interface designer placed them in and what she named the class attribute for each. And if she didn’t apply a class, suddenly the programmer might want her to add one even if there is no stylistic application at all. Software Engineers who may have dismissed the whole “cascading” part of style sheets in the past now utilize the same selector syntax in their JQuery searches as designers do to apply styling to elements.

Microformats apply the same high level principle – using markup meant for styling in a broader context – but here the focus is on providing semantic meaning to elements based on their class names. For those not familiar with Microformats, it’s a method for making human-readable information also machine-readable, with a minimal amount of effort. Basically, you take information on your webpage that already has some objective meaning (like an address or a calendar entry), throw some agreed-upon naming conventions for styles into the HTML you already have, and you’re done. Oftentimes, the HTML elements are meaningless, and the class designations are everything – in a traditional hCard example, a designer might use a SPAN or a DIV around the street address, but he must give it a class attribute of “street-address”. Which means that not only do the CSS naming conventions of the Interface Engineers need to conform to a standard which may have very little to do with styling, but they also have direct implications for any programmers who care about that machine-readable end of the equation.

By extending the usefulness of CSS, both Microformats and JQuery blur the line that for some development shops might be a wall between offices, a division in the organizational chart or just a way to do development “the right way” –a line between styling and programming, designer and developer. Is it a positive trend? Despite the advantages of separation, it’s hard to think of programmers and designers taking a greater interest in each other’s work and hopefully discovering a new thing or two as a bad thing. After all, we may not all be masters of the web, but we’re still learning.

This entry was posted on Tuesday, October 14th, 2008 at 9:41 am and is filed under Tech, Web 2.0, Web Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.