What are web documents made of, anyway? Sugar, spice, and everything nice?
In fact, they’re nothing more than Source. For all of the inspiration, thought, and sweat that might go into a page, it is merely a mess of characters that happens to contain a lot of brackets.
After five and a half years of actively building pages, it’s occurring to me that a lot of developers haven’t figured this out.
What I see is not what they get.
Is this the anguished moaning of an old fart? It certainly is.
As with the plaintive cries uttered by all old farts, this one also contains a nugget of wisdom: while at first you may succeed by the power vested in your tools, you could ultimately fail on account of their limitations. In extreme cases the cognitive “filters” imposed by a GUI can make it easy to forget that you really are implementing markup and scripting languages.
That’s why it’s time to go back to basics.
When I started doing web work in August 1995, there were a few tools out there – PageMill and HoTMetaL Pro come immediately to mind – that would attempt to build a page, and would occasionally even do it right (give or take the not-so-occasional NATURALSIZEFLAG).
For the most part, however, we Used the Source. Summoning energy from the crowns of our <HEAD>s and the lowest reaches of our <BODY>s, and despite all of the <IMG> problems foisted upon us by clients, we made templates, saved them, and passionately pecked away as if it were four minutes ’til midnight. With nothing more than hastily-assembled graphics and the 128 characters available to us, we <B>ly went where no creative had gone before.
A few years ago, the Pied Piper came to town, and he’s been seducing our younger cadres ever since. His true name is Dreamweaver.
The good, the bad, and the ugly#section2
At first glance Dreamweaver and its cousins (GoLive, FrontPage, Fireworks, and ImageReady) are a tremendous gift. They free the designer from the shackles of scripting and the mire of markup, allowing creativity to spring forth like the remorseless tiger it ought to be.
These programs giggle at rollovers, and belly-laugh in the general direction of the complicated table slices over which so many have destroyed their eyesight. Wait – you need to do a global replace on a whole site? No problem.
Dreamweaver and its ilk allow a single environment to be employed across an entire project or an entire shop, thus spawning one of the Babel Fish that makes it possible for designers to communicate among themselves. (The other one would be standards.)
These applications have perversely proven the value of function over form. The icon of WYSIWYG has earned every one of its converts. After all, the point to the GUI is that it brings the interface within easy reach of the user, and WYSIWYG web design applications are one of the higher expressions of this mission.
However, as any puissant student of the art of love will point out, seduction comes at a price for both parties.
The applications used to generate this markup are resource-hogging monsters, likely as not to bring our workstations to their knees. The developers who use them are also limited. If it should come to pass that Joe Designer has a great idea that his tool can’t pull off, well, he’s S.O.L. unless he gets some help, or happens to know how to code by hand.
What they don’t tell you#section3
To the credit of WYSIWYG applications, later releases make it easy to write HTML by hand in the confidence that it will be left alone, which provides for a lot more flexibility in the development process. These later releases also generate markup – for simple pages, at least – that sparkles next to the output of earlier versions.
To be honest, though, it’s not the sensibilities of the old hands and the geeks that I worry about. It’s the skills of newcomers. Just as word-processing software, with its spelling and grammar checkers, has helped to diminish writing skills, WYSIWYG web apps are chipping away at the median knowledge level of practitioners of the interactive arts.
By “chipping away,” I am not referring only to the sloppiness or the lapses of memory that result when a designer gets married to his WYSIWYG tools. It’s becoming apparent that there are no small number of designers out there who’ve never been exposed to anything but WYSIWYG, who wouldn’t have the first idea of what to do with Notepad|pico|BBEdit|Pagespinner|HomeSite (unless the archangel Gabriel also happens to be a savvy web designer). As a further outrage, these designers bill by the hour.
Software companies are only partially to blame for this widespread problem. After all, their job is not to improve your web design skills; it’s to write, market and sell software. And software is written to address the needs of its market. Software is always limited, of course, since its creators are only human, and therefore possess finite resources.
My question to you is, why would a software company be forthcoming about the things its latest title cannot do? If they can get away with marketing it as the Greatest Thing Since Human Reproduction, why shouldn’t they? Better marketing == more revenue == pleased shareholders. Things continue apace, since market churn replaces users who outgrow software.
“Vee vere chust vollowing ohr-dirss…”#section4
Who, besides software companies, shares the blame for this erosion of skills? Clients and managers, that’s who. Clients and managers create impossible deadlines, and make key development decisions though they wouldn’t know emphasis from italics if the difference bit them on the ass.
It seems natural that an application, effectively marketed as a time-saver, would in fact be procured and integrated into a shop that’s groaning under demands to rival the labors of Hercules.
The end result is a thousands-strong army of web developers who’ve been encouraged to just get the f—-ing job done. Like Milgram’s study subjects, they’ve been pressured to produce rather than to Do The Right Thing. They’ve actually been encouraged to depend on their tools so as to minimize static during the development process. Perceiving what they believe to be the lesser of two evils, they choose it.
When you consider the consequences of a mid-project change in development methodology – which has been known to happen when someone attached to the project learns something new and experiences an epiphany – this is not an entirely bad outcome.
On the other hand, it has created a situation in which developers have become accustomed to previously unheard-of salaries despite their lack, in many cases, of fundamental knowledge.
That fundamental knowledge lies in the Source.
Better living through chemistry#section5
Source is the atom of the web universe. It’s the basic particle, the lowest common denominator, of which everything else is composed. You may not be a chemistry genius, but come on – what else could be used to create matter?
I can hear the sighs of boredom already. “Yeah, whatever,” the chorus groans.
This is your call to action, so listen.
What goes through the modems and routers? Bits. What gets displayed on the screen? Pixels, which are defined by bits. What finalizes a transaction on your e-commerce site? Bits.
Let’s look at these bits and bytes from a designer’s point of view.
The big word, the word that every web designer should have memorized by heart, is “parse.” This word has a neighbor in this context: “interpret.”
parse [from linguistic terminology]
1. To determine the syntactic structure of a sentence or other utterance (close to the standard English meaning). “That was the one I saw you.” “I can’t parse that.” 2. More generally, to understand or comprehend. “It’s very simple; you just kretch the glims and then aos the zotz.” “I can’t parse that.” 3. Of fish, to have to remove the bones yourself. “I object to parsing fish”, means “I don’t want to get a whole fish, but a sliced one is okay”. A “parsed fish” has been deboned. There is some controversy over whether “unparsed” should mean “bony”, or also mean “deboned”. – From Webster’s, via the Jargon File
Are you confused now? Don’t be. Those two words are the ones that describe what a web browser does to the source code that crosses its sights. It starts at the top of a file, parses the (X)HTML, scripts, and styles through to the end of the file, interprets that markup, and spits out its representation on the screen. The computer does exactly what it’s told. Do you really want your software telling the computer what to do, when you could as easily be giving the orders yourself?
When you drag or create an element in a WYSIWYG environment, the software has its own algorithm for writing code. In most cases, the output is adequate, but hardly efficient. The software doesn’t know the purpose of the code; it’s merely trying to faithfully reproduce a desired layout in such a way that the browser will still be standing at the end. Can it write the code in such a way that both the structure and appearance of the page are properly represented? It often can, but not nearly as well as you can do it on your own, if you know the rules by which web document structure is defined, and can apply those rules to the site that you’re creating. The software may be able to code for you, but it cannot read your mind, and it certainly can’t read the minds of your client or your intended audience.
While content may be king, and while your audience doesn’t (usually) care about the quality of your markup, that quality effects the searchability, maintainability, extensibility, accessibility, and file size of the web documents you create.
A square meal of rhetoric#section6
“You’re wrong, Ben,” you might say. “The stuff I build works without a hitch, and Dreamweaver does it all for me. My clients are thrilled, and I’m raking in dough on account of the time I’ve saved.”
If you maintain an intranet, or an external site targeted to an audience known to use a particular browser/platform/throughput environment by its own volition, I will concede your point. I will be similarly magnanimous if you happen to be one of the lucky ones who takes to software like a fish to water, who can achieve a Vulcan Mind Meld with any tool in record time.
If, instead, your logs show stats from all n corners of the web, or if you’re deeply committed to achieving guru status (and thus improving your rates of compensation), then it’s time to get back to the Source.
In order to be a virtuoso you have to have intimate knowledge of your tools. Doesn’t it make the most sense to establish that intimacy with the tools that are free, open, and exquisitely well-documented?
Proponents of WYSIWYG like to reply to this appeal by holding up the talisman of PostScript. “We don’t have to mark up documents for printing, and they come out just the way we want them,” they say. “Why should it be any different for the web?”
It is different for the web, and will always be different for the web, because the web is not a sheet of paper. It doesn’t have finite or even predictable dimensions. Its content is not static. It doesn’t have five centuries of process and tradition from which we can draw best practices. It cannot be expressed entirely as a Cartesian coordinate system in increments of six or twelve hundred. Nor will these things soon change.
When everything is said and done, this medium we call the web is not yet mature enough that its paid experts can be ignorant of its inner workings or finer details.
The client at the bottom of the food chain#section7
The recent downturn in the immature web industry has exposed its Achilles’ heel: to this point, its lifeblood has been clients whose main concern has been a rush to market. Until late last year, neither cost nor quality were seen by clients as issues of overarching importance.
That has changed with the turn of the calendar. Clients will learn soon enough the dirty secret of the large consultancies: the web, like software, is best developed by ability, talent, and sound planning. Economies of scale do not benefit web development, except where they create a synergy of talent. Clients won’t stand for being charged high rates, either – unless they know they’re doing business with an operator who really knows his (or her) stuff.
All other factors being equal, the little whale can “swim the sea” just as well as the big one, and at a much lower cost, because little whales don’t need to eat nearly as many krill. But this doesn’t change the fact that any one shop (or developer) has limits on the knowledge and experience it can accumulate without increasing bulk. This dark cloud has a very bright, multifaceted lining.
Future Possibilities#section8
As the market continues to tighten, we’ll see more clients who are willing to consider small operators as credible providers of a given specialty.
With the merger of Macromedia and Allaire, content-management solutions will continue to improve. This is a good thing, because it will make feasible projects that at present only the biggest, most ambitious clients can afford. The evolution of open-source solutions will further amplify this trend.
The lumbering dragon of higher education will continue to improve the quality of its offerings in the New Media disciplines, leading to interactive designers who have a holistic appreciation for what works and what doesn’t.
In the longer term, but along the same lines, the savvy and dreams of the generation now in secondary school will be felt in the marketplace. As with systems programming in the Seventies and Eighties, the graduates of today’s Art Center will come from tomorrow’s community college.
All of these factors point to a future in which HTML practitioners are in fact dinosaurs or at best basement-dwelling specialists.
However, we’ve not arrived at that future just yet. Until then it’s a good idea for those who want to call themselves “professionals” to have a broad repertoire of knowledge. This repertoire can only be built from the ground up, which means coming back “home” to the Source.
The building blocks of source code: resources#section9
Given all that’s been said above, I would feel like a tease if I didn’t point out some resources that might be of use to a developer who wants to kick the WYSIWYG habit.
At the beginning of my own time on the web, the resources available to beginners were not nearly as comprehensive as they are today. This is amply reflected in the relationship between ability and experience, which is not nearly as pronounced now as it was three or four years ago.
What may come as a surprise, however, is the fact that many of the resources available then are still entirely relevant now. What follows is a list of my favorites.
The NCSA Beginner’s Guide To HTML: In terms of breadth, this resource hasn’t much to offer, but it’s at the top of the list because it does the best job of any resource I’ve found when it comes time to understand how the web works at the page level.
The Bare Bones Guide To HTML: If the Beginner’s Guide is the book, then the Bare Bones Guide is the Cliff Notes.
The Yale C/AIM Web Style Guide: What the Beginner’s Guide does for HTML, the Style Guide does for presentation, content, and optimization.
The World Wide Web Consortium: The documents here are verbose to the point of being inscrutable – but they are also a necessary stop on the journey from cluelessness to mastery.
The tutorials at Webmonkey: These are written in a style that doesn’t really appeal to me (or my brain), but they’ve gotten many a web-developing butt out of a sling over the years.
Netscape’s documentation for JavaScript: It’s non-standard. It’s outdated. It also does a great job of explaining how HTML and JavaScript interact. {Resource no longer available online ““Ed.}
The irt.org JavaScript FAQ Knowledge Base: If you’ve become familiar with how JavaScript works but can’t wrap your mind around a particular objective you’re trying to accomplish, this repository can be a lifesaver. {Resource no longer available online ““Ed.}
Microsoft Developer Network’s Web Workshop: This site is not strictly excellent (with the exception of the CSS documentation), but it is comprehensive – and indispensable, when you consider IE’s market share.
Anything published by O’Reilly & Associates: The good news is that these resources are produced with the involvement of the people who’ve helped the web come into existence. The bad news is that you’ll have to pay for them…but that’s okay, because you’ll get what you pay for. I especially recommend Webmaster In a Nutshell entirely because it does an excellent job of explaining how forms and CGI work.
Mailing lists: ALA recommends thelist and webdesign-l, where you can read countless and varied threads, ask (or answer) countless questions, and devour knowledge in concentrated form. At least, that’s what it seems like to me – and I subscribe to both.
Source code: “Read the source, Luke!” This was most-repeated piece of advice I saw back in 1995, and it’s no less true today. If you want to know how something got done, VIEW SOURCE. Whether it’s HTML, CSS, JavaScript, or even a server-side language, viewing source can open your mind to the really cool stuff on the web.
No Comments
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
To Ignite a Personalization Practice, Run this Prepersonalization Workshop
The Wax and the Wane of the Web
Opportunities for AI in Accessibility
I am a creative.
Humility: An Essential Value