I Wish I Could Write Better

I wish I could write better. Don't you?

See what I mean? What am I asking, there? Am I being cute, and asking "don't you wish I could write better?" or am I asking if you, yourself, also wish that you could write better? The two simple sentences are just vague enough together that if we walk away from them and move on, some people can reasonably be expected to explain it either way.

I have been writing a long time. I have never come up with anything anyone would remember, probably. I'm kind of proud of a paper I did in college. I got a kick out of a few commercials I did when I was involved in radio. I am very proud of my father's eulogy. I did well with a few articles and reviews for Computer Shopper and some other magazines. But nothing I have written has ever been immortalized on a T-shirt. Nothing is in danger of appearing in Bartlett's Quotations. Still, I have always been a fan of good writing, wherever I may find it.

Have you ever wondered how some people can tell a story in a dozen words, while others need an afternoon? Have you noticed which story is generally better? Brevity is always a goal, but never, as we see above, at the expense of actually conveying an idea correctly.

Some of the best writing being done today is in advertising. Some of the very best work is in single-panel comics. Think of it—you have only the time it takes to turn a page to convince someone they need an entirely new car. You have only thirty seconds to convince someone they need to change the toothpaste they use. An enormous amount of work is brought to bear on the task, when skillions of dollars are at stake.

There are different types of writing. Writing a book is different from writing for a magazine. Magazine writing is different from writing for radio. And of course, writing for the Web is different from everything else. Please try to keep it short.

Online, we don't have the pressure to complete an idea or an argument by the bottom of a page. We don't know how big our "page" might even be. So there is a tendency to put too much on the page. Most people online don't really read the information they seek, they skim what's available, looking for bold or emphasized text, sidebars and lists:

• Strong, bold text
• Emphasized text
• Lists of key items

