Birnam Designs Blog -- sharing tips, resources, ideas, and more on web development and design

In the last eight years, I have made lots of advances with my web development. I am always learning new methods, new tools, and new strategies on the path to intelligent web development. These are tips I’ve learned from my progress so far.

(Inspired by the Graphic Push article “The Path to Intelligent HTML“)

Flash

Single Files - NO

Working with Flash, it is very easy (and tempting!) to put everything into a single file. As long as your flash file is neatly organized, this shouldn’t be a problem, right? Not quite. It’s very easy to create gigantic files that not only take forever for the user download, but which take forever to compile, wasting precious development time. I first started dividing my flash movies into multiple files in an attempt to solve bandwidth problems for the end-user. But it wasn’t until Flash introduced the ability to import external JPGs and MP3s instead of just other SWF files that I really started loving this technique.

My favorite example is with galleries or slideshows. These can include dozens or even hundreds of images, yet since the point of these movies is to show off the images, lowering the resolution really just defeats the purpose. This is an easy recipe for an enormous flash file! So, to solve this problem, I create the initial interface in flash, but load the images from external files - each with their own loader bar if necessary. This splits up the download nicely for the user, and the sky’s the limit for the number of images you can use with this technique.

External Definitions - YES

Traditionally with Flash, it has been possible to load text files full of variable definitions. I used this to its fullest potential, but it was… well, clunky. Importing single values was fine, but importing a collection of values was done by defining “value_01″, “value_02″, “value_03″, etc. After the variables were loaded, you would run a function to move all of these individual variables into more accessible structures like Objects or Arrays (or arrays of objects!). There had to be a better way. And then Macromedia gave it to us: XML!

Now, if I want to include variables in external files, I can use an XML document. I particulary like to use XML defined values when I am creating galleries and slideshows. I mentioned above that I like to import the external JPGs at runtime. I also like to define what images are used and the order in which they’re used with XML files. This is one of the best ways to speed up project updates! Say, for instance, a client wants to rearrange the order of slides in a slideshow. If you made the movie the traditional way, you’ll have to open up Flash, move clusters of frames around, and recompile. But by using external JPGs defined in an XML document, all you have to do is open up the XML in a text editor and cut and paste the nodes that need rearranging. Easy!

Another favorite use of external XML is for link definitions. If a client needs to change the URLs of external links within the movie, all it takes is a quick XML update. I also use this technique for menus, image sequences, and content.

Reusable Scripts and Components - YES

After developing in flash for a while, you will have accumulated a library of functions, objects, and animations that you frequently reuse in other projects. Scripts can be included into a Flash document with the “#include” directive, which can help you avoid repetitive changes. For instance, say you have a button that triggers a function on the rollOver event, and this button is animated over many keyframes. Normally, if you wanted to change the rollOver event for that button over the entire animation, you would have to edit the button’s actions at every keyframe. But if you defined the button’s actions in an external script, and “#include” that script at every keyframe, you simply edit the external script once to change the button’s behavior for the entire animation!

Graphics, buttons, and movieclips can be reused as well by being saved to an external library. You can open the external library, and drag and drop these items into your current document. But it gets even better with components! In Flash, components are a nice method of packing your most powerful custom objects in a way that makes them even more accessible - just look for your custom elements in the Components panel! You can even ‘run’ them inside the Flash development environment, so you can see how they will look in the final compiled output! (this is called “Live Preview”) Components can be simple, or can involve complicated, programmatically-rendered designs. They’re the ultimate in resusability and, if done right, in scalability as well.

In the last eight years, I have made lots of advances with my web development. I am always learning new methods, new tools, and new strategies on the path to intelligent web development. These are tips I’ve learned from my progress so far.

(Inspired by the Graphic Push article “The Path to Intelligent HTML“)

Methods and Techniques

Templates - YES

Dreamweaver has them. GoLive has them. Visual Studio 2005 has “Master Pages,” which are basically the same thing. For static small and medium sized websites, I have found no reason not to use the template systems available in these applications. I had long eschewed using these proprietary template systems, prefering a non-proprietary system that runs on the server. Script includes or SSI can be used to make “header” and “footer” files that form the foundation of a template system, and are good options for large sites or sites with a lot of custom scripting.

But for smaller sites, especially if you want to make the most out of your editing tool, go ahead and use the template systems they offer. You might have to swallow some pride when you do so, but once you’ve made it through a good-sized project using such a system, I’ll bet you’ll like it. You’ll be creating pages faster than ever! The individual page editing is a painless, automated process. The template markup is in the form of HTML comments, so you won’t be sacrificing your HTML validation. It’s safe and easy. Just relax, take a deep breath, and give it a shot.

