The Thanking

It almost seems cruel, but the wheel has turned and it is once again Thanksgiving. A time to inventory our blessings, show a little gratitude, meet family we haven’t seen for a year, eat to excess and then gird our loins for battle in the morning, as dawn breaks over Black Friday.

I say cruel because a lot of us are worried about our jobs, again. This has become a regular feature of employment. We get dental and eye care and the constant question of Am I Going Have A Job Here Next Year?

In a lot of businesses you can see this kind of thing coming. I sold $X last year, but only $Y this year, and I don’t think they are going to be happy with that. Maybe you could have worked the angles a little better, been a little more clever, managed your time differently and made some difference. But it’s not a surprise—here’s the line, and this is you down here, under it.

Our situation is different. Money comes in, gets divvied-up however it does, by whoever does that sort of thing, and it turns out that we have come up short. The TV news announces we are a skillion dollars behind last years’ numbers.

Wow. That’s more than I make in a whole year. It’s more than I will make in a lifetime. Hell, I don’t know—it could be more than all of the Hiatts have ever earned.

After that dryness in the mouth goes away, someone comes up with some context. Yeah, it’s a skillion dollars, but that turns out to be less than two percent of year-ago fundage. Well, okay… that’s a lot, still. But it isn’t an insurmountable problem, right? Well, here’s where it gets interesting.

Some would say let’s take something out of reserve, give everyone a two percent haircut and wait for the Good Times to roll, again. News stories now tend to indicate the economic storm is over in many parts of the nation or in some key parts of the economy. See? Things will be better soon. We can all hold our breath for twenty-six weeks, if we know that’s as long as it will be.

But it doesn’t work like that. Instead, here, historically, the cap’n will throw someone out of the lifeboat, to make things better and easier for those who remain. We’ll motor along, Doing What We Do until the word comes down and then we will just decide that we don’t need to teach Principles of Elevator Operation any more, and that entire program is cut.

There are all manner of solutions to this. We could all take a tiny pay cut. We could all take a free day off every so often. We could use our current chairs and computers and copiers for an extra year, or two. We could cut back on travel. But for some reason it has been seen in the past as better to do it this way. Instead of everyone suffering a little, a few will suffer a lot.

From a strictly numbers point of view, I’m in good shape. So is my wife. The two of us together make a much wider target, but still, we are only two of hundreds and hundreds. So numerically the risk is probably greater walking to lunch or driving downtown. I teach people how to put information on the Internet. The Internet is more popular now than it was when you started reading this, and more information is moving from printed page to online, with a corresponding need for more people to know how to do that. It isn’t like I am teaching people how to operate an elevator.

But I have friends here, who work in shaky fields of shaky departments, doing work that probably won’t be missed the way, say, teaching Calculus or History would be. I hate the thought of missing them almost as much as the thought that the bullet hits me.

It doesn’t matter how good a job you do, this way. It isn’t about how long you’ve done it. If it is seen as a surplus line, the whole crew goes away. *Poof!* Like fish swimming in a school, with a fisherman overhead. What happened to Bob? Don’t ask, just keep swimming.

So yeah, I am thankful that I have a job. But I already wonder what next years’ Thanksgiving may be like.

Ping!

Shortly after the Earth cooled, and the waters receded, dinosaurs roamed the land. After an interval, the Internet and World Wide Web were developed and we came to need a way to display images online.

The old, dead, CompuServe network had already trod this path, and arrived at a marvelously clever solution for its day, the .gif file. Say “Jiff” or “Giff”, it doesn’t matter. The Graphics Interchange Format allowed for 256 colors—and one of them could even be “Invisible”. Transparency and interlacing were two of .gif’s best features, animation a powerful third reason to use it on your next page. The file format quickly became a favorite of anyone with only a few colors to display, anyone who needed to have a background image shine through around whatever was being displayed, or anyone who needed a very little motion on their page. The format was a perfect fit for most logos and graphics needs, not great at portraiture or landscape photography, though.

For that kind of richly textured image, you needed to use the other format, .jpg, from the Joint Photographic Experts Group. “Jay-Peg” files could feature as many colors as anyone needed, with correspondingly larger file sizes. But these could be slimmed-down quite a bit by means of lossy compression, by rounding-off sixteen hundred different kinds of Green to only a dozen or so. Most people don’t notice any difference at lower levels, and even when cranked up quite a bit the result is very often still Good Enough.

