Some of us can be told something and, just through hearing it, pick it up. Others have to see it. If you can draw it out on the board, they'll understand what you mean. Still others have to actually do something for it to stick. No amount of lecture or audio-visual presentation will help. They need to sit down and actually try to do something, in order to really learn it. I try to include a little of everything in my training workshops, to catch everyone, because Not Everyone Learns Best In The Same Way. Not everyone wants to hear me go on and on about the elegance of a well-styled web page. Not everyone wants to read the material off of a screen or out of a book. It's good to cast as wide a net as you can, in these matters.
One of the biggest challenges I face every day is remembering that Not Everyone Uses The Web The Way That I Do. You may have run across this in your own Web surfing, if you find yourself visiting familiar sites with a new computer, a laptop, for instance. Laptops frequently have differently-sized screens, and occasionally, slower connections. All of a sudden pages that look fine on the office computer are squished, or the text is so small as to be almost unreadable, or pages that come up quickly seem to be taking forever to load. This kind of exercise is good to put yourself through once in a while, because the odds are very good that there are only a few other people out there with precisely the same combination of computer, monitor, connection speed and Web browser as you are using.
Spare a thought to those who are muddling through with less-than-optimal equipment. They cannot put any more memory into their machine. They cannot upgrade to the newest browsers, they cannot devote three minutes to download a single graphically-rich Web page, and would not be able to appreciate the difference in graphics anyway.
A dozen years ago, things were probably simpler. Pretty much everyone had a thirteen inch or fifteen inch monitor and a 9600bps modem, and we were pretty much all using Netscape Navigator. So we all did pretty much see the same things in the same ways.
But today we can't count on that at all. Have you see how your favorite pages look on the new Apple iPhone? It's a real eye-opener, to many talented Web designers. We can now expect visitors to our Web pages with 30" Cinema displays and 3½" iPhone viewports, too. How can you strike a balance in a world like that? It's not really difficult. Just give a little thought to how a page is likely to be used, and remember to always validate your markup. Well-formed (X)HTML and CSS goes a long way toward keeping the widest range of your users happy.
I hope you have a safe and happy holiday break, and look forward to seeing you in a workshop or at a WebDevNet meeting in the coming year.
Wednesday, December 12, 2007
Wednesday, December 5, 2007
Tidy Up!
This is a great time of year to close the books on things that didn't work out, and prepare to start new projects and make new beginnings in the year ahead.
Do you run a clean shop? Suppose your website has a dozen pages and thirty images or graphics. How many web pages are actually in your working directory? And how many photos and images are inside your images folder? Are you linking to a style sheet, or three?
Here's how I work: I start marking up pages and get to the point where I'm uncertain of how to proceed. Then I'll stop and do some heavy-duty thinking about my options. Very often, I need to actually see the alternatives. Maybe there are browser issues and what I want to do doesn't look or work right in one of the popular browsers. So I will actually copy the page I am working on and add a little sign to the name that tells me I can toss the file, eventually.
So login.shtml becomes boguslogin.shtml while I sketch out how the form is actually supposed to look and work. I get the fonts right. I monkey with the colors, and the spacing above and below, left and right. Try it with a frame and without. Maybe inside one of those fancy fieldsets. When everything is as I had hoped it would be, I copy and paste the trial-and-error results into the actual Web page, and go on to the next thing. If you have been paying attention, you'll notice that I didn't finish up by saying "And then I delete the old, dead, boguslogin.shtml page.
I have a lot of boguspage.html pages in my local directories—and by extension on the remote server. I always imagined that One Day I would get rid of them, but of course One Day never comes. I get a site working with an original stylesheet, add one of my own and then add an experimental stylesheet, linking to originalstyle.css and newstyles.css and to maybestyles.css. One day, I promise myself, I'll go through and clean up all of the duplicate style rules and get down to a single CSS page. That day never came, either.
But this year, before the break, I have actually scheduled time in my week to clean things up. I never thought much about this until looking over the shoulder of a coworker recently who was much closer to Felix Unger in personality than I am. It was amazing how much easier it was to work when you could see all of the files in the website, in the files list. It took no time at all to see the first page, the next three, and the two under those and imagine how they all fit together.
If you're like me and your workspace is full of output01.html, output02.html, output03.html and goodoutput.html, you could benefit from a little cleaning and consolidating, too, probably. Give it a try. You save a lot of time looking for files, and you will save a lot of server resources, too.
The coming new year is a great time to try to start new habits. This is one I'm going to work on very hard, in the year ahead.
Do you run a clean shop? Suppose your website has a dozen pages and thirty images or graphics. How many web pages are actually in your working directory? And how many photos and images are inside your images folder? Are you linking to a style sheet, or three?
Here's how I work: I start marking up pages and get to the point where I'm uncertain of how to proceed. Then I'll stop and do some heavy-duty thinking about my options. Very often, I need to actually see the alternatives. Maybe there are browser issues and what I want to do doesn't look or work right in one of the popular browsers. So I will actually copy the page I am working on and add a little sign to the name that tells me I can toss the file, eventually.
So login.shtml becomes boguslogin.shtml while I sketch out how the form is actually supposed to look and work. I get the fonts right. I monkey with the colors, and the spacing above and below, left and right. Try it with a frame and without. Maybe inside one of those fancy fieldsets. When everything is as I had hoped it would be, I copy and paste the trial-and-error results into the actual Web page, and go on to the next thing. If you have been paying attention, you'll notice that I didn't finish up by saying "And then I delete the old, dead, boguslogin.shtml page.
I have a lot of boguspage.html pages in my local directories—and by extension on the remote server. I always imagined that One Day I would get rid of them, but of course One Day never comes. I get a site working with an original stylesheet, add one of my own and then add an experimental stylesheet, linking to originalstyle.css and newstyles.css and to maybestyles.css. One day, I promise myself, I'll go through and clean up all of the duplicate style rules and get down to a single CSS page. That day never came, either.
But this year, before the break, I have actually scheduled time in my week to clean things up. I never thought much about this until looking over the shoulder of a coworker recently who was much closer to Felix Unger in personality than I am. It was amazing how much easier it was to work when you could see all of the files in the website, in the files list. It took no time at all to see the first page, the next three, and the two under those and imagine how they all fit together.
If you're like me and your workspace is full of output01.html, output02.html, output03.html and goodoutput.html, you could benefit from a little cleaning and consolidating, too, probably. Give it a try. You save a lot of time looking for files, and you will save a lot of server resources, too.
The coming new year is a great time to try to start new habits. This is one I'm going to work on very hard, in the year ahead.
Tuesday, November 27, 2007
It Didn't Work!
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.
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.
Subscribe to:
Posts (Atom)