3rd Party Scripts - YES

Something else I was once loath to use were 3rd party scripts. I avoided them at all costs, from simple javascript functions to full-blown web-based applications. I was proud, stubborn, and oh so very picky about my code. I wanted to do everything myself. What an idiot I was! (This was before I learned the value of my own time.) I did benefit in the beginning, because I learned a lot more this way. But there were downsides, mostly rooted from the extra time committment. By spending so much time on the rudimentary code, I didn’t have time to make user-friendly and powerful systems.

Eventually I started using 3rd party scripts, some of which turned out to be very useful packages. A perfect example is Wordpress, a host-it-yourself blog package. With Wordpress, I can take advantage of all the tools I wouldn’t have had time to make myself - like a truly user-friendly administration system, a beautiful template architecture, a plugin architecture, RSS feeds, and more.

Wordpress has such a good plugin interface, in fact, that there is a whole community of developers out there creating free plugins that anybody can use. So now I can take advantage of even more features that I don’t have to spend my own time on. What a system! Converting normal templates to the Wordpress system is a piece of cake, and very easy to manage.

Content Management - YES

For almost any size site, content management is an enormous benefit. Even for sites that require a lot of custom scripting, it’s worth it. I consider it an up-front cost with long-term savings. It’s an easy decision for my clients: why not pay an extra $1500 today, if it will save you $5000 in update costs over the lifetime of the site? (just example costs, of course) But it’s not only an advantage for the client, it’s an advantage during development, too. Making templates for modern content management systems is easy enough once you get familiar with the system, and suddenly you have a robust, user-friendly administration system that you can hand over to your users.

Wordpress can be used as a content management tool, but for sites that need a bulkier content management tool, I use Joomla (it used to be known as Mambo). Joomla is as incredible for large-scale content management as Wordpress is for blogging.

In the last eight years, I have made lots of advances with my web development. I am always learning new methods, new tools, and new strategies on the path to intelligent web development. These are tips I’ve learned from my progress so far.

(Inspired by the Graphic Push article “The Path to Intelligent HTML“)

Tools

Text Editors - NO

I know. I’m being mentally slapped by hard-core programmers all over the world. So let me explain. I would be perfectly comfortable coding websites in a text editor. I don’t have a problem with that. In fact, even though I use Dreamweaver and GoLive to develop webpages, I almost exclusively rely on their code editors, and only occassionally use their WYSIWYG interfaces. I started off using text editors because I believed - and still believe - that a full understanding of the actual HTML/CSS/Javascript code is absolutely essential in good web development.

That said, I do recommend using an editor like Dreamweaver or GoLive, for all the built-in productivity benefits. Built-in FTP transfers. Remote versioning control. Templates. Snippets. Components. Error checking. Reference guides. Code completion. Built-in scripts. Drag and drop linking. The advantages are too numerous to list! (Incidentally, I have no preference between Dreamweaver and GoLive, although I have the feeling that Dreamweaver is going to be the one to survive the Adobe/Macromedia merger)

Professional Tools - YES

I’m not trying to say that text editors are not professional — I am a huge fan of EditPad Pro and high recommend it, and I find it very professional. Perhaps what I am trying to say is to use Specialized Tools. Even among HTML editors, Dreamweaver and GoLive just scratch the surface of a well-rounded toolset. Since I work in such a broad range of projects, I use a wide variety of tools. Photoshop is probably the most important tool in my shop. 99% of my projects start there. With Photoshop comes ImageReady - and while I feel that most of ImageReady is fluff, there are a few really good tools in it. Flash is a great tool all by itself, but I also use SWF Studio for building CDROMs. I also have to supply my Flash movies with audio and sometimes video, which require their own tools. (I use Adobe Audition and Sony Vegas.) I use Blender for 3d graphics. InDesign and Acrobat for PDF publishing. OpenOffice for document and spreadsheets. Illustrator for vector graphics. Visual Studio for application development and .NET programming. And these are just the big ones. I use dozens of tools for various smaller tasks. (Note: I hope to put up an article fairly soon that discusses my favorite tools.)

The point of a good tool isn’t just functionality, it’s higher efficiency. That’s what justifies the cost of the software. I bought Adobe Audition, for instance, after having a particularly difficult time finding proper tools for a particular set of audio editing requirements. I could do what I needed to do, but I was spending hours longer than I knew it would have taken with a good application. So I bought a copy of Audition, and it literally paid for itself in the first two weeks of using it.

