How do you learn?

How do you learn things? Ever think about that—about how you learn best?

Some people are definitely wired to respond better in one channel than other. And some tasks lend themselves better to one channel than other, too. Some people learn best when they can read about a subject. Give them a book and a few hours and they will come back understanding how to fund their retirement account. There isn't a lot to be gained by making someone stand in line at two or three banks, brokerages and insurance companies, learning how to open up an IRA account.

Some folks can do pretty well just sitting in classroom situation and having someone preach to them. Maybe they're good note takers, or maybe they are just good listeners. That's how I got through most of my elementary and even junior and senior high classes, really. Maybe sixty percent of whatever I learned in school was just reciting things someone else had poured into me at one time or another. Classroom work involves both visual and aural input. You see things and you hear things and the hope is that you will absorb some measure of it and not be Left Behind.

Others are do-ers, and other tasks are best learned by example. You can read about driving a car and learn a lot of the theory and rules of the road and so on. But you really don't get the tactile feedback you need to process to actually learn to drive a car. There is a crown in most roads and you need to apply a little pressure on the steering wheel to counteract the tendency for a car to drive itself into the weeds. But how much pressure is needed, and for how long? What if you need to turn a corner in a crowned road? We won't even get into the absurdity of trying to learn parallel parking from a chapter of Driving For Dummies.

So, we have all kinds of people, and we have all kinds of processes and some of them lend themselves well to the task in only certain circumstances. This is why we try to touch on so many of the senses in our workshops. There are many pages or slides involved in teaching HTML, but you really aren't going to learn the language that way, are you? Each contains a lot of information, and probably all of it is important in one way or another, but you don't have to read every word from the overheads to "get it". It would not be very effective if I just stood at the front of the class and read the information to you, either. I can't think of anything more boring than having someone read me a slide that I can see for myself. And when you're bored, you start thinking about what's for dinner, tonight, and whether or not your income tax refund has arrived yet and whether you should replace your wiper blades out of this paycheck or whether you could wait for anoth—what? Wait, what did he say about image tags, again?

I try to keep things moving, so you don't have time to linger on any point long enough for laundry or grocery shopping to intrude. When we look at workshop feedback, most of my responses come back saying the pacing was either just right or a little fast. It's rare that anyone says they were too slow or too fast, and I'm happy with that because I know the misery of listening to someone droning on and on about something nobody in the room is interested in (including, often enough, the speaker).

But not every technique is going to land with every student who attends every workshop, no matter how good a writer did the words, no matter how good of a graphic designer laid out the slides or pages, no matter how well the teacher speaks. At some point we all have to take some responsibility for what we learn.

In all of my workshops, I have places built-in where I stop and ask for questions, often reminding people of the last two or three things we have covered. "Okay, any questions about page headings? Any questions about lists? Everyone understand anchor tags?"

And I almost always point out that books are available that run to seven and nine hundred pages on most of these subjects, so we necessarily have to leave something out to get everything done in only two hours. Generally, we finish early and I always try to say something like "Okay, was there anything that you had hoped to learn today that we didn't cover?" We frequently have the use of the room for another fifteen or twenty minutes and I'm more than happy to talk about anything anyone brings up.

But most often, everyone gets up and leaves. I try not to take it personally.

There's A Storm a Comin'!

Just like in the old Western movies where someone announces the story conflict with those archetypal words, the Web design world is about to enter a tempest that shakes up tradition going back more than a decade.

Until now, progress has been pretty linear on the Web. HTML debuted and browsers were launched, and they both developed into version two, version three and so on. If you started writing to the HTML 4 standard, you were writing better markup than before. If you were using Netscape Navigator 4, that was a better browser than version 3, and so on.

All that may be about to change.

We teach in the Intro to HTML class that browsers ignore tags they don't understand. This was a neat feature of the early Web. If you happened upon a Table with Netscape's second browser it didn't cause your computer to lock up, sending a little trail of smoke out the back of your monitor. You still got all the data, all the information, from the Web page you were looking at. It just wasn't in a tabled format.

Now, you could argue that they weren't doing you any favors with this, because reading tabular data without a real table is a bear. But at least the information was available. This was the promise of the future. If you ever found yourself in 2011 with only an old Pentium-II laptop that only had Internet Explorer 5 you could still order floor mats for your flying car online, because IEv5 would ignore all of the 3-D tags in HTML 7. Or so we were told.

