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.
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.
Wednesday, October 31, 2007
Is Dreamweaver CS3 Worth It?
It's a question I get asked a lot. In the hallway, on my way to or from a meeting or class… "Is Dreamweaver CS3 Worth It?"
My answer is almost always "Yes!" Dreamweaver changes pretty frequently, these days. And the last several revisions have brought an increasing emphasis on Web Standards, doing more things the right way, easier, than ever before.
We used to get a new Dreamweaver every two or three years, but they're coming much faster, now. The developers would take note of comments and service issues and we would get bug fixes and new features at regular intervals. Still, version One looked an awful lot like version Three, and so on. That all stopped with what would have been Dreamweaver 6.
I like to say that about that time, they hired a man of Vision, and the result was Dreamweaver MX 2000, with a whole new look and a great many new features aimed at making it easier to build standards-compliant pages. Dreamweaver MX 2004 was next, building on the interface of the previous release. If you had a Dreamweaver 3 or Dreamweaver 4 book, you were kind of lost. But if you had a Dreamweaver MX 2000 book, you could still find your way around and puzzle-out the new features. Then, according to my theory, the man of Vision must have quit, because the next box was again labeled just "Dreamweaver 8".
But the same thing held true, with regard to books and features. If you had a Dreamweaver MX 2004 book, or even a Dreamweaver MX 2000 book, you could find your way through Dreamweaver 8, even if that meant missing out on a few of the latest features. The work flow and interface has changed only minimally over the recent past.
What would have been Dreamweaver MX 2007 or Dreamweaver 9, maybe, is now called Dreamweaver CS3 (the CS standing for Creative Suite). Once again, in many ways it looks like Dreamweaver 8, Dreamweaver MX 2004 or even Dreamweaver MX 2000. But there are a great many features and benefits, especially helpful for us here at UNL using the Templates to build pages. Good work has been done in upgrading CSS positioning support, creating pages, adding Assets, Snippets and Library items and also interfacing with various scripting languages.
If your department, college or campus organization has some upgrade money in the budget, I'd recommend getting Dreamweaver CS3. If you only just recently made the move to Dreamweaver 8, you can probably wait a while before upgrading, with the understanding that computer software is a lot like fresh fish: the older it gets, the less anybody wants it. Dreamweaver CS3 is going to be current a lot longer than Dreamweaver MX 2004 will remain usable, let's put it that way.
My answer is almost always "Yes!" Dreamweaver changes pretty frequently, these days. And the last several revisions have brought an increasing emphasis on Web Standards, doing more things the right way, easier, than ever before.
We used to get a new Dreamweaver every two or three years, but they're coming much faster, now. The developers would take note of comments and service issues and we would get bug fixes and new features at regular intervals. Still, version One looked an awful lot like version Three, and so on. That all stopped with what would have been Dreamweaver 6.
I like to say that about that time, they hired a man of Vision, and the result was Dreamweaver MX 2000, with a whole new look and a great many new features aimed at making it easier to build standards-compliant pages. Dreamweaver MX 2004 was next, building on the interface of the previous release. If you had a Dreamweaver 3 or Dreamweaver 4 book, you were kind of lost. But if you had a Dreamweaver MX 2000 book, you could still find your way around and puzzle-out the new features. Then, according to my theory, the man of Vision must have quit, because the next box was again labeled just "Dreamweaver 8".
But the same thing held true, with regard to books and features. If you had a Dreamweaver MX 2004 book, or even a Dreamweaver MX 2000 book, you could find your way through Dreamweaver 8, even if that meant missing out on a few of the latest features. The work flow and interface has changed only minimally over the recent past.
What would have been Dreamweaver MX 2007 or Dreamweaver 9, maybe, is now called Dreamweaver CS3 (the CS standing for Creative Suite). Once again, in many ways it looks like Dreamweaver 8, Dreamweaver MX 2004 or even Dreamweaver MX 2000. But there are a great many features and benefits, especially helpful for us here at UNL using the Templates to build pages. Good work has been done in upgrading CSS positioning support, creating pages, adding Assets, Snippets and Library items and also interfacing with various scripting languages.
If your department, college or campus organization has some upgrade money in the budget, I'd recommend getting Dreamweaver CS3. If you only just recently made the move to Dreamweaver 8, you can probably wait a while before upgrading, with the understanding that computer software is a lot like fresh fish: the older it gets, the less anybody wants it. Dreamweaver CS3 is going to be current a lot longer than Dreamweaver MX 2004 will remain usable, let's put it that way.
Subscribe to:
Posts (Atom)
