I hope everyone had a great Thanksgiving break. We all got together, ate too much, had a wedding and ate too much again and now it's great to be back at work where I can get some rest!
I am a skeptic by nature. I sometimes feel like nobody in the room is more surprised or more pleased when we press that mighty [F12] key and a real, live, Web page loads and looks great! But what if something goes wrong?
Years ago, I was a mainframe computer operator and things went wrong almost every night. Something would blow up and I'd panic and call one of the Systems Analysts. "The big job just quit running!" I'd say, with probably more breathless drama than was really needed. "What does it say in the manual?" would come the reply. Rather than tell me how to fix the problem, he would tell me where to find it in the rack of books, and how to interpret what it said about the care and feeding of a mighty computer. I quickly learned to look up the problem first, and only if I didn't understand the manual to give the Analyst a call.
You might wonder how this applies to Web pages, since we don't have a manual for HTML. Well, we do, of a sort.
You can think of the WorldWide Web Consortium as sort of the company behind HTML, XHTML, CSS and several other technologies involved in serving up information online. The W3C, as it is known, provides an extensive online "manual" for each of the languages and protocols we use every day. Unfortunately, they are written more for people designing and building Web browsers than mere civilians like you and me. But for us there is something even more wonderful: The Validator.
Today, it is more important than ever that the markup we write is good. I don't mean inventive or original or even imaginative. I mean only that it conforms to the W3C standards. They have decided that Web pages should have <head>'s and <body>'s. You can create Web pages that don't have them, and they might work, today. But if you create pages that include them, they will work, today and tomorrow.
So if the page you see after pressing your [F12] key isn't quite what you had imagined, validate your page and see what kind of information comes back. There is a link in the footer of almost every UNL-templated page, to check that page for valid markup. I recommend you click that link and immediately check the option to Show Source and then re-validate your page. The reason for re-validating with visible Source is that so much of the information that appears on a templated page is Included. In Dreamweaver, we see only a single line of markup like this one: <!--#include virtual="sharedcode/bigfile.html" -->
The file bigfile.html could be one line long, or many hundreds of lines long. Either way, it is going to throw off the line count you see in Dreamweaver. So don't be surprised if the validator says you have an error on line #437 when your page in Dreamweaver is only 256 lines long. Also, don't be surprised if your error count is huge, at first. The results it records are cumulative, and if you make a big enough mistake, early enough in your page, everything from then on may be seen as a problem to the validator.
The validator will tell you not only what line, but in what column you are having a problem. Typical errors include un-escaped ampersand characters in URL strings, unclosed tag pairs and simple spelling errors. The validator will explain to you what it doesn't like and where it found it, you just need to match up the errors it sees with your own markup and make the changes. Changing & to & for example, will correct most problems with invalid URLs. Adding alt="alternate text" to images will fix most problems with invalid images, and so on.
Once you have got a page that validates, then you are in a place where a telephone call may be helpful. Validating your page goes a long way toward fixing display errors, as well as making your page much more accessible. Remember, we do more of this here at UNL than any other school we know of—so show a little pride and validate your pages before you finish.
Tuesday, November 27, 2007
Wednesday, November 14, 2007
There's Just So Much To Learn!
I was talking with a young lady recently who ran through a quick skills inventory and went on to tick through the various techniques and technologies she wanted to learn next when she stopped saying, "There's just sooo much to learn!"
She was right, of course. There is a lot to learn. And very often, somewhere along the line, some well-meaning soul helps us out by inventing some way around a lot of the knowledge—but then we have to learn how that works and so, net-net, it's probably a wash. Learn the language, or learn the program so you don't have to learn the language? Sadly, the answer is probably "both". Learn HTML and CSS? Or learn Dreamweaver? "Yes!"
Putting together a single web page might involve knowledge of HTML, XHTML, CSS, Dreamweaver, PHP, MySQL, Photoshop, Flash, Java, JavaScript, Apache, Linux, Windows, OSX, FTP, AJAX, Accessibility, Security, Templates, Forms and, of course, Design. I don't mean to scare anyone, but the list doesn't really even end there. There are any number of editors and helper applications, plus whatever rules and customs you must follow in your college or department. There is a lot to know. But you don't have to know it all quickly and in fact you probably don't have to know it all.
Most of us will quickly settle into a comfortable rhythm of making quick HTML edits and resizing images in Photoshop. But I have always felt that there is no wasted knowledge. If you spend only five minutes a week actively learning something—anything—about putting together better web pages, you will be rewarded. You will either start making a bag of money, or you will be spending less time doing the web pages and have more time to do everything else in your job, which still leads back to that bag of money.
Learning more about HTML (and XHTML) makes your page editing easier and faster and more precise. Learning how to lighten or darken photos will get you raves from the front office and from whoever is actually in the photos. And learning more about the features and functions of Dreamweaver makes your time spent in that application much more productive, as well.
There is a lot to learn. But that doesn't mean that you have to learn it all by the weekend. Suppose there are just fifty tags in all of HTML. If you set about learning them all, one per week, you would know all of the HTML tags in about a year. Now here's a little secret: I have been working on web pages since 1993, and there are HTML tags that I have never used. I know what they are and I sort of know what they do, but they have just never come up. There are going to be things like that in every area you set out to conquer. Very often you can tell early in the process what is going to be important and what isn't. Don't let it all intimidate you.
How can you learn it all? Putting aside the question of whether that is possible, or even a Good Idea, we each learn best differently. Some of us are visually oriented and we learn best by seeing things. Others are aligned more toward audio and we have to hear it to get it into our brains. Some of us are wired more for experience and we have to do things to learn them. Find your own best way and dig in. There are any number of books and Web sites that can help you learn HTML and CSS. We offer workshops and full-on training for people who need that. You can find friends and coworkers at the Web Developers' Network meetings you can ask for help. And don't be afraid to experiment. Create an unlinked page, "bogus.html" and just work your way down the various menu options. When you're done, just delete the page and keep the knowledge.
There is a lot to learn. You don't have to learn it all, and you don't have to learn it all right now. But you do have to make a start, and from there, if you are consistent, you can learn a lot.
She was right, of course. There is a lot to learn. And very often, somewhere along the line, some well-meaning soul helps us out by inventing some way around a lot of the knowledge—but then we have to learn how that works and so, net-net, it's probably a wash. Learn the language, or learn the program so you don't have to learn the language? Sadly, the answer is probably "both". Learn HTML and CSS? Or learn Dreamweaver? "Yes!"
Putting together a single web page might involve knowledge of HTML, XHTML, CSS, Dreamweaver, PHP, MySQL, Photoshop, Flash, Java, JavaScript, Apache, Linux, Windows, OSX, FTP, AJAX, Accessibility, Security, Templates, Forms and, of course, Design. I don't mean to scare anyone, but the list doesn't really even end there. There are any number of editors and helper applications, plus whatever rules and customs you must follow in your college or department. There is a lot to know. But you don't have to know it all quickly and in fact you probably don't have to know it all.
Most of us will quickly settle into a comfortable rhythm of making quick HTML edits and resizing images in Photoshop. But I have always felt that there is no wasted knowledge. If you spend only five minutes a week actively learning something—anything—about putting together better web pages, you will be rewarded. You will either start making a bag of money, or you will be spending less time doing the web pages and have more time to do everything else in your job, which still leads back to that bag of money.
Learning more about HTML (and XHTML) makes your page editing easier and faster and more precise. Learning how to lighten or darken photos will get you raves from the front office and from whoever is actually in the photos. And learning more about the features and functions of Dreamweaver makes your time spent in that application much more productive, as well.
There is a lot to learn. But that doesn't mean that you have to learn it all by the weekend. Suppose there are just fifty tags in all of HTML. If you set about learning them all, one per week, you would know all of the HTML tags in about a year. Now here's a little secret: I have been working on web pages since 1993, and there are HTML tags that I have never used. I know what they are and I sort of know what they do, but they have just never come up. There are going to be things like that in every area you set out to conquer. Very often you can tell early in the process what is going to be important and what isn't. Don't let it all intimidate you.
How can you learn it all? Putting aside the question of whether that is possible, or even a Good Idea, we each learn best differently. Some of us are visually oriented and we learn best by seeing things. Others are aligned more toward audio and we have to hear it to get it into our brains. Some of us are wired more for experience and we have to do things to learn them. Find your own best way and dig in. There are any number of books and Web sites that can help you learn HTML and CSS. We offer workshops and full-on training for people who need that. You can find friends and coworkers at the Web Developers' Network meetings you can ask for help. And don't be afraid to experiment. Create an unlinked page, "bogus.html" and just work your way down the various menu options. When you're done, just delete the page and keep the knowledge.
There is a lot to learn. You don't have to learn it all, and you don't have to learn it all right now. But you do have to make a start, and from there, if you are consistent, you can learn a lot.
Wednesday, November 7, 2007
Manage Your Mistakes
This happens to me fairly often, and maybe you've seen it or done it, too. I'm leaning over someone's shoulder as we both discover that Some Idea Doesn't Work. Before I can say anything, they select all of the relevant text and hit the [Delete]-key. All of the time, effort, energy and imagination that went into the failed effort is now... gone.
Well, okay, maybe not "gone". Dreamweaver will let you un-do all of the way back to a blank page. But still, maybe there was just a detail or two that kept success at bay. Here's a tip that I learned long ago when it comes to failed efforts: You may be a lot closer than you think and you may not realize it until you go down a blind alley or two. So, don't delete your first effort, comment it out, instead.
You spend twenty minutes wrestling with some element of your page, only to find out it doesn't work. Go back and add <!-- to the top and --> to the bottom. Browsers will ignore the markup that didn't quite work but it will still be there for you to compare, gather information from, de-bug and so on. If you are trying to get a Cascading Style Sheet to work some magic and discover it doesn't, you can comment-out the offending style rules by using /* and */ characters. Suddenly, the rules aren't gone, they just don't work. You can add back as many property-value pairs as you need to get things working as you would expect.
Next time you decide to convert a Table into a Division on one of your web pages and you don't want to get to a place where you can't come back, consider commenting-out the table and working from there. If it all gets too frustrating or the boss comes in with a Right-Now! project, you can roll back the changes by moving your comment tags from the Table to the new markup and save the new work for later.
Well, okay, maybe not "gone". Dreamweaver will let you un-do all of the way back to a blank page. But still, maybe there was just a detail or two that kept success at bay. Here's a tip that I learned long ago when it comes to failed efforts: You may be a lot closer than you think and you may not realize it until you go down a blind alley or two. So, don't delete your first effort, comment it out, instead.
You spend twenty minutes wrestling with some element of your page, only to find out it doesn't work. Go back and add <!-- to the top and --> to the bottom. Browsers will ignore the markup that didn't quite work but it will still be there for you to compare, gather information from, de-bug and so on. If you are trying to get a Cascading Style Sheet to work some magic and discover it doesn't, you can comment-out the offending style rules by using /* and */ characters. Suddenly, the rules aren't gone, they just don't work. You can add back as many property-value pairs as you need to get things working as you would expect.
Next time you decide to convert a Table into a Division on one of your web pages and you don't want to get to a place where you can't come back, consider commenting-out the table and working from there. If it all gets too frustrating or the boss comes in with a Right-Now! project, you can roll back the changes by moving your comment tags from the Table to the new markup and save the new work for later.
Subscribe to:
Posts (Atom)