This is the part of our story where the freckle-faced little girl climbs up on the rail fence, looks to the horizon and squints, shielding her eyes with a childlike salute and announces, "Storm's a-comin'!"

Netscape lost the lead in the browser market because time and development stopped at Navigator 4 for too long. Microsoft rolled out their version 5 of Internet Explorer and quickly capitalized on that with version 5.5. Internet Explorer came along 6 comfortably within three years. Netscape had a good start on a bad browser with Navigator 5 and abandoned it, refocusing efforts on Navigator 6 but by the time it arrived, the Browser Wars were over. The remnants of Netscape will disappear at the end of this month.

So Microsoft won, if that's the word, the Browser Wars. And they celebrated by de-emphasizing development of their browser, Internet Explorer. The lesson of Navigator 4 was lost and Internet Explorer 6, which shipped in October of 2001, was still the original-equipment browser in October of 2006. During this time we saw the rise of Opera and Safari and especially Firefox, an open-sourced browser with excellent standards support.

Microsoft finally responded with IE7, in October of 2006 and to their credit they fixed a number of errors in IE6. But in fixing the browser so it finally adhered to standards published more than a decade before, Microsoft actually broke many Web sites built by people who had learned to work around the shortcomings of Explorer 6.

Now Microsoft are scrambling to avoid the tyranny of the installed base. They are the most-used (I can't quite bring myself to say "most popular") browser by far. And their most-used browser was out there with all of its flaws for five years and every day another… what, hundred? thousand? Web sites were published?

So Microsoft's feeling is that they are doing us all a favor by freezing things, now. Unless you include a special line of markup in all of your future Web pages, their upcoming IE8 is planning on rendering pages as though it was IE7. In three years, or five years, or whenever, IE9 will render those same pages no better than IE7 did on its best day. And IE10 will render perfectly-formed, standards-compliant Web pages just like (wait for it…) IE7, too. In order to get the improved rendering we expect is still on the way from Microsoft, we have to opt-in, with special versioning codes.

They say they don't want to "break the Web". They say that heads-up developers who lean on the standards are the ones most likely to keep up, most likely to learn to include this one extra line. Your typical bowling league webmaster probably hasn't read anything on HTML since "Learn To Make Web Pages In A Day" back in 1999, and is thus out of the loop.

Damnit, I can see both sides. And this might be easier, on some level, but really it only just prolongs the agony. Microsoft intends to pull of the IE6 Band-Aid™ over the next twelve or fifteen years, rather than turning out a browser that, by default acts like the best browser a skillion-dollar company can come up with.

I don't like the precedent. I don't like the idea that the next browser company can get a line on every Web page, too. Or that Microsoft may change its corporate mind in three years and we'll end up including three or four or twenty lines of markup in every new page, just to get browsers to act they way they should have in 2000.

It's not a war. We don't have to take sides. There's a storm coming, though, and someone is going to get wet.

document.write("Learning JavaScript")

Well, it's happened. I have begun to learn JavaScript. I know—nobody is more surprised about this than me.

Some background, for those of you just joining us: Way back in the mists of time, circa 1995, the once-mighty Netscape Communications corporation decided that the future of the Web involved offloading some of the required processing power to the users' own processor, rather than depending upon servers for everything a Web page did. This was important, in a world of dial-up modems. The chief benefit, though, was that letting the users' computer chew on things allowed for a degree of interactivity we had not seen, before. They named their creation LiveScript, but a lot of light and heat in the tech world of the day centered on Sun Microsystems and their new programming language, Java. At the last minute, Netscape's scripting language was renamed "JavaScript" even though JavaScript has about as much to do with Java as Lightning Bugs have to do with Lightning.

Kewl! But what does that all mean?

It means that, using a client-side scripting language allowed for Web pages that reacted to various actions a user might take. Hover your mouse over a menu, for instance, and you might hear a click or a beep and the menu itself might grow or expand or change in some meaningful way. From a user-interface standpoint, this was pretty cool. You could now provide some useful feedback to your users that they were hovering over a link. But like a lot of tools, JavaScript could be misused, too. A great many pages were built that required JavaScript. If your browser was one of the few that did not have JavaScript, you were out of luck, as were the more paranoid among us who had JavaScript-enabled browsers, but who had turned JavaScript off in hopes of somehow enhancing their online safety. A movement began to use JavaScript to enhance necessary things like navigation, rather than to replace them.

Concurrent with all of this, we saw a rise in the use of Cascading Style Sheets, CSS, for many of the actions JavaScript was famous for. And the mighty Flash juggernaut continued to gain steam and Flash allowed for all kinds of actions and reactions to user input. So for a period of time there JavaScript was on the wane.

I was really happy about all of this, and long held the theory that JavaScript would become the Web's first dead language. JavaScript would become Web Latin. I remember the day a few friends decided to study JavaScript and asked me if I was interested in joining them and I told them no. And for a few years there, I was happy with my decision. I saw fewer and fewer pages with complex JavaScripts and so I must have been right.

But then one of those geeks with no girlfriend who spend their evenings moving the cutting edge came up with something new. AJAX arrived early in 2005, providing Asynchronous JavaScript and XML.

We have talked about XML, before. XML, the Extensible Markup Language is the future of the Web. I have noodled around with a little of it, and it's pretty cool. You can actually write your own tags in XML. It's all about describing the content of a page, though. To an even higher degree than using one of the strict document type definitions, XML separates content from presentation. Think of your <title> tag. It doesn't apply italics or change the color of your page title, it only titles the page. XML is all about that kind of thing.

Asynchronous roughly means "no timing" and in this instance means that the communication is more akin to a telephone than an old CB radio. Saying "Over" is the hallmark of synchronous communications like two-way radios. I talk. I indicate I'm done talking. You talk. You indicate you're done talking. I talk again. On the phone whether or not I'm talking has no bearing on whether or not you talk. It's possible to interrupt someone, on the phone. So that's AJAX, then. XML being monkeyed with at any given time, using the magic of JavaScript.

We'll see…. But I now have a renewed empathy and respect for anyone who is learning anything new about the Web. And it appears that learning new things about Web development is something that isn't going to stop, or even slow down, any time soon. I am a long way from AJAX, where you download a page and all kinds of additional stuff that may or may not appear or happen, depending upon what you point at or click on, without any further interaction from the Web server. But I am dipping a little toe into the JavaScript waters, and we'll see how this one goes.

What Is Important?

From time to time, Life has a way of smacking you around and reminding you of a few things. It's good to take some time now and again to appreciate a few things, and to stop and consider what is really important.

I think validated markup is important. I think spell checking a page is important. I'm really a fan of the title="" attribute. Deadlines, certainly, are important. Knowing as much HTML and as much about Dreamweaver as you can is important. But something happened this week that really serves to show how trivial a great deal of our days really are.

Tuesday morning, our Associate Vice Chancellor, Kent Hendrickson, was killed in an auto accident on his way to work. He was in the autumn of his years, as the poets say. But he was in pretty good health—certainly healthier than me. So it wasn't expected, as when someone has a lingering illness. He was here, and then he wasn't. I still have an e-mail in my Inbox from him, from last week. And now he's gone.

Every time I was ever in his presence, Kent spoke to me, usually calling me by name. I have never been in a situation before where my boss's boss's boss's boss even knew my name, but Kent not only made the effort to learn my name, but also what I did for him every week.

I ran into Kent at Wendy's one day, having lunch with another of the staff from Fourth Love. He waited for my wife Kathie to get to the table and settle in, and then laid a little praise on me with a wink. As we were walking to the car after lunch, Kathie said "You know, the only way that could have been any better would have been if your dad could have heard it!" and she was right. Here was a guy whose head was full of budgets and plans and task forces and committees and facilities and all the rest, but he very generously took a moment and shined-up my whole week.

Kent had a great sense of humor and was very approachable. One afternoon on my way to a meeting in the Student Union, I came upon Kent at lunch alone. "What's the matter, Kent? Did you piss everyone off, again?" I asked and then worried that soda might start coming out his nose as he shook his head, laughing. Some people are afraid of their boss's boss's boss's boss. I never was afraid, around Kent.

Look, it's important that we realize that the twenty-first century is going to happen online. It's important that we build the best web sites we can. It's important that we learn to use our languages and our tools as best we can. But there are other things, too.

Maybe take some time this evening. Hug your family. Play with your kids or dog or even your spouse. Think about anything but Web sites for an evening or two. And make sure that how you fill your days is really important. The Web will still be here, tomorrow.