I shouldn’t have been surprised. Web Development is just another skill, after all, and as far as I’m concerned all skills have exactly one thing in common: you start out bad, and you get better. So what was so surprising? Why, taking a look back at some of my earliest projects, of course.

They stunk.

But it wasn’t just my designs that were bad. My code was bad. My tools were bad. My fundamental strategies were bad. I can’t receive all the blame for this – after all, the web has been evolving, too. Popular stratagies, browser capabilities, and available tools have all gone through their own changes. But in the last eight years, I have made lots of advances on my own. I am always learning new methods, new tools, and new strategies on the path to intelligent web development. These are tips I’ve learned from my progress so far.

(Inspired by the Graphic Push article “The Path to Intelligent HTML“)

Coding and Design

Frames - NO

My first websites used frames everywhere. But I know enough now to realize that frames are Bad News in most cases. Frames complicate bookmark behavior. They require a fundamental fragmentation of a page, which reduces search engine optimization and can cause other problems. For instance, users coming to a site through a search engine link might only see a partial page. It’s not pretty, and frames are safely out of my life now.

There was some good to come out of frames, though - or at least the IFrame variant. Several years ago (early 2001) I was experimenting with IFrames as a method of transferring data between the page and the server and updating the existing content without having to reload the page. I knew that was pretty neat at the time, but now I realize I was, in fact, experimenting with an early version of AJAX. Fortunately, there are better tools for AJAX now, but using IFrames was a start.

Tables - NO

One of the worst aspects of my old code were the enormous nested tables. Four, five, six layers deep? Maybe more. Updating old code was like scraping off wallpaper and discovering that you had to peel off five or six more layers before you could paint the wall.

There will always be a place for tables in web design, but there are better ways to layout a page. CSS allows you to arrange your page into simple, logical blocks of content. It’s much simpler and cleaner than the old table-based layout, which improves code readability and makes a page easier to update. Not only is the code cleaner, but I believe that the entire philosophy behind CSS-based pages helps promote cleaner, more user-friendly pages on the user end. Better code and better pages? It’s a win-win. While we’re on the topic of CSS:

CSS - YES

For years my web projects were all very simple. Five or six pages, minimal fuss. Site-wide changes like updating font size or link color were merely a little annoying. But when you’re working on large websites, even simple changes can take a long time. With CSS you just edit one file and that’s it. That’s efficiency. Markup was also improved, by eliminating the need for tags like <font>.

CSS also opens up a lot of possibilities that weren’t available before. Web developers now have access to better typography, more sophisticated use of background images, easier printer-friendly and text-friendly designs, better search engine optimization results, better accessibility support, and lots, lots more. Moving to CSS was one of the biggest steps in my evolution as a web developer.

Javascript, AJAX, and DOM - YES

My old experiments using IFrames to communicate behind-the-scenes turned out to be a sign of times to come, but I had no idea how far it would go! Now, tools like XmlHttpRequest are available on the most popular browsers, and I am more comfortable with DOM scripting - both of which get used in AJAX, the hottest thing on the web right now. I’ve incorporated it into a few projects so far, and I love it!

The most interesting thing I’ve found about AJAX is that instead of adding a layer of difficulty to the programming, it actually makes a lot of my tasks on the backend even easier! More user-friendly and easier to develop? There’s a reason why it’s the hottest thing on the web!

One of the goals for any website is to be well-indexed by search engines. It’s called SEO, for Search Engine Optimization, and it’s both an art and a science. But it’s also possible to go the other way. Sometimes there are files that you would rather search engines didn’t see. There are methods of hiding these files from the search engines that play by the rules, such as using the robots.txt file, but the first rule is that if you don’t want something publically accessible, don’t host it online.

An article called Things You Don’t Want Google to Find, over at Silicon Valley Sleuth, outlines several points made at a conference on security. The speaker was George Kurtz, the Senior Vice President of the well-known computer security firm, McAfee. In his presentation, Kurtz shows several confidential files and pages that were found after simply searching for them on Google.

These startling finds included payroll documents, social security numbers, confidential files, passwords, even the configuration panels for personal routers.

So, the moral of the story is: if it’s online, it’s public. Please keep that in mind.

One of my favorite features of Firefox v1.5 is that when you are prompted to upgrade, you are given the option to see what extensions will break due to the upgrade! What a fantastic feature — yet one that has caused me to delay my 1.5.0.1 upgrade. (security fixes) One extension in particular — the Googlebar extension, an even better Google toolbar than Google’s own extension — would not work after the update. Unfortunately, that is probably the most actively used extension I have! Fortunately, there is a solution. (also, Googlebar has since released an updated version that fixed the problem in the first place, but that still leaves me with a few extensions that won’t work after the upgrade)

