Learning/Teaching HTML

I found it very interesting to be in a class where people were being taught HTML, for two reasons:

  1. Although I’ve been using HTML since 1996 or ’97, I’ve never taken a class in it.
  2. I’m in the process of hiring an assistant who will cover for me while I’m at ITP, and the person I’ve chosen has no Web experience, so I’m going to have to teach her this stuff myself in a few weeks.

So Monday’s introduction made me think about how I learned HTML myself, and about how I intend to teach it.

How I learned HTML

Slowly.

Version 1.0

In September 1996, when I started working at the Academy of American Poets, the organization’s Web presence was just what’s known as a brochure site: all the text was literally copied from the printed brochure. There was probably one mailto: link, pointing to the sole e-mail address used by the organization. Because I had a friend who worked at PC Magazine, I did already have a personal e-mail address—a string of random letters and numbers—and a form of Internet access through Prodigy. I had access only to Prodigy’s content, though, not to the World Wide Web, so having real Internet access at my office was deeee-luxe.

I sat in the cubicle next to the Webmaster, Bruno, and he taught me how to make basic edits to the site and do a few things in Photoshop. We used a WYSIWYG editor called HoTMetaL Pro, and I learned some things by examining the code that HoTMetaL would generate. Eventually I was using the WYSIWYG interface only for stuff that was tedious or confusing to mark up by hand, such as tables—of course, everything was laid out using tables at the time.

Version 2.0

The following spring, in time for National Poetry Month (April), Bruno had the website redesigned, with the help of a print design firm that had started doing websites. (Nobody else was doing websites at the time.) Our new home page consisted of just an image map (I think the text links at the bottom were added later in the year), with the site navigation embedded in the image. The site’s content had also been greatly expanded—which is to say, there was content, comrising mostly a set of curated poetry exhibits, accompanied by audio recordings. All of it used tables and HTML frames.

When Bruno started working part-time fom home, I began making a lot of the little day-to-day changes for him. Occasionally we’d need to create a new navigational button, and since all our buttons were graphics rather than live text, and our Web designers were slow to respond to our requests, I’d try to make them myself. I’d never heard of antialiasing, but I could see that my buttons didn’t look like the ones the designers made—their buttons had these weird kind of colored halos around them, when you zoomed in. So I tried to replicate the effect in Photoshop by hand. No shit. It didn’t look very good, but it did the job, and eventually the designers would get around to making the real button.

The more I worked with the website, the more annoyed I got by its limitations. The frames meant not only that it was difficult for other sites to link to us, but also that I couldn’t link to us: whenever we wanted to cross-link to a specific page on the site, I’d have to make a new frameset. It was a nuisance, and although there were some helpful file-naming conventions in place, the directories were growing cluttered. I’d also started reading more about how to do Web stuff, and I learned that our site posed some pretty serious usability and accessibility problems, with the frames and tables and image-based navigation.

We started wanting to feature specific content on the home page, so after a few months we added a grid of items below the big image map. These were all below the fold, however, so they weren’t as effective as we wanted them to be. Also, there were technical problems—the discussion forums and event calendar ran on ColdFusion, whose code was maintained by a guy who never returned our calls; when they broke, they stayed broken. So I started reading up on ColdFusion, website optimization, information architecture, usability, and accessibility, and reading articles at places like Webmonkey and A List Apart. In the process, I discovered HTML standards and realized that we were stomping all over them. I also began using Homesite, which was more of a text editor than a WYSIWYG editor, and which could highlight syntax in both HTML and CFML.

Around the same time, I was learning about design and using desktop publishing software, and I used style sheets and templates a lot, so the idea of having style sheets on the website, too, and having the content be pulled into templates from a database, made perfect sense to me and seemed like a desirable thing.

Version 3.0

By fall 1999, Bruno had a full-time teaching job, so I was running the website with the help of the lovely Kim Ranney, who also learned coding on the job. We put out an RFP and ended up hiring Juxta, a company that specialized in database-driven websites and could make better use of the ColdFusion license we’d spent so much money on. Over the next few months we worked with them to rebuild the backend from scratch and clean up all the existing content so that it could run on a database-driven site. The new site, rebranded as Poets.org and designed by Steve Gulla, launched in spring 2000. The new site was our first version to use a DTDHTML 4.0 Transitional—and CSS, and I was constantly running our pages through validators, trying to get as close as I could to a clean, accessible site.