And, truthfully, it was a Good Enough kind of time back then. Most machines were connected, if that’s the word, via a none-too-fast modem. And quite a bit of computer output was limited to 256 colors back then, too. To see richer color required an extra expenditure for a state of the art video card, and even then the results were squirted onto only a 13” or 14” color monitor, probably. So yeah, Good Enough was good enough, for most of us.

A recurring theme of this blog is that Things Will Not Always Be Like This. And so it was in the graphics world. Video cards improved, monitors improved and online transmission speeds improved. But .gif and .jpg stayed the same. This happens in business until there is a compelling reason to move and in the middle 1990s it started to look like we might get that, when patents and lawsuits and confusion shared the world stage with rumors and no small amount of fear. The online subscription model was in trouble (I had two networks shot out from under me within a year or so, General Electric’s GEnie and Microsoft’s The Microsoft Network). Why would anyone think the people who owned the wasting asset of CompuServe would be willing to sit by and watch everyone continue to use their image format, for free?

This being the Internet, most people got most of the story wrong, of course. Unisys owned the patent for the creation of .gif, but stories floated out every week or so that one day we would all have to send a nickel to someone to display our animated Under Construction graphics. Work began on a replacement.

The fruit of that labor was the Portable Network Graphics format, .png (“Ping!”). .png files can be even smaller than .gif format files, they offer various levels of transparency and don’t suffer from generational losses the way .jpg files do. Save 20% of file size with every edit and you quickly get below 50% of the original .jpg image quality. Animating .png is not as easy as with .gif, but .png files don’t cloud up with artifacts when sharp color differences are present, as with high-contrast colors or text appearing in an image.

The .png file might be king today but for its missing the shipping deadline for the most-popular Web browser of the day, Microsoft’s Internet Explorer 6 for the PC. A lot of the gee-whizziness of .png was lost in IE6, so developers and designers had to ask themselves if it was worth going that extra mile for a file only twenty percent of visitors might even appreciate. For most, the answer was no, and so .gif and .jpg reigned supreme through another browser cycle.

Today, we even more need of high-quality images and graphics than ever before, and today we have the technology to back it up. If you are working in High Definition levels of image detail, consider breaking the old .gif or .jpg habit and trying a .png file for the task. You might surprise yourself—and your page visitors, too.

The Right Tool for the Job

Everywhere in Life, we struggle with the difference between what we can do, and what we should do.

In many cases, there is settled Law to help guide us. No matter how much an individual needs killin’, it isn’t up to us to carry out that obligation. Most often, there isn’t quite as much Black and White involved in the equation, though.

As it pertains to the Web, there seems to be no end of people who just bought a selection of fonts and are bound and determined to use them all, to get back the maximum value, I guess. Where two or three would be perfect, they need to sprinkle in six or seven. If a picture is worth a thousand words, then nineteen pictures would make a Web page worth a novella, right?

Two Olde Sayings come to mind, here. There is no accounting for Taste. And, if all you have is a hammer, everything looks like a nail.

You can write a bestselling novel in Microsoft Excel. It wouldn’t be fun, or easy, but you could do it. And just because you just learned JavaScript, you can animate your form buttons, have images slide across pages and trail a flock of geese behind every page visitor’s cursor. But that doesn’t mean that’s a good idea, either.

I always try to keep in mind the purpose of a Web page, and ask how this or that change or technology or feature might or might not fit in, given that choice.

I cannot imagine a need for Flash on a Web page for, say, a mortuary. If they are having a sale, should animated angels fly across the screen, carrying a banner saying Twenty Percent Off Cremations in January! or something similar? Maybe that’s too easy. Can I shop for caskets online—Do I really need to do that? But, if so, should the images be animated so clicking on the lid opens it up to reveal the fabrics on the inside? Should a site like that play mournful music at low volume by default?

I’ve been involved in sites where people had some idea of something they had seen elsewhere and wanted incorporated into their new site. The site they had seen was trying to sell something and was full of all kinds of razzle-dazzle effects. But their site was actually more of an informative page, barely even a brochure. Any of that would have gotten in the way of their customers finding the information they wanted.

It’s not like anyone would come back, just because the page navigation flew out from the side, tore itself off of the main menu and danced around the screen before artfully transforming itself into the newly-selected page. The people just want to know how big the gizmo is and if they can get a green one. They’re not going to tell their friends to come and check out this new Web site and even if they did, those friends aren’t interested in a new gizmo and wouldn’t come back later, either.

