Fragmented Development

"My, loading that web site was entirely too fast for my tastes. I wish the authors of this page would slow it down a bit!"

Never in the history of computing will you ever hear the statement above spoken out loud - well, at least not seriously. When it comes to load time, there's no such thing as too fast, and your visitors will thank you if you embrace that concept.

So... what is a conscientious web developer to do?

Next to good design practices, HTTP compression is one of the best tools we have to save our visitor's time. This technology works at the server level, so if you use a web host, you'll have to talk to them.

The way it works, without getting too technical, is a lot like creating a ZIP archive. Each bit of information (with a few exceptions), gets sent through a compression mechanism if the other side supports it. You use up much less bandwidth than you normally would, and all it costs you is a little processor time. Since your processor time is almost always cheaper and more abundant than bandwidth, this is a win-win situation - and all of your pages load much faster as a result.

Now, the drawbacks. HTTP compression works fantastically on text, like static HTML documents and dynamically generated pages (like ASP.net and PHP). With everything else, it's hit or miss. For instance, I'm under the impression that Javascript and CSS files should not be compressed. The browser needs to get these files as fast as possible to render your page correctly, and adding another step (decompression) in-between receiving the file and rendering your page could cause some display problems. A flash of unstyled content could result, and that might not be acceptable.

In addition, you shouldn't compress files that are already compressed. Compressing information more than once can lead to data loss... I think. I'm speaking from information gathered ten years ago, but I believe the basic concepts haven't changed much. Also, compressing content that's already been compressed, like re-ZIPing a ZIP file, takes a long time to process and doesn't gain you that much.

Now, certain file formats (Flash, PDF, OpenDocument, images, etc.) already come compressed, so you shouldn't use HTTP compression on those. Everything else is fair game, as long as you look into the file formats.

Give HTTP compression some thought, it'll help you save on bandwidth expenses and help you save your visitors some time as well.

While re-designing a page that relied heavily on internal linking, I ran into a problem using a numeral at the beginning of the name attribute. Whenever I used a name that started with a digit, the validator returned an error. This had never happened before, so I checked the reasoning behind the error*.

Apparently the name attribute has been deprecated, and the id attribute is now used instead.

I think this is great for quite a few reasons, one being that 'id' is shorter than 'name', saving me two characters on each internal link. I know, it's not much, but eventually that will add up!

I also like this new change because it makes so much sense. All the name attribute ever really did was give an ID to an anchor, so we're really cutting the pretense and getting straight to the point.

I've yet to research how much browser support this has so far, so for now I'm using both for backwards compatibility. The name attribute is still valid, it's just deprecated, so <a name="foo" id="foo"></a> is a perfectly valid internal reference. Just watch your naming conventions!

* I use the HTML Validator extension with Firefox, which allows you to view all validation errors in real-time, as well as being able to pick out errors in your source code, and explain why they're errors.

I heard that Kubuntu, my favorite flavor of Ubuntu, had a new version out. Since I run a dual-boot system with Windows XP and Kubuntu, I did my duty and downloaded the latest version, which just happens to be 7.10 (Gutsy). While I was starting the install process, I noticed a small blue signal strength graph in my taskbar.

I bought a separate USB wireless adapter for Linux a while back, because my Linksys PCI card did not seem to behave well with Linux. But the USB devices were still sitting on my shelf, disconnected, because I hadn't finished setting up the machine yet (and they only worked for about fifteen minutes on average, so I wanted to save them for updates and package installation). But there it was, telling me that I had a wireless signal strength of about 90%.

I double-checked to make sure I hadn't somehow left one hooked up, and finding nothing, dropped to my knees with arms raised to the sky. Finally, decent wireless support in Linux.

I'm beginning my first Linux-only day in a long time, and it's a good feeling. Nigh, a wonderful feeling. This leaves one major barrier to my ditching Windows entirely: games. But with some experiments I've been doing with Wine, that may be a thing of the past as well. For anyone who's been waiting for the right time to switch over to Linux... well, this is it. Our day has come.

