Going Javascript Crazy

gjcIt sounded like my latest career move was going to be a bit more interesting than I had planned. Congratulations, Bob, on your new job. Belo’s quite an outfit,” read the note from the estimable editor of this fine journal. “And, uh, ummm, do you plan to still write a column for ajaxlessons.com? I know you won’t leave us in suspense for the follow to the last one you wrote. The one about sex.”

The note went on to offer helpful hints and insights into Texas life, including this bit of borrowed wisdom: “If I owned both hell and Texas, in the summer I’d rent out Texas and live in hell.”

Nothing like a bit of encouragement. But I suppose a few explanations are in order.

By the time you read this, I will have left my position as the founding director of the American Press Institutes Media Center to become senior editor for information commerce and technology at A.H. Belo Interactive. I had a wonderful two years at the Media Center. I did the things I set out to do – at which point Belo offered me a challenge I couldn’t refuse.

I’ll continue to write this column for Quill. I’m grateful that Quill wants me to do it.

And I’ll certainly finish up the topic I took up last issue, which was the user interface and gender – not sex. I have enough trouble figuring out computers without wandering into Dr. Ruth territory.

Fair warning: This issue we go swimming in deep technical waters.

Take a look at this JavaScript, which is designed to be an invisible Web page.

<SCRIPT LANGUAGE = “JavaScript”> <! – bName = navigator.appName; bVer = parselnt(navigator.appVersion);

if (bName = = “Netscape” && bVer > = 4) br = “n4”; else if (bName = = “Netscape” && bVer = = 3) br = “n3”; else if (bName = = “Microsoft Internet Explorer” && bVer > = 4) br = “e4”; else if (bName = = “Microsoft Internet Explorer”) br = “e3”; else br = “n2”;

//Frame for IE 4 with Dynamic HTML. if (br = = “e4”){ document.write(‘<FRAMESET ROWS = “100%, *”

FRAMEBORDER = NO BORDER = 0>’); document.write(‘<FRAME SRC = “inter. htm” SCROLLING = AUTO>’); document.write(‘</FRAM ESET>’); }

//Frame for NN 4 with Dynamic HTML. if (br = = “n4”) { document.write(‘<FRAMESET ROWS = “100%, *” FRAMEBORDER = NO BORDER = 0>’); document.write(‘<FRAME SRC = “inter. htm” SCROLLING = AUTO>’); document.write(‘</FRAM ESET>’); }

//Frame for every other browser. else { document.write(‘<FRAMESET ROWS = “100%, *” FRAMEBORDER = NO BORDER = 0>’); document.write(‘<FRAME SRC = “noninter.htm” SCROLLING = AUTO>’); document.write(‘</FRAM ES ET>’); }

//->> </SCRIPT>

Note what I am doing in this JavaScript. I am telling the server to sense the browser, and then storing that information as a variable. I can then run conditional statements against that variable!

This particular script is simple – it just loads one page or another, depending on the variable – but the power of this technique should be clear. If we can store one variable, we can store N variables. We can then track the intersection of data points, and supply navigation based on the results.

Demographic marketing, for example, uses data mining techniques to produce accurate results with very little data. People moving to Washington, D.C., and Northern Virginia to work in an executive position who choose to live in the town of Leesburg buy Jeeps, not Ford Explorers. Why? There’s a long, complicated explanation, but that doesn’t matter. Suffice to say that if you collect enough data, you can fit people into large patterns given just a few data points.

And who has more data about your site than you? Think of the power – if you track and correlate the way people navigate your site, you will be able to offer tailored-on-the-fly navigation for visitors.

Before we get complicated, though, there’s good news. There’s plenty of information available to the server from the browser without further ado – and much can be done with it.

Last month we discussed modifying the interface on the fly, based on the user’s learning style – that was the gender stuff – by using what your server knows about each browser. At a minimum, your browser knows the protocol each surfer is using – that’s why you type HTTP before an address to tell the browser to make a HyperText Transfer call and it knows which browser is calling. That is how we sensed the browser in the above script, and the IP address the surfer is calling from, which tells us where to send the data.

But that last bit of info also tells us who is calling. For example, we know that 134.68.42.XXX is an address from the local university; you can always use WHOIS to look up a domain and find out the IP.

Think of how you could use that info with this script. You could, for example, modify the display and menus based on the incoming IP, highlighting today’s activities for users surfing from the campus and commuter info for those surfing from off-campus.

Where do you want to go today? (Sorry.)

The problem is that interface design involves a constant tradeoff. The more links you put in, the less room there is for content. The fewer links you put in, the harder it is to get there from here.

The problem, of course, is that most layout tends to treat the screen as a page – that is, layout is fixed in place the way it would be on paper. What little interactivity there is tends to be ad swapping or graphic rollovers – lots of flash to drag through a narrow modern pipe for such a small payoff.

Dynamic devices such as this column’s JavaScript allow you to circumnavigate this problem by endeavoring to put on screen only the things each user wants and needs – what I call the iceberg theory of interface design.

As we all know, most of an iceberg is underwater. And since screen real estate is limited, only the tip of the navigation iceberg makes it onto a user’s screen, no matter what.

The trick is to get the right piece of the iceberg on screen.

Part of the blame here has to do with the basic structure of HTML. The HyperText Markup Language is a Document Type Definition. Because it is a static DTD, it is difficult to do anything beyond what the DTD was designed to do – in this case, describe a page. This limitation explains why anything beyond the plainest Web design requires scripting, Java, CGI, and so forth.

That is finally changing. HTML is being replaced by Dynamic HTML, XML, and the Document Object Model.

Leave a Reply