Always remember your audience. Are there many readers for whom English is a second language? Maybe you will want to lighten up on both idioms and cultural references. Lighten up? Under the weather? Over the hill? Is it possible two people discussing a Hot Car and a Cool Car are both discussing the same vehicle, and both in the same way? What would Maxwell Smart think of a situation like that (if you don't know who Maxwell Smart is?).

Put your stuff away for a day or so and re-read it before publishing. Seeing a page with new eyes is an easy way to catch mistakes. Sure, you meant to tell them A, B and C. But did you? Did you ever really get around to C at all? Make sure your true meaning is clear. Pass the work around and let others see it—and listen to their comments.

There was a Saturday Night Live skit where Ed Asner, as the manager of a nuclear power plant, had to leave a new crew in charge. He cautioned them on the way out, "Remember, you can't put too much water on the reactor core!"

Sure enough, as soon as he was gone, alarms started blaring and lights started flashing and the new guys had to respond. But were they supposed to put all of the water they had on the reactor core? Because, after all, you can't put too much water on the reactor? Or were they supposed to add it a gallon or two at a time, because you can't put too much water on the reactor? Hilarity ensued.

I wish I could write better. Don't you?

Where Do You Go For Help?

I'm a reader. Specifically, I absorb most of my information from reading books, magazines and Web sites. A selection of a few of my favorite books is at right. From the magazine rack, I enjoy .Net Magazine ("Dot-Net") and Web Designer, both from England (By the way, how is it that there are no USA-based Web magazines?). These are both expensive, but offer a fresher perspective than the books and most come with handy tutorials and even CD-ROM collections of fonts, utility software and templates for exercises detailed in the issue.

But what about online?

There may well be more good information available online, for free, than is available on a printed page, today.

You often hear me preaching about validating pages, and directing people to the World-Wide Web Consortium's Web site, http://www.w3c.org/. These are the people in charge of our various Web standards. These are the people who decided what should happen when you place a <p> tag on a page. They must know something, right? Well, yes and no. If I were to set about the task of writing a book on HTML, I would start here for my source material, but while the site is a great reference, it's not really a good source for learning things. Every page of the site just drips with committeeism and almost Dilbert-speak. Even that would be okay, but it's just so dry. Here's the W3C, on the subject of visited links. Now you know why I make the Big Bucks, huh?

There is a W3Schools Web site, not affiliated with the W3C, and there is a lot of free material there, but it is crowded with advertising.

So where do mere mortals go for help? Especially busy mortals? Back in the Olden Days, we had a resource that was fantastic, called WebMonkey. Plenty of mere mortals showed up here and, for a few years, learned the in's and out's of Web Design and Development, but it didn't last. Now, it's back, and off to a great start. You can read about all of the various tags, just as before, but the Web is bigger and more complicated than it was, and you can also find out about content management systems here, now. You can learn JavaScript. You can learn MySQL. You can learn PHP. You can learn blog publishing. You can learn RSS. You can learn more than you can learn, if that makes sense—and it's all free.

Microsoft maintains a lot of Web training and related resources. Unfortunately, I can never find what I'm looking for when I start at Microsoft.com. When I have been sent links via E-mail or stumbled upon a page in a Google search, I have been very impressed. I just can never find what I'm looking for there. Understand, please: It's not that it takes me twenty minutes or half an hour. I can never find what I am looking for, there.

Adobe, on the other hand, have a great site. Maintaining the terrific standards of the Macromedia folks, their Dreamweaver resources are outstanding. It's a Framed site, which is too bad. There was a time in the late 1990s, when we feared that one day every page might look and work like this. But at least this is a Framed site that works. You can learn some Dreamweaver here, folks. I know I sure have.

The Kewl Kids hang out at A List Apart. This is the crowd that is dragging the world, kicking and screaming, to the Promised Land of Web Standards. I don't care much for the earlier stuff, and the site has been around forever so there is some very early Early Stuff. But if you pick things up around ALA098 and work forward for a few issues, you will see how far we've come, and why (and who to thank). Articles on A List Apart come from authors you have heard speak at conferences and on podcasts, authors who have written many of the books on your own bookshelf. You won't find tutorials on which <HX> heading to use where. But you will find some wonderful discussions on how to best style your pages, or even parts of pages, like styling your Forms.

And of course, if you have any questions, you can always pop in here and ask me anything. As I say in many of my workshops, "If I don't know the answer, I'll make something up!"

Meet It Head On!

What is difficult for you? Tables? Columns in CSS? Adding Padding?

Maybe the better question is How do you deal with this difficulty? Do you just ignore it? Do you try to excuse it with a nervous chuckle "Hehe, I'm just not good at Tables?" Do you use other means to overcome the deficit?

Why not learn Tables? Why not learn columns in CSS? Why not learn about adding Padding?

I'm serious, why not? There aren't a dozen things to know about most tags and attributes and I can guarantee you that if you can drive a car or bake a cake or even order dinner from a menu, you probably have already mastered things that are much more difficult than whatever it is you lack in the world of HTML or CSS understanding.

Let's take tables, for example. Tables are our most common compound tag. Compound tags require two or more tags to "build" a page element. In the case of Tables, we have <table> tags indicating where in the document our Table begins and ends, but then we must describe the actual table itself. In a way, the <table> tags are no different from any other tags. <p> tags indicate the beginning and </p> tags indicate the ends of paragraphs. Whatever it is that a paragraph is and does, we know where it begins and where it ends. With Tables, it's no different. We use <table> and </table>.

So, we have indicated where the Table starts and ends. Now we have to describe the Table itself. This is done left-to-right, in rows. You cannot have anything in a table if it doesn't appear within a row. That is, there must always be at least one row. Table Rows, in keeping with HTML's easy-to-remember tag naming scheme, are put down as <tr> and </tr>.

Once again, while it is necessary that these tags occur within the original <table> tags, there really is nothing special about Table Rows. These tags indicate where on the page, and where within the Table, a Table Row begins and ends.

Finally, the Table Data cells need to be identified. Hmm… Table Data. Do you suppose that's how they arrived at <td> and </td> as the tags involved? And do you think, as straightforward as all of the other tags are, that things would suddenly get jumbled and complicated, now? Or do you suppose that <td> tags merely show where within each Table Row a Table Data cell begins and ends?

So what have we built, so far? Well, we have indicated where on the page our Table should begin and end. We have indicated where within the Table a Row should begin and end, and within that Row, where the Table Data begins and ends. So taking that knowledge, just that little bit of understanding, what kind of table do you think this creates?

<table>
<tr>
     <td></td>
     <td></td>
     <td></td>
</tr>

<tr>
     <td></td>
     <td></td>
     <td></td>
</tr>
</table>

If this looks to you like a single Table, with two Rows, each with three cells, you're correct. See? It's really not that difficult. Just a few simple rules need to be followed: The number of cells in each row must always be the same. And we should not use Tables for page layout.

You can create some very intricate designs on your page using Tables. Columns, headers, borders and so on can all be created and manipulated at will. Where two, three or more boxes need to be reduced into a single box, we can use attributes such as colspan="" or rowspan="" to get the numbers to balance. In our table example above, if we were using the entire first row as a heading or some other single-column entity, we could have added a colspan="3" attribute to our first <td> tag. This is saying that the first Table Data cell actually spans three columns. This balances the number of cells in every row. The first row includes a single Table Data cell that now spans three columns, while the second row actually includes three <td>'s. The two are equal, so everything is fine.

There are several attributes we can apply to Tables. Cellpadding, cellspacing, a border width for example. And of course Tables can be styled using CSS to a degree that Table attributes don't allow. You can elect to have all borders appear as a single pixel, by applying border="1" to the table. But using CSS, we could style the bottoms of the boxes one way and the sides another. We could even make the left-side different from the right-side border, alternate background colors in rows, etc. CSS rocks, remember!

There are many little things involved, but none of this is as hard as doing your own taxes or taking the training wheels off of your child's bicycle. If you can dedicate only fifteen minutes every day to the task of Learning About Tables, you can learn it all within a week, probably. And, once you know it, you can keep that knowledge for the rest of your life. That's a bargain, isn't it?

And then you can get on with the task of learning The Next Thing.

The Shower and The Future

I get some of my best ideas in the shower.

I don't recommend it for everyone, but it seems to work for me. The shower, sitting at a stoplight, even while waiting in the car while my wife finishes the shopping. I seem to just need a few moments of Alone Time, to gather my thoughts and bring everything to bear on a problem.

Sometimes, you just can not do any more, sitting in front of a computer screen. When that time comes you have two choices: you can get up and do something else, or you can try to slog through the problem you are wrestling with for as long as it takes. In my experience, putting your head down and redoubling effort rarely pays off in finished work I am proud of.

I am not talking about giving up. I have not seen a nested-table design I could not unwrap, eventually, just by working in layers. But every week I come upon something I have no experience with that seems like it ought to be some easy variation of A, B, C that does not turn out to be as easy as that.

I have found that seven is about my limit of attempts. In almost every case I can get the basic idea down and flesh out the details right away and then spend a few attempts in adjusting the margin or padding or some other detail. But if I can't get it done in seven attempts, I need to get up and walk around, start in on another project and come back to the original problem later. It helps if "another project" has very little to do with the first work. For example, if I am trying to get some high-spiff navigation to work, it works best if I switch to catching up on my e-mail, attend a meeting or work on some other site's page footers. It does no good to switch from one navigation scheme to another. I can't even read a developer Web site if the story is about navigation. I need to get as far away from the problem as I can.

And then something amazing happens. It's like my brain solves the problem with idle cycles available throughout the day. I have been walking down the hallway when inspiration suddenly hits me. "Wrap it all in a <div> and apply the style to it! Or something.

You know more than you think you do. You have absorbed more than you think you understand. If you let your brain stew on a problem for a while, it may work out the puzzle for you while you are doing the laundry or grocery shopping. Just don't sit at your screen, trying to pound a round peg into a square hole. Get up and walk around for a bit and get some distance and you may be surprised at how quickly a solution pops into your head.

The future is coming, again.

Yesterday, we laid down the first plan for the next version of the Templates. I am liking what I have seen, so far. It is a careful plan with well-defined goals, clear and reachable deadlines and, again, the charter to incorporate as much of the new technology and tools that people have come to expect from modern Web sites.

Even back in grade school, I can remember the wonderful feeling of possibility, in holding a fresh, new, empty notebook. Later in life I beheld the blank first page of a word processor the same way, wondering if they give Pulitzer Prizes for computer reviews (sadly, no). Before you put that first character down, your work can become anything. Once you have committed to that first character, though, the rest flows more or less of necessity. It is an amazing transformation, and it happens quickly. We could do something, here. We could raise the bar. We could advance the cause. We could screw it up.

I love it. It's going to be a lot of fun, again.

Mid-Year Tune-Up

Where has all the time gone? I can't tell you, but I can tell you where half of the time has gone! It's mid-year, and a good time to take stock of everything you are doing, how it's all progressing and compare the reality to the hopes and dreams we all had back in the icy cold of January.

By now you should have checked all of your page footers and updated your copyright statement, at the very least, to ©2008. How is your navigation holding up? Are you linking to any long-ago abandoned projects, summaries, activities or other things of an expired nature?

Do you have title attributes on your related links? Do you have title attributes on your navigation? If not, why not? It's an easy fix to make, and it's one of those things you can do to your site that people really appreciate. Also, check your breadcrumb navigation and, if you're using it, your college navigation.

Speaking of college navigation, if you are using it, do you use it on every page of your site, or just some? Is it clear to your users which is which and when they should expect it and when not?

How about your graphics? Does the Ansel Adams vista of your building and the surrounding campus show trees that didn't survive the recent storms, or parking that has been re-engineered into green space? Is there new construction nearby that should appear in the background but doesn't? It looks pretty, but if it confuses someone looking for you it should probably be updated.

How about the basic structure of your Web site? Three times in the last three years I have happened upon someone else's idea of how a site should be architected and been… less than impressed. There can be a lot of politics involved, and you can't change a great many things about a site, but if you can streamline the structure and eliminate duplications and false-starts, you can drastically cut down on the time it takes to maintain your site—or train someone new to come in and maintain it for you.

Imagine opening up the top-level directory to peek inside and finding your old friends, the images folder, the sharedcode folder, the Templates folder, maybe a graphics and movies folder, and then your pages. Got an index.html page? Sure. index.shtml? Well, yeah, since the update. Are they the same? Shouldn't the .html page point at the .shtml page, by now? If you put a redirect into the .html version, anyone getting there from an old link or bookmark will automatically be forwarded over into the new page and you don't need to spend resources updating and maintaining both versions of what should be the same page.

A meta refresh is in order, here. You can place the following meta tag into the <head> of your document and anyone visiting this page will immediately be forwarded on to unl.edu. Since none of the content of the old page will ever be seen, you may as well delete it all, and just keep the basic framework of a Web page, with nothing in the <body> at all. Such a page will load quickly, and move the user along seamlessly to the new page. You can pause by changing the zero, below, to some other value, indicating how many seconds we should expect to rest on the old page, before moving along to the new.

<meta http-equiv="refresh" content="0;url=http://www.unl.edu" />

Make a point of opening up your Web site this week and deleting all of your false-start pages. If you have an index1.shtml, index2.shtml, index3.shtml as well as oldindex.shtml, newindex.shtml and testindex.shtml, it will be terribly confusing when it comes time
to train someone new in what is important, what can be deleted, what is actually being linked-to from various other pages, and so on. When I do these kinds of experimental pages, I try to name mine bogus.shtml or trashthisone.shtml to make it easier on the next person, but the best solution would be to delete these false-starts and experiments quickly, before they begin to take on the patina of legitimacy usually reserved for bad architecture.