I knew that I wanted to eventually upgrade all our HTML 4 Transitional code to XHTML, so when John Tranter, a poet in Sydney, asked for volunteers to convert back issues of Jacket magazine, I spent a weekend or two doing that. I believe it was in doing that project that I first made use of HTML Tidy.

Everything was going swimmingly, then, until fall 2001, when, largely in consequence of what had happened in September, half the staff was laid off. I opted to be one of them.

Version 3.5

For the next six years, my coding needs were minimal, Having a lot of time on my hands, I started a personal blog, hosted on the “pro” version of Blogger. I'd switched to using a Mac, and since I was on Unix, I also fiddled around with PHP a bit, trying to see if I could figure out how recreate the needlessly expensive Poets.org backend (Windows NT, Microsoft IIS, ColdFusion) on Unix/Apache/PHP/PostgreSQL. (No, I couldn’t.) A year or so later I got a part-time job as managing editor of PEN’s literary journal, and I spent a weekend rebuilding that icky little website to be XHTML 1.0 compliant.

In 2004 I set up a TypePad blog for a colleague, and in October 2005, I started my first WordPress blog. I also founded or joined a few group blogs (e.g., Clusterflock, DrawMo!).

Version 4

Then, in late 2006, two former colleagues from the Academy asked me to come work at Nextbook, a cultural organization that has an online magazine. This is where I am now, working half-time while I'm in school. I don’t have direct access to the templates, unfortunately, but being the only person on staff who knows an appreciable amount of HTML, I’ve become the formatting problem–solver and the liaison to the freelance Web developer. I do all my coding in TextWrangler except image maps, which I’m still too lazy to code by hand. (I used to do them in ImageReady, but now that that’s been dropped from the Creative Suite, I have to do them in Dreamweaver. It’s almost inconvenient enough that I’m ready to start making them from scratch.) When I have to make a new style sheet, I either use the demo version of Coda* or start with an existing CSS file. I can never remember how the anchor pseudostyles work, and there are still a lot of other things that I have to look up in the specs every time.

How I plan to teach HTML

So, now that I’m in school, I’m hiring a full-time assistant to take care of things while I’m in class. The person I’m probably hiring has no Web experience. She has worked as a typesetter, so I know that she, like me, is used to using style sheets and templates. I also know that, as a text designer, she must understand that you can’t design a document without first figuring out what its structure is. And if she’s ever used Quark XPress’s weird markup language, she’ll be familiar with the concept of tagging.

So my approach will probably be to start with a structured document—say, perhaps, Southey’s Life of Nelson or Etiquette by Agnes H. Morton, and then we’ll do a design survey to see what kinds of elements the document contains. Next, we’ll mark up the structure. Once everything is tagged, we’ll make a couple of style sheets and run everything through the appropriate validators.

We’ll try to follow XHTML 1.0 Strict, because why learn sloppy habits when it’s just as hard to learn to code to the standard? Part of the reason I decided to hire a person with no Web experience for what is arguably a more than half Web-based job is that it’s easier to teach a person healthy coding hygiene from the outset than it is to get people to relearn stuff that they think they already know. I also think that for the right kind of person, adhering to standards is fun. It’s challenging. And the solutions one finds to thorny layout problems can sometimes make HTML seem quite elegant. That said, even semantic web-istas are unable to agree about how some pretty common types of content should be marked up. But we’ll consider the options, and read the spec, to make sure we’re making a conscious decision, not just using a particular element because it’s the only one we know.

We will not try to make pages that render the same in IE 6 and 7 as they do in more modern browsers, because I believe that’s a waste of resources.

Then, finally, once she’s got a good grasp of what code should look like, we’ll view code on some of the pages from our company’s website (for example, a feature and a poem), and I’ll show her what we’re up against.

We’ll see how it goes.

* I do have a licensed copy of Coda at home, but I can’t justify purchasing it for my company because I so rarely do anything that requires that much assistance.