It’s early days, yet. A great many people making Really Important Decisions are not the ones who actually use the technology, still. Or care much about what it is and what it does. Somehow a rule is needed so one gets implemented. I was four years from my first Web page when I sat on my first committee. There, I was the most-experienced Web Guy on the panel—many people had no Web experience at all beyond clicking on the latest viral link of the day. But I was told that “Our logo needs to be somewhere on every page” and “Everything on our site needs to be accessible in three clicks or less” and several other chestnuts. Sometimes we still have to do things the way The Boss wants them done. Damnit.

Sure, you can. But should you? Is it really the best use of the time and talent and resources? Maybe step back a bit and try to see the bigger picture, and how your site fits into someone’s Webby day. Not every page needs to be Euro-design, spare and featuring acres of White space. And not every page needs to have a row of dancing piglets in ballet tutus high-kicking across the screen carrying a “Welcome!” banner to some Souza march. Choose the right tool for the job, please.

The Bigger Picture

Have you ever stopped to think about what it is that you’re actually doing, when you mark up a new Web page? And what’s all this about markup, anyway?

Whenever there is a new technology that is similar to something current, we see a massive adoption of the terminology, even the jargon, of the Olde Ways. Even customs and lore seem to transfer over. When Man learned to fly a hundred and six years ago, the closest thing we had to describe and govern this behavior was shipboard navigation, and so a lot of nautical stuff was quickly adopted and adapted for use in aviation.

The original idea behind the Web was that we would be laying out online documents… hmm… kind of like setting type. Sure it was much easier to add color or edit words, but the basic ideas seemed to fit almost perfectly. And since the language of typesetters was called markup, we took to marking up our Web pages. We don’t have any of the cool editing symbols, though I still remember a few of them. But the basic idea is the same. You start with a document, sometimes typed but sometimes handwritten, and you start putting little symbols into it to describe how you want it to look to the typesetter, who loads everything onto a giant plate, from which you print as many copies of the document as you need. Trust me, in Mark Twain’s day, this was heady stuff, indeed.

So from all of this we get the basic structure of HTML, today. All of our tags begin with “<“ and end with “>” and most sort of describe or remind us of their action. We put a slash in front of the same symbol to indicate we are done with its behavior, whatever it was. That is, a “p-tag” (<p>) begins a paragraph, while a “slash-li-tag” (</li>) indicates the ending of a list item. We start at the very top and the very bottom, with <html> and </html>, turning on and turning off the HTML-ness of our document. “Here is where our HTML begins, and here is where our HTML ends”. HTML being, let’s remember, the HyperText Markup Language. So we have a start and an end, and everything in between is (wait for it) HTML.

A section of our document has been set aside to help describe and control the rest of it. <head> begins the head of our page, and this is where we link to any external stylesheets or JavaScript pages and put any meta data we want to include and so on. Only the <title is actually visible to our page visitors here, unless something has gone horribly wrong. The rest of it is really only useful to Web servers, Web browsers and search engines. But we describe that area, too. <head> and </head>.

The part below the head is the body, so <body> and </body> come next. Every visible thing except for the page title appears here, so the body of your document is crucial. We place a tag under the </head> to indicate the body is starting, and one right before the final </html> tag to indicate we are done with the body, in a non-forensic doctor kind of way.

The elements inside the body tags are very close to actual nineteenth-century page markup. We place paragraph tags around the text we want to be paragraphs. We place heading tags around the text we want to be headings. We build complex tag structures to describe tables and lists. In those cases we need more than just an “it-begins-here” tag and an “it-ends-here” tag. We need to indicate the beginning and the ending of a table or a list, sure. But we also need to markup the various elements within it, too. With tables, we next describe the start and end of our table rows, and then inside those we even describe the beginning and ending of each individual table data cell. For lists, we must indicate the start and end of each list item.

I’m sure that back in the day there were people renowned for their markup skills just as there are, today. I’m sure there were pages that were structurally awful, but looked okay on the page just as we suffer today from bad markup with good-enough results.

We are probably lucky things turned out this way. The dominant model for computer communication of that era was a high-level programming language that translated the ideas of the programer into the machine language that the computer understands. We could easily have ended up with a markup model that involved either compiling or interpreting machine instructions. That would have led us down a whole different path.