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.
Wednesday, November 11, 2009
Wednesday, November 4, 2009
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.
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.
Wednesday, October 28, 2009
Fixin's
You spill out all of your creative talent on a new Web page and after a while you just cannot stand not knowing any more. And so, with just a hint of trepidation, you hit your [F12] key to show the results in a real browser on the real Internet... and it looks awful. What do you do, at that point?
This is a question I seem to get the most. Well, this or some variation of it. How do you fix things? Okay, I took the training. I read the Google links. I looked it up in the book. Then I put down my best first effort and gave it a shot and came up short. Now what?
Validate your page first, of course. But suppose it’s not a syntax error you are hunting, but some weakness in your understanding of, say, Cascading StyleSheets?
When I was learning to fly, I had a Hell of a time learning to land, which is one of the skills you really want to become good at. I had a wonderfully patient flight instructor, though and he gave me the key: Try, as much as is possible, to always do the same things, and do them at the same time. I used to take off at 90 miles per hour the first time, and 110 miles per hour the next. Sometimes, I would climb to eight hundred feet before turning, other times, I would climb up to twelve hundred feet. Sometimes, I would turn toward the runway when I was a quarter mile from the end and other times, I would find myself half a mile away. And when I would turn onto my final approach, sometimes I would fly at 85 miles per hour and other times at 75 miles per hour. Sometimes I’d have the engine at idle and other times I’d be turning 1500rpm.
Every landing was different for me, because every landing was different. I never did the same thing the same way twice in a row, so who is surprised that each landing was a new adventure? Once I learned to always take off at 90mph and to always climb out at the same speed and always make my first turn at the same altitude and always reduce my speed abeam the same location on the runway, and so on, everything came together for me. You reduce your workload and get everything done early so you can more easily manage the fewer variables that have changed since the last time. You end up on Final approach with more or less the same “picture” out the window every time because you’re always more or less at the same place with the same airplane as you had last time. You’re not suddenly having to slow down, or account for a changing cross wind. And if you do have to account for those changes, those are the only changes you have to deal with.
Manage your variables is the lesson. Don’t change seven things and then check your pages, change one thing and check your pages. Work it out in your mind… what is it, specifically, you expect to see? And what are the differences between what you expect and what you get? Change one thing and you can immediately see the results of that change. But if you change nine things you may have a more difficult time seeing the effects of an individual adjustment. This is especially true when you are dealing with margins and paddings in CSS.
I am a big fan of putting a box around it, whatever “it” is that you’re working on, to help you to see what is actually happening on a page. Quite often there is a big difference between what you expect, what you think is happening and what is actually going on. You want to adjust the space between “this” and “that”? Draw a box around either element and then start making adjustments—just remember the border itself needs to be accounted for in that space. If you don’t declare a border, there won’t be one, of course. But if you do declare even a one-pixel border around an element, you will be placing two pixels in either the horizontal or vertical space you are working in. Remember that.
Work slowly, deliberately. Make a change, anticipate what it will do, and then check the results. Once you have the effect you wanted to achieve, or are happy with an accidental discovery, then move on to make other changes. And keep learning. Eventually, you will find that what you expect to see and what you actually get are more and more often the same. Then maybe you can back off a notch or two and only check every two or three changes. But if you’re surprised again, go back to the last time you weren’t and do the single-change thing again, stepping through the process until it all works.
This is a question I seem to get the most. Well, this or some variation of it. How do you fix things? Okay, I took the training. I read the Google links. I looked it up in the book. Then I put down my best first effort and gave it a shot and came up short. Now what?
Validate your page first, of course. But suppose it’s not a syntax error you are hunting, but some weakness in your understanding of, say, Cascading StyleSheets?
When I was learning to fly, I had a Hell of a time learning to land, which is one of the skills you really want to become good at. I had a wonderfully patient flight instructor, though and he gave me the key: Try, as much as is possible, to always do the same things, and do them at the same time. I used to take off at 90 miles per hour the first time, and 110 miles per hour the next. Sometimes, I would climb to eight hundred feet before turning, other times, I would climb up to twelve hundred feet. Sometimes, I would turn toward the runway when I was a quarter mile from the end and other times, I would find myself half a mile away. And when I would turn onto my final approach, sometimes I would fly at 85 miles per hour and other times at 75 miles per hour. Sometimes I’d have the engine at idle and other times I’d be turning 1500rpm.
Every landing was different for me, because every landing was different. I never did the same thing the same way twice in a row, so who is surprised that each landing was a new adventure? Once I learned to always take off at 90mph and to always climb out at the same speed and always make my first turn at the same altitude and always reduce my speed abeam the same location on the runway, and so on, everything came together for me. You reduce your workload and get everything done early so you can more easily manage the fewer variables that have changed since the last time. You end up on Final approach with more or less the same “picture” out the window every time because you’re always more or less at the same place with the same airplane as you had last time. You’re not suddenly having to slow down, or account for a changing cross wind. And if you do have to account for those changes, those are the only changes you have to deal with.
Manage your variables is the lesson. Don’t change seven things and then check your pages, change one thing and check your pages. Work it out in your mind… what is it, specifically, you expect to see? And what are the differences between what you expect and what you get? Change one thing and you can immediately see the results of that change. But if you change nine things you may have a more difficult time seeing the effects of an individual adjustment. This is especially true when you are dealing with margins and paddings in CSS.
I am a big fan of putting a box around it, whatever “it” is that you’re working on, to help you to see what is actually happening on a page. Quite often there is a big difference between what you expect, what you think is happening and what is actually going on. You want to adjust the space between “this” and “that”? Draw a box around either element and then start making adjustments—just remember the border itself needs to be accounted for in that space. If you don’t declare a border, there won’t be one, of course. But if you do declare even a one-pixel border around an element, you will be placing two pixels in either the horizontal or vertical space you are working in. Remember that.
Work slowly, deliberately. Make a change, anticipate what it will do, and then check the results. Once you have the effect you wanted to achieve, or are happy with an accidental discovery, then move on to make other changes. And keep learning. Eventually, you will find that what you expect to see and what you actually get are more and more often the same. Then maybe you can back off a notch or two and only check every two or three changes. But if you’re surprised again, go back to the last time you weren’t and do the single-change thing again, stepping through the process until it all works.
Subscribe to:
Posts (Atom)