Evilsoft.org has a good rundown of how to edit a Firefox configuration file in order to restore extensions caused by minor updates.

Notes:
1) don’t try this with major updates, like a 1.5 -> 2.0 updates, and

2) pay attention to the author’s note about using a text editor, not a word processor, to edit the configuration file. I recommend either Edit Pad Pro (not free) or Notepad (free) for pure text editing.

I’m one of those people that are (still) unwaveringly faithful to Google. I love that company. I (half) joke with my client that the only two reasons I would ever just pick up and leave my business are if 1) Google offers me a job, or 2) Pixar offers me a job.

Now, rumor has it that Google is readying a rollout of an online payment service, not too dissimilar from PayPal. They call it GBuy.

WHAT!?

Please, please tell me that they’re not going to really call it GBuy. Surely somebody has pointed out that GBuy could be pronounced as an abbreviated form of “Goodbye”, as in “Kiss your money g’bye!” Seems obvious to me….

Please, please, please. Especially if you are just starting a business. Have lots of people look at your name. Sometimes they’ll notice something obvious that, due to familiarity, you have missed.

No, I’m not talking about Quirksmode.org, the fantastic resource on browser compatibility. (Although if you don’t know about that site already, do yourself a favor and go ahead and bookmark it. Go on.) I’m talking directly about the quirks mode in browsers. More specifically — and you can skip to the end if this is all you’re interested in — I’m talking about how to determine if a browser is running in standards mode or quirks mode.

Both Internet Explorer and Firefox (and assumedly other modern browsers) have two different rendering modes, standards and quirks.

But first, what is rendering? It is the process of interpreting the markup of a web page and determining how to draw the page. As difficult as that sounds, believe me, it’s probably even more difficult than you realize. It’s not just HTML. It’s also javascript, XHTML, CSS, DHTML, DOM, VML, embedded plugins, SVG, Canvas, XML, XSLT, MathML, SGML, etc. And even within these types of markup there are different version numbers. HTML 1, HTML 2, HTML 3, HTML 4, XHTML 1.0, XHTML 1.1, CSS 1, CSS 2, CSS 3, etc. And then, within those levels of markup, are even more levels. Transitional XHTML 1.0, Strict XHTML 1.0, etc.

Obviously, trying to interpret all of these is no easy task, even if you could rely on every developer in the world to be a markup expert. Of course they’re not, so you also have to account for errors. How do you handle markup mistakes as gracefully as possible so that the resulting webpage isn’t rendered in an incoherent mess of text and images?

Enter Standards Mode (aka Standards Compliance Mode) and Quirks Mode. Just from their names, you can probably guess which one is used to render pages with flaws and which one is used to render pages that observe all markup rules. For me, Standards Mode is a goal. If I have created a webpage that is rendered with standards mode on both browsers, then I’m in good shape. (when I say ‘both browsers’ I am of course referring to Internet Explorer and Firefox) If my page falls into quirks mode, I need to figure out what’s wrong. It’s more than just observing good markup rules — it is also more reliable to have a page that is rendered in Standards Mode. When I say reliable, I mean that it is easier to get Internet Explorer and Firefox (and other standards-observing browsers) to render your page in the same way. This saves enormous headaches, because otherwise you have to sometimes create multiple style definitions, or even multiple pages, in order to get things to look right for all browsers.

Now that we know which is better, here’s the question: how do you tell if the browser is rending in standards mode or quirks mode?

In Firefox, it’s simple. Right click on the page, select View Page Info, and look for the “Render Mode:” detail. Tada! If you’re a serious web developer, though, you should also ensure that you have the Web Developer extension for Firefox. If you have this extension, then there is always a nice friendly icon in the corner of your screen that will show you the render mode. For instance, at this moment, I can look up and see that there is a blue circle with a checkmark in it, so I know that this Wordpress admin page is running in standards mode. When I roll over the icon, a tip pops up and confirms this. Or I can click on the icon to jump to the View Page Info dialog which will tell me the same information. If this blue circle is greyed out, then I know I’m viewing a page that is relying on quirks mode.

In Internet Explorer, it’s not so straight-forward. To the best of my knowledge, there is no built-in functionality that will show what render mode the browser is using. It’s not in the page info. Instead, I defer you to the Render Mode Bookmarklet. It’s easy to use: follow the link I gave you and you will find a page that contains a link at the very bottom. Clicking this link runs javascript code that will determine the render mode of the page and give it to you via alert box.

All you have to do is save this link as a bookmark, and you have a bookmarklet that will do the same thing to whatever page you happen to be visiting! Enjoy, and good luck always finding your pages in standards mode!