There's nothing more shameful, nothing more embarrassing than finding that one of the links on your page is dead. If you're going for the quaint amateur-ish designer look, then let the links on your site lead to 404 errors. I can't think of any better way to lower a visitor's opinion of your competence...

...Well, maybe there is one thing that's more of a "faux-pas" — causing 404 messages for people linking to your site. If you ever expect to have a successful web site, one of the keys is not abusing people who link to you.

Inbound links are invaluable to any web page, by providing direct traffic and increasing your chances of being listed in the top search listings. So it's your duty as a web citizen to keep your site structure fairly stable, and prevent breaking any direct links to your pages. If someone has been kind enough to link to you, don't pull that page out from under them.

In a perfect world, that would be that — end of discussion. Instead, there's almost always going to be a situation where you need to move or rename a page on your web site. Luckily, there are several ways to do this without breaking links.

HTML Headers

HTML headers are sent between the browser and the server, and are a great way to redirect people to the new location of the page. When someone requests the old file, simply send them these two headers instead:

HTTP/1.1 301 Moved Permanently
Location: newfile.html

Easy as that. Now anyone who visits the old URL will be taken to the new updated one, and anyone who cares (search engine spiders, webmasters checking their links) will know that the link in question is an old link and should be updated.

These headers can be sent from the web server software (IIS or Apache), or can be sent through scripting languages (PHP's header function).

Javascript/Meta Refresh

If you don't have access at the server level, and don't have the ability to use a scripting language, you can always use the HTML meta tag option or a short Javascript function. Just make sure to display a message to the user beforehand, to prevent confusion. This will at least get people and spiders to the appropriate file.

I would post an example here, but you can probably find a better example if you search for the term "meta/javascript refresh/redirect".

People who link to you are doing you a favor; return the favor by making sure those links always lead somewhere!

I'm a hardcore web guy. I dive straight into the mucky muck of tags and CSS and server stuff and I love it that way. I code each piece of HTML or CSS in a page by hand. I use two tools when doing web work: The GIMP for all my image needs, and PSPad for absolutely everything else, and with these tools I manage two highly complicated web sites. At last check, they have over 700 documents (pages, downloadable documents like PDFs) between them.

Managing this much content incorrectly is a good way to become an alcoholic. Unfortunately, I've never been a big drinker, so I have to create techniques that allow me to manage this much stuff without losing my mind. That, in essence, is what this whole entry is about.

Templating

Do you have a navigation bar that is common across several pages? Redundant elements that can be reused? Need to make site-wide changes without a ton of work? Then templating is for you. Templating is the single easiest way to make web sites more manageable, by grouping together reusable pieces of the page (like navigation) and using server side scripting languages to include them when needed. This not only makes it easier and faster to build pages, but it makes it much easier to maintain these elements across the site. The more code you reuse, the less you have to rewrite.

Separation of Presentation, Content, and Behavior

In the early days of the web, there was one file: index.htm, which held the entire web site content. When methods of embedding images came along, there was the index and the image files. As web sites started to grow, more and more technologies came along to allow the separation of different elements in a page. Currently, we have the following to use:

• HTML for structure
• CSS for presentation
• Javascript for behavior

Keeping these elements of a page separated makes pages much more manageable. If all aspects of a page are mashed into one file, like old table-based layouts, editing a single piece of a page becomes a game of hide-and-seek. Separation of structure, presentation, and behavior make code more readable and organized and make navigating that code much faster. Organized code also lends itself much better to templating, which is a web guy's best friend.

This is an ongoing process, so I will post more as I go. Keep an eye out for updates!

What I know about JSON can be summed up easily, placed on a post-it note, and stuck to your monitor as a (somewhat) helpful reminder. What I know about JSON is this:

JSON is the velvet rope of JavaScript.

One of the reasons I can sum things up so concisely is because I have no idea how to use JSON. I've read a few articles, looked at a few tutorials, and gotten myself nowhere. When I learn more, I will post it in this blog and link to it from this post.

This space reserved for link to my infinite future knowledge

Until then, may I humbly suggest Web Standards With Imagination, a blog maintained by Dustin Diaz. He's the guy that introduced me to this stuff, and where JavaScript is concerned, he is the Dalai Lama to my plain-old Llama.

I've been exploring the way Internet Explorer 7 handles things, and I'm overwhelmingly disappointed. IE7 suffers from the same "Microsoftitis" as most Microsoft products - which means that it behaves the way Microsoft believes it should, and not the way the rest of the world does.

The fact that Microsof has a monopoly (not a near monopoly, not a partial monopoly, a full-blown illegal monopoly) means that they set the de facto standard with whatever they do. This is infuriating as a web developer, when the rest of the world has already dictated how things must be done.

With IE7, the standards set forth by the W3C just doesn't seem to cut it. Granted, they're getting slightly better, but with the amount of time they had been working at it, they should have fixed many more of the problems they have. IE 3, 4, and 5 were released within a year of each other. Each version was leaps and bounds above the other. IE 6 was released three years after IE 5, and was a huge improvement over IE 5.

IE 6 was released in 2001, and IE 7 was released in November of 2006. Nearly five years in-between. I count three major improvements so far: Shiny new interface with tabs, some CSS bugs fixed, and the Zoom feature.

The IE rendering is nearly the same as IE6, with the same quirks that make it challenging to design a standardized page that looks good in IE. In fact, the lack of some CSS bugs remove the ability to use CSS hacks, so in that case designers and developers are basically back to square one.

The introduction of tabs in IE7... well... welcome to the party, guys.

As for the zoom feature... I was genuinely impressed by IE7's zoom. It's generally a great idea, especially for those who have low vision. Mind you, Opera's had this forever, but that's not the point. At least Microsoft's trying.

Then I zoomed in on one of my layouts, and found a terrible terrible bug that actually split words in two and sent them to opposite sides of the screen. While somewhat disappointing, I still haven't given up on it. It needs some work, but it's not a bad step.

So, if the trend of IE releases hold, and Microsoft gives up it's "my way or the highway" policy, we may just have a decent standardized browser to develop for when 2014 rolls around.

In an earlier post, I described why I thought it was brilliant of Apple to release the Safari browser for PC. Now that I have a little more time to elaborate, I will do so.

Number One: Compatibility

By far and away, the best reason for Apple to bring their browser to Windows is compatibility. As a Windows user, I download each and every browser out there that will run on my PC. I have IE going all the way back to version 3, Netscape from Navigator 2 Gold and forward, a bunch of old Opera and Firefox versions, and even some from the text-based realm like Lynx. I don't use them all the time, but I've loaded each of my layouts in them at least once.

I also keep a Linux boot CD handy - Knoppix for KDE, Ubuntu for Gnome (I also use Kubuntu from home, but don't have that CD at work. Go figure) - and I test those environments as well. Linux users don't make up a large share of my visitors, but so what. They'll never make up a large share if my sites don't work on their browsers.

Macs presented a special problem. While their browser, Safari, was based on KHTML, it did things a little differently. Also, Macs are not cheap, so buying one just for testing purposes was completely out of the question. My solution was to load up as many of my sites in Safari whenever I had access to a Mac, and hope that they rendered well.

But with Safari on Windows, my problem is solved. I can make sure all of my pages render for my Mac friends, and I don't have to invest a dime. This gives anyone using a Mac a better chance of viewing a well-polished page, which will make for a better experience for Mac users. What company wouldn't want more satisfied customers?

Number Two: Familiarity

I am a PC user, and I hate Windows. It's clunky, ugly, bloated, buggy, insecure, and expensive. I would love to get away from Windows... but I can't.

I've spent nearly fifteen years learning how everything works on Windows, and I couldn't possibly just jump into a new environment. I've looked into converting to Linux, but it hasn't come together for me just yet. I've given some thought to Macs, but never very seriously, because Macs are completely foreign to most PC users. I wouldn't really know where to start, because I'm not familiar with any of the programs or interfaces.

This is where the real genius is. ITunes, Safari, and QuickTime are all common occurances on most PCs nowadays. All of them sport the brushed Mac interface, all of them share their counterpart's functionality, all of them have versions that are free to download and use. Everyone using this software has a little Mac exposure. Each installation is like an Apple ambassador, bringing the everyday PC user a taste of the good life - and making it a little bit easier to warm up to a Mac. If you've used all of the programs, then half the battle has already been fought.

Number Three: See One and Two

That's really all their is to it. Apple has made a very strategic move by releasing Safari on Windows, one that I do not believe they will regret.

Note: This is an update to an earlier post. To get the whole story, read Safari's Blinkey Background Bug.

Due to my influence on the developers behind Safari (*snort*), the browser bug dealing with background colors of positioned elements and Flash objects using a wmode value of 'opaque' has been corrected in the new Safari beta. This is great news for developers, because there was no workaround or hack available.

I'll post more about the brilliance of making Safari available for Windows a little bit later.

Note: This post is out of date. To see the stunning conclusion, read the update!

With the new Tourism web site, I've been introduced to a whole new world of browser bugs - the bugs associated with using Flash.

Since this is my first foray into Flash, I tried to use as little of the stuff as possible. The design called for the use of a flash-animated header with a integrated navigation menu. My usability alarm immediately went off: "you can't put a piece of the navigation structure inside of Flash! What about people who have flash disabled? What about people using screen readers or text-only browsers! For God sake's man, think of the spiders!"

So, I crafted a particularly tricky piece of CSS and HTML, and positioned a DIV containing an unordered list over the flash. At first, it disappeared entirely - but I was not daunted.

Some of my video experience reminded me that video is a tricky beast, and isn't always displayed like other items on your screen. So, I did some digging and discovered that the problem was indeed the display mode of the flash. A quick addition of the 'wmode' attribute (set to 'opaque') and we were off and running. It was accessible, it was pretty, it looked like the perfect solution! I ran up to the designer, and we loaded it up in Safari.

She was impressed by the appearance, and seemed genuinely happy with how it had worked out. Then she hovered over one of the links, and the box disappeared.

I was unprepared for that, to say the least, so I did a little digging on Google. It turns out that there is a bug in Safari that causes problems with hovering elements positioned over Flash, and there's no work around currently.

I quickly assured our designer that it was only a Safari bug (the majority of our visitors are using IE variants), and that I would do all I could to resolve it. With a little more digging, I discovered that applying a background image worked marginally better than using a background color in our situation, so I applied a 1X1px image of the color white. The link text still had a white background, but the container DIV still always lost it's background color.

I believe I've come as far as I can with this particular bug, and the rest is going to have to be done by the folks behind Safari.

Note: This post is out of date. To see the stunning conclusion, read the update!

With the new Tourism web site, I've been introduced to a whole new world of browser bugs - the bugs associated with using Flash.

Since this is my first foray into Flash, I tried to use as little of the stuff as possible. The design called for the use of a flash-animated header with a integrated navigation menu. My usability alarm immediately went off: "you can't put a piece of the navigation structure inside of Flash! What about people who have flash disabled? What about people using screen readers or text-only browsers! For God sake's man, think of the spiders!"

So, I crafted a particularly tricky piece of CSS and HTML, and positioned a DIV containing an unordered list over the flash. At first, it disappeared entirely - but I was not daunted.

Some of my video experience reminded me that video is a tricky beast, and isn't always displayed like other items on your screen. So, I did some digging and discovered that the problem was indeed the display mode of the flash. A quick addition of the 'wmode' attribute (set to 'opaque') and we were off and running. It was accessible, it was pretty, it looked like the perfect solution! I ran up to the designer, and we loaded it up in Safari.

She was impressed by the appearance, and seemed genuinely happy with how it had worked out. Then she hovered over one of the links, and the box disappeared.

I was unprepared for that, to say the least, so I did a little digging on Google. It turns out that there is a bug in Safari that causes problems with hovering elements positioned over Flash, and there's no work around currently.

I quickly assured our designer that it was only a Safari bug (the majority of our visitors are using IE variants), and that I would do all I could to resolve it. With a little more digging, I discovered that applying a background image worked marginally better than using a background color in our situation, so I applied a 1X1px image of the color white. The link text still had a white background, but the container DIV still always lost it's background color.

I believe I've come as far as I can with this particular bug, and the rest is going to have to be done by the folks behind Safari.

I am a web developer. I develop web sites, the code behind them, and most technical aspects associated with interactions on the web. I am concerned primarily about function, speed, efficiency and usability.

I am not a web designer, even though I try. Web designers design web sites, and focus on the aesthetics and layout of a page. Their primary focuses involve presentation, appearance, and beauty*.

When web designers and developers need to work together, sometimes differences in opinion crop up. Sometimes quarrels break out. Sometimes people agree to disagree, and sometimes people die.

...Okay, so nobody dies. However, somehow the designer and developer need to come to a consensus. There is usually a middle-ground to be had, but the trouble is getting there. Misunderstandings on both sides can get in the way; maybe the designer isn't used to designing for the web, so they expect the precision of other fields of design. Maybe the developer has never had to delve too deep into the CSS properties that have to do with typography, and are poorly equipped to use them.

Whatever your position, designer or developer, take it upon yourself to find that middle ground. If you're working with someone from the opposite camp who refuses to budge, find a compromise that works for both parties. It's much easier to work with someone who's willing to cooperate, and if you prove that you take their opinions and concerns seriously, they're more apt to respect yours and take them into account. Someday we may not have to choose between graphical elements and handicapped usability, but until then, try to be the good guy. Stick to your guns, but don't shoot yourself in the foot.

* Like I said, I'm no designer. I am just speculating here.

This week, one of my co-workers began working on a ticket that I had started. The situation involved an ASP.NET script, a stored procedure, and CSV and Database data sources. It was a fairly complicated issue that involved a 3rd party - they supplied the CSV file. It turns out that they had changed the formatting of the CSV file, which botched up our import script quite thoroughly.

I supplied my co-worker with the script, and started showing him what I had come up with so far, when we ran into some of my debugging code. Since I was working alone on this project, I had some fun with variable names (dim stupid, broken;). Luckily that section had been commented out, so he didn't seem to mind that too much.

However, we continued on in the code and ran into a piece of debuggery that was still in place: the 'coolguy()' function. I assume that I named it "coolguy" because I assumed I was, indeed, a cool guy. However, when my co-worker asked "Okay, so what's coolguy() do?" I had to re-assess my naming conventions.

Not only had I left out any semblance of comments, I hadn't given my functions or variables meaningful names. I was one of those coders. I was not a cool guy.

I sheepishly informed him what I thought the function did, but also had to admit that I wasn't sure. Coolguy wasn't ringing any bells, because I gave things silly names all the time. My intro to programming instructor popped briefly into my mind - she was shaking her head. If I had decided to be a samurai instead of a web designer, I would be ritualistically ending my sad existence right now.

Moral of the story: even if you're just goofing around, trying to fix something, make sure to take it seriously - code like you're working in a team, and you're submitting your program to five other people, all of which are higher up in the food chain than you are. Who knows when someone else might shed some light on the programs you've been writing... but you can make sure they don't get any of your abundant personality quirks with it. *sigh*

I'm at work, but I'm not at work. I'm sitting in the Public Safety building, in a meeting room, with other essential staff. Certain public offices, like Public Health and the County Clerk, have a skeleton crew occupying a couple of seats. Computers and phones are set up where they're neccessary, and people come and go like it's business as usual.

Yesterday, the main electrical point of entry caught fire and started arking all over the basement. The backup generator kicked in, which caused more fireworks. The building lost power, and acrid smoke filled the halls. Our network coordinator scrambled to power down the servers and devices before he was forced to leave by the firefighters on scene.

Shortly after this all happened, I received a phone call from a coworker telling me that I shouldn't bother coming in today. Luckily, this all occurred around 9:00 AM, and I'm scheduled to start work at 10:00 AM.

After some time spent home catching up on some personal web stuff, I received another call: it's our network coordinator. We had a backup generator on scene, and were ready to turn things back on...

Shortly after I got to the office, we had almost all primary systems up and running. The only device that did not bounce back was our RAID array. If you work in Warren County, your "My Documents" folder points to that device. That's no bueno. Our network coordinator hopped on the support line with Gateway (they sold us the device), and we overnighted a new one to the municipal center.

Back to today - we have the new device, and from what I hear they're putting it in right now and rebuilding the array. We may have to restore from backup, but at the very worst that means we lose two hours of work. Our main systems were down for around five hours - not too bad if you consider the circumstances.

This week has emphasized the importance of having a good backup plan, as well as a plan for emergency response. In the event of an emergency, having a set procedure saves a tremendous ammount of time and money, and allows you to bring everything back to operation.

Now, if only the plan didn't involve me coming in two hours early...

My new year's resolution is to switch to Linux - specifically one of the Ubuntu variants. I'm sick of using Windows and supporting Microsoft in it's efforts to remove the rights of it's users. Linux can (technically) do absolutely anything I need it to do, the trick is getting from here to there.

After much deliberation, I've decided to use Kubuntu flavor. I really like the others (especially Xubuntu), but Kubuntu just seems like the best fit. So, I install the distro on my second hard drive, and most everything works automatically. Being somewhat of a perfectionist, I automatically start yearning for my dual-screen setup and wireless network. This is where the pain begins.

First of all, I must add that none of these problems are limited to Kubuntu. Dual-screens has to do with the underlying X.Org system, and lack of comprehensive wireless support crosses all distributions.

With that said, I completely destroyed X.Org by trying to add a second screen. No warning, no second chance, just a callous-looking command prompt with some errors. After the third install, I figured out that I was really just mucking up the xorg.conf file - I saved a copy of that to my home directory, and in case of nuclear holocaust, I simply restored the configuration file. Not that hard to overcome, but I'll be damned if it didn't take a ton of time and effort. I can also tell you how many normal users would be willing to go to those extremes to keep their system up and running with Linux...

I still have not been able to configure my wireless card. If I was a little more flexible in my requirements, things would not be so difficult - but I have a degree in networking. I am not willing to settle for anything short of WPA security, with my own configuration (AES encryption, pre-shared key, channel 8). The fact that Ubuntu (and I'm guessing it's the same with Xubuntu) does not have a built-in way to do this is unacceptable. By installing a separate application in Kubuntu I can get some of the options I need, but this has not let me get my wireless network up and running. I've tried several fixes on the internet, none of which have worked, most of which have had me configuring a file that is no longer used in Ubuntu. I've been able to run CAT5 cable to my PC for the time being, but it will not last.

While I do appreciate the configurability of Linux, most users will not. The majority of users simply want something that works - which is why Windows is so popular. If you don't work in Windows, you can't compete in computing today. This is also why Macs are gaining popularity: they control the environment their operating system runs in, so everything works. With the growing importance of the Internet (which is cross-platform), Macs are becoming a viable alternative.

The only way Linux is ever going to survive on the Desktop is if it becomes one of the operating systems that "just works" out of the box. The efforts of Ubuntu and other distributions just may make this possible, but it's still a long way off.