Update: There have been a number of comments that have already demonstrated a number of holes in what I’ve written below. Please be sure to read the comments as well. There are some excellent and valid points that rightfully challenge the ideas I’ve put forth here.

I think it’s safe to say that most people who keep up with what’s going on in the web development community are pretty excited about HTML5. Granted, there are some who would argue that HTML5 hasn’t really arrived yet, because we don’t have complete support in all browsers. While everything that I have heard and read suggests that IE9 will be the first iteration of Microsoft’s product to support HTML5, the other, current implementations do not. Fortunately, there are some tricks and techniques that we can use to bring a certain level of support, allowing us to follow numerous urgings and start using HTML5 today.

And that’s exactly what I have been doing!

Technically speaking, this version of the Echo Enduring Blog actually uses HTML5. Check out the DOCTYPE tag in the source code—pure HTML simplicity. However, I’m going to be honest here. The switch over to HTML5 actually came somewhat late in the development process, and if you actually examine the rest of the code, what you will find is that it really doesn’t make much use the numerous, new HTML5 tags and elements.

Fortunately, however, with a client project that I am currently working on, I had the opportunity to try a few new things and I decided to make it my first, full blown HTML5 development project. As I usually do, I coded up the design in flat HTML and CSS first, making use of the new <header>, <footer>, <aside>, <article> and <nav> tags as I went. Everything was going swimmingly, and I started to carve the HTML and CSS into a proper template for WordPress (that being my CMS of choice in this instance).

And Bang! I hit a snag. Specifically, I hit a snag having to do with the navigation. But before we get to that, let’s take a minute to talk about history and semantics.

There’s Semantics and Then There’s Semantics

As strange as it may seem, and in spite of everything we have come to expect (and even demand) from websites in the past fifteen years, until the arrival of HTML5 there has never really been a tag or series of tags that were actually dedicated to structural navigation. The <a> tag comes close, but it defines an individual elements, whereas navigation itself is more of a system.

So, using the logic of semantics, developers eventually came to the conclusion that a menu or other navigational tool closely resembles a collection or list of links. Given this, the most logical and semantic choice of the time was to use an unordered list, with each link placed within its own list item. So, if I wanted to code a menu, I would do something like this:

<ul> <li><a href="index.html">Home</a><li> <li><a href="about.html">About</a><li> <li><a href="services.html">Services</a><li> <li><a href="products.html">Products</a><li> <li><a href="contact.html">Contact</a><li> </ul>

Over time, this (or some variation) pretty much became the accepted standard for creating navigation (specifically menus), and while I always thought that it was somewhat less than ideal as a solution, it was the best we had and it’s what I’ve been using for years now.

Then HTML5 hit the scene. I’m not sure how many people realize it, but this completely throws the traditional way of doing things on its head! This newest specification features a new tag called <nav>, and as you might suspect, it is used to define a navigational area. Okay, so what’s the problem? Can’t we just do something like this?

<nav> <ul> <li><a href="index.html">Home</a><li> <li><a href="about.html">About</a><li> <li><a href="services.html">Services</a><li> <li><a href="products.html">Products</a><li> <li><a href="contact.html">Contact</a><li> </ul> </nav>

Absolutely. That’s entirely valid markup. But it’s not necessarily good markup. First, it’s redundant. Both the <nav> and <ul> tags are basically fulfilling the same role, acting as a wrapper. So, unless you have a very specific reason why you would need two wrapping elements, using both is simply redundant and ultimately unnecessary.

One option that some people might consider would be to take out the <ul> tags, but that strikes me as somewhat non-semantic—using list elements without a list. And semantics is the other issue that we need to consider. Semantic coding is about chosing the right tool for the job, but sometimes the term “right” should probably be replaced with the word “best”. There may be a number of equally valid options, and its up to us to chose the one that is the most appropriate.

As we have seen, previous to HTML5, using a list for navigation was the most appropriate and semantic decision. But, since HTML5 introduces a dedicated navigational tag, things change. Now, using a list for navigation is no longer the most semantic decision, because we have another option that is more appropriately suited to the task. And so, a menu coded like this would, in my opinion, but much better in HTML5.

<nav> <a href="index.html">Home</a> <a href="about.html">About</a> <a href="services.html">Services</a> <a href="products.html">Products</a> <a href="contact.html">Contact</a> </nav>

As an added point of interest, if you check the W3C entry on the <nav> tag, this is pretty much exactly what they provide as their example of how to use the tag.

HTML5 Living in an XHTML World

Now, to bring this discussion back to my WordPress problem—the issue that I ran into stemmed from the fact that WordPress, as it currently stands, still uses the old list navigation method. Using the relatively new (but still totally awesome) custom menus tool that is now built right into WordPress, I created slightly different header and footer menus and deployed them in the custom theme that I was developing.

There, right in the middle of my semantic, well-coded HTML5, was a now-less-than-semantic, list-based navigation, aptly surrounded by a redundant <nav> tag! It was everything I didn’t want for my navigation, and it reminds us of a very simple but important truth: as much as HTML5 is a great new technology, and as much as we should push for its use here and now, the simple fact of the matter is that we are still living in an XHTML (or even HTML 4.01) world!

It’s kind of being left-handed (which I am). You’re part of the minority, and for the most part, you can get by in life without a hitch. Every once in a while though, you run up against something that is just so obviously built for right-handed people that it is all but impossible to use. It’s just a part of being left-handed in a world that is built for right-handed people.

I think that HTML5 is in a very similar situation, at least for the moment. For the most part, you can code freely and not run into a problem. With this navigation issue, however, I came to the point where I had an awesome system in WordPress, which was built on a particular assumption that was true for XHTML (and all its ancestors), but which I longer believe to be valid for HTML5, and while I tried looking for different options and preferences,  I couldn’t find any built-in way of moving from list-based navigation to purer <nav> based menus.

A Functional Solution

Fortunately, I did come up with theme-based solution, which involved writing a custom PHP function to manipulate the generated HTML. Basically, instead of just printing out the menu’s HTML, I wrote it to a variable, then passed that through a bit of processing before echoing (writing) my own, much simpler code. Here’s the function:

function custom_wp_nav_menu($menu,$menu_id){ $custom_menu_html = wp_nav_menu( array( 'container' => false, 'echo' => false, 'theme_location' => $menu )); $custom_menu_html = strip_tags($custom_menu_html, '<a>'); if($menu_id == ""){ echo "<nav>\n"; }else{ echo "<nav id=\"$menu_id\"gt;\n"; }echo $custom_menu_html; echo "</nav>"; }

The logic here is really, really simple. First, we start by calling the wp_nav_menu WordPress tag, passing it a few key options. Setting the container property to false eliminates any default HTML elements used to wrap the menu, while setting the echo property allows us to return the HTML rather than immediately echoing it. Lastly, the theme_location property tells us which predefined menu we want to use, information which we pass into the custom function.

Then we use the PHP strip_tags function to strip out everything but the <a> tags, leaving us with a grouping of menu links saved to a variable. Then it’s just a matter of echoing the required tags to complete the transformation.

You’ll also notice that we have a second option in the function, which basically allows us to declare an id attribute for the surrounding <nav> element. This is useful for sites that declare multiple navigation areas, such as header and footer menus, which may be slightly different in terms of content and styling. You could also use this technique to pass in custom classes, or whatever else you may need.

Conclusion

Ultimately, it’s not the most ideal solution and it definitely feels a bit like a hack. However, until we make a fuller transition from XHTML list menus to purer HTML5 menus, it remains a relatively quick and easy workaround for those who continue to pioneer with emerging web technologies, as well as those who are just being introduced to them.

That being said, then, I hope this article has helped to introduce some readers to reality of certain semantic shifts that arise as a direct result of the new HTML specification, has helped illustrate the changes that are coming to the way we markup navigation, and (perhaps most importantly) provided a technique for deploying HTML5 in an XHTML world.

What do you think? Are you using HTML5 in your sites now? How are you coding your navigation and menus? Have you run into this or other, similar problems?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Recently, I have seen a couple of different articles that have tried to address the question of what is the best content management system (CMS) to use for a website. First, Amber Weinberg wrote an article over on Freelance Folder, entitled “Which Content Management System Should You Focus On?”. The article basically introduces the concept of the CMS and its importance to modern day web developers, provides a brief listing of some different options, along some of the pros and cons of each (according to the opinions of the author), and offers a few simple tips on how to get started choosing your platform. It’s a great introduction for beginners.

More recently, Brian McDaniel authored a different post entitled “Why WordPress Is The Best CMS”. In this article, Brian explains a number of different reasons why he has migrated nearly all of his web work to WordPress from systems like Drupal and Joomla. He talks about a number of the benefits of WordPress as a CMS (even though it was originally created as a blogging engine), with his typical humour and wit (the closing line is priceless), making some interesting and valid points along the way.

Interestingly, both authors actually favour WordPress, and generally for reasons that I tend to agree with. Personally, I’m a big supporter of the WordPress platform and probably use it for about half of the work I do (with the other half being built on Concrete5).

Additionally, both authors also conceded that you really need to pick out the CMS that works the best for you. Amber touches on this by suggesting that you

Download some of the platforms you’re interested in, install them and try to code a couple of sites in them. It also helps to pick up a few books or read a few tutorials on the CMS itself.

Similarly, Brian writes:

The short answer to the oft-asked question we started with is this: choose the CMS that works best for you and your context. Try them all, if you have the time. You may find that something other than WordPress is your best CMS

What both of these comments ultimately point to is that the best CMS is the one that works the best for you. The respective authors each present you with the reasons why they choose WordPress over any of the others, but the final decision has to rest with you, your situation and the requirements of a given project.

From my perspective, that’s good, solid advice.

However, as I have been thinking about the idea of what makes one particular CMS better suited to a particular project, I thought about a number of different things. One was the way I differentiate between a WordPress-based project and a Concrete5-based project in my own work. That one’s actually pretty simple. Anything that requires a blog, news stream or other means of publishing periodic, article-like content will be built on WordPress. Similarly, anything that may require some complex, non-standard functionality is probably better suited to WordPress, because there is more likely to be a plugin, and even if there’s not, custom coding just tends to be easier.

On the other hand, if the project is for a simple brochure site, I tend to lean more towards Concrete5, which allows me far more flexibility in terms of the placement of multiple content areas, and actually allows me (or the client) to edit content directly from the page, rather from the admin back-end. I really dig that feature.

Regardless, this is a perfect example of how the unique requirements of a particular project ultimately direct my choice of CMS. The more I thought about it, however, the more I realized that there is another important factor that comes into play.

That factor is available resources.

I tend to agree with Brian and Amber in that creating a theme for WordPress is pretty simple, and hooking into its broad range of core processes is fairly straightforward too, allowing for a great deal of functional flexibility. On the Concrete5 side, turning a static HTML and CSS page into a basic theme is probably even easier than creating a WordPress theme, and involves just plugging in some snippets of code in the desired content areas. Coding custom functionality is a bit more tricky, but by now I’ve worked with the guts of the system enough to be able to figure most things out.

So, when I start on a new website project, I’m going to turn to one of these two solutions, based on the requirements of the project. That being said, however, it is entirely possible (and perhaps even likely) that there may be another CMS out there that, based simply on its feature set, might actually seem like a more appropriate choice.

But chances are, I’m not going to use it. Why?

Because what “works best” often entails more than a pure mathematical evaluation of functionality. It must also take into account things like time and resources, both of which tend to be a limited commodity.

As a real life parallel, I live in Canada, and right now we’re in the middle of winter. Winter is generally very cold here, and due to the effect that this severe lack of heat has on water, we have a tendency to get snow. Sometimes, we have a tendency to get a lot of snow. Unfortunately, snow is not a particularly considerate phenomenon, and it likes to cover everything pretty much equally, including our roads. Given this, I can tell you that there are times when a big, 4-wheel drive truck with extra large tires would be a much better transportation solution than the Mazda 5 that my wife and I currently own.

Unfortunately, we simply do not have the financial resources to afford that big truck, especially since we would only be using it a few times a year, when there is a lot of snow on the roads. So, we just have to make due with the vehicle we have (which, during most of the rest of the year, suits our little family just fine). It may not be the most ideal solution, but it’s always managed to achieve the intended result of getting us from point A to point B.

I think in many ways, the same is also true of web design and development. There may very well be another content management system out there that would actually be a better solution for a project, but you may simply not have the resources to implement it. That could be a matter of money, but more often than not its also going to be a matter of time.

Many systems come with a steep learning curve, which means that you would have to invest the time into actually learning how to code and develop for that particular CMS. Depending on the system, that can require a pretty significant investment, and probably one that most clients wouldn’t be all that keen on paying for. It is also likely to stretch out the course of your development cycle, and ultimately delay the launch of the site, which is another thing that most clients would probably prefer to avoid.

So, even though using WordPress or Concrete5 (or your CMS of choice) might not be the most ideal solution based strictly on core functionality, when you factor in learning curves and extended development time, things might look a little different. If I can accomplish the same objectives using one of these familiar systems that I could with a “better suited” system, in a fraction of the time, then for me it’s a better decesion to go with the familiar system.

After all, its the end result that matters far more than how you get there (though that’s not to say that the getting there is not important), and selecting the right CMS for the job is not always about a list of features. It can also be about comfort, time and limited resources.

In closing, I’d just like to throw out a quick shout out to both Brian and Amber for writing interesting, thoughtful and useful articles! Thanks guys.

What do you think? What is your favourite CMS? How to you determine what the best tool would be for a given project? Is it strictly a matter of features, or do you consider other factors too?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

This is the third post in what will likely prove to be the lengthy process of our Group WordPress Project. Thanks to everyone who left their thoughts and ideas on the last post, in which we were looking to establish the overall purpose of the site. A lot of the comments were pretty varied. Some people were looking for a portfolio-based theme, while others all but pleaded for the theme to not be portfolio based.

The one thing that I saw the most was the idea of having a social networking/interaction based site, which actually surprised me a little bit. I thought that an ecommerce shop or an online magazine theme would have been the clear winner, but it looks like you guys want something that really pulls together the whole social media thing. That’s an interesting idea and, I must admit, somewhat of a daunting challenge.

But, since I also don’t want to ostracize those individuals who may be looking for something else, what I am going to propose is a sort of personal branding theme with a high degree of flexibility, where:

• There exists a central hub, which functions as an aggregator of activity from a number of different social media outlets and anything that you actually post to WordPress itself (organized with custom taxonomies) with the option to have these displayed as separate entities or as a one, continuous stream.
• Some built in social networks would include:
  • Twitter
  • Flickr
  • YouTube
  • Digg
  • StumbleUpon
  • Dribbble
  • Possibly Facebook
  • Others? Suggestions open
• For maximum flexibility, it would be ideal to be provide a structure for individuals using the theme to also include other networks, since it would simply be impossible to include every conceivable network as a default in the theme itself
• In addition to aggregating social activity, however, the theme would also have the ability to support extended sections, including a basic portfolio, a simple ecommerce shop and a blog (magazine or personal). Moreover, these sections would be optional, and could be turned either on or off through an options panel.
• In addition to the various customization that we see above, the theme will also allow users to customize
  • Layout
  • Colours
  • Type

How does that sound to everyone? Obviously, there will probably be a few other little bits of goodness, but that should sum up the basic purpose that will drive the functionality of the theme. Anything I missed?

The next step for me will be to take all of this (and any extra suggestions), pool it all together and start developing an overall structure for how the theme will actually fit together. In the next post, I will probably talk a bit about how I approach that kind of work.

In the meantime, we have one more little bit of business to take care of—the name! There were all kinds of great suggestions, but the one thing that I saw coming through the most in your comments was that notion that the name of this theme should somehow correlate to the name Echo Enduring. I like that idea! So, I collected four of my favorite EE-related name suggestions, and then added a couple of my own ideas. Here they are:

• Enduring Discourse
• Echoes United
• Echo Interactive
• Echo Entourage
• Echonic
• Echunity

Personally, I really like the name Echonic. It fits in with the branding, and is nice, short and punchy. What about you guys? Which one is your favorite?

Well that’s it for this post. Don’t forget to cast your vote for the name, and feel free to leave a comment or idea as I work on creating an overall flow for how the theme will all fit together. Hope to have that done over the next couple weeks so check back soon!

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Alright folks, if you thought that I had forgotten about or abandoned the Group WordPress Project, think again! I’m still entirely dedicated to the concept, and am back with the next update. In the first post, I basically introduced you to the concept of the project, which is for me to work on a brand new WordPress theme, based on input, feedback and random strokes of genius from you, my awesome readership.

So far, there have been lots of awesome comments, ideas, suggestions and so forth, and now it’s time to start narrowing things down so that we can build a fuller vision of where we are going with this theme, what it’s going to look like, what it’s going to do and so forth. Based on the comments, I think that there are a few basic precepts that we can all agree on:

• Typography – I think that any theme design obviously needs to take its typography into consideration (like any design that uses words and letters), but the comments seem to suggest trying to take it even further. Well I have a few interesting thoughts and ideas in this area, so we’ll definitely be talking about typography. Anything you want to add here?
• Clean design – The general consensus that I gathered from the feedback I received on the first post was that the theme should be simple and clean, without going quite so far as to reach stark “minimalism”. Basically, this tells me that you’re looking for something that presents a clear, visual personality without getting too ostentatious or showy. Awesome. I am totally down with that.
• Flexibility – Another general thing that I see people asking for is a flexible theme. There has been talk of digging into custom taxamonies and post types. There was at least one suggestion about being able to change colours (I have a neat idea for that one). Basically, what you’re looking for is a theme that you can really take control of and make your own.
• HTML5 and CSS3 Goodness – Quite a few people suggested that they would want a theme built with HTML5 and CSS3. I absolutely intend to go this direction, making allowances for graceful degradation, of course.

Those are all really awesome thoughts, and we will totally be tackling them as we move through the series. The big thing we need to nail down though, can possibly be best summed up by Jorgen, who commented:

before jumping straight in and making big design decisions shouldn’t there be some rough idea what the theme’s purpose is going to be? An online magazine, photographers portfolio, design showcase, etc., etc. These are all very different types of websites and you cannot make one template to fit all.

This is an excellent point. Some people have suggested making a portfolio site. Others have suggested a quasi-social networking site, or an eCommerce site. I think the biggest thing is that I am seeing is that you want a theme that is more than just a blog, but we need to nail down exactly what that “more” will be. I’ve written and posted about functionality on a couple different sites lately and, as Jorgen rightly points out, an eCommerce site is very different form an online portfolio. They will require different functionality, and so we want to nail that all down from the start!

So, for the feedback on this stage of the process, I’m looking for your votes. Should the theme be for:

• Magazine style blog
• eCommerce site
• Portfolio
• Brochure site
• Social network/interaction
• Online gallery
• Other (please specify)

That’s the first part. The second part is a name. All themes have some sort of fancy name right? Well let’s start giving our project an identity. Offer up some suggestions for theme names (possibly based on your vote for the theme’s purpose). I’ll compile them all, select my a number of my favorites and then we can have another vote later on.

Armed with a name and a purpose, we will be well armed to start sinking our teeth into this project!

So now it’s up to you! Let us all know what you want our group theme to do, and drop a suggestion or two about potential names. I’m really looking forward to seeing what you come up with!

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

Alright everyone, I have an idea for a new project that I want to undertake, but I need your help to make it fly. There are a few different things that I’ve been wanting to do for a while, and I’ve wondering if I can combine them into a single awesome project. First of all, I’ve been wanting to get to work on a WordPress theme that I could distribute here on the Echo Enduring Blog. I’ve had a few people suggest that this would be something that they would be interested in.

Second, I’ve also had some requests for content that actually shows people how to build a WordPress theme entirely from scratch—or at least how to code it up from a Photoshop mockup. I can tell you right now that such an undertaking is not something that I would (or even could) do in a single post. With the amount of detail that I invariably go into, something like that would probably turn into the world’s longest blog post, and would be far to large to manage. A series of posts seems like the only real solution. I’m okay with that though. I’ve done a few series in the past.

Third, I’ve long been interested in running a kind of social experiment, by developing something based on continuous feedback from a community of users. Basically, the concept is to produce something in a number of stages. As I move from each stage to the next, I accept further ideas, comments, feedback and suggestions from the community itself, and allow that information to actually shape the direction of the project.

Lastly, I think an Echo Enduring eBook would be pretty awesome – don’t you?

The Proposal

So, if you haven’t already put the pieces together, this is what I’m thinking: over the next several months I will actually go through the process of developing a WordPress theme entirely from scratch, starting with ideas and concepts from you. Periodically, I will post tutorials working through what I’m doing at each stage of the project, and how to basically replicate the techniques in your own work.

Then, at the conclusion of each post I will ask for further feedback about where you think we should be going with the development of the project.

When it’s all said and done, I will have a fully designed and developed WordPress theme. I haven’t quite decided what I should do with it yet, but what I do know for sure is that everyone who contributes to the development of the theme will be able to download it for themselves. After all, you will have been an important part of the creation of the theme, so it will be partly yours anyhow!

Lastly, once everything is written and published here, I intend to pool it all together, polish, edit and compile it all together into a single eBook. I definitely intend on selling that, but again I’ll make sure that everyone who contributes to the project can get their hands on a copy, either free or at a significantly discounted price.

Your Part

Obviously, though, this project just isn’t going to work if I can’t get you, the reader, involved. Your comments and feedback are going to be the backbone of the entire thing, so I hope you’ll let your voice be heard and help shape the direction of this group Word Press theme project!

So, to start it all off I’ll just throw out a few general questions

• What kind of theme would you like to see?
• What kind of general direction should we go with?
• Talk to me about style: clean, grungy, textured, subdued, colourful?

Basically, let’s just work to nail down a really general and basic concept of where we want to go with this group project. Think of it as one big brainstorming session here on the Echo Enduring Blog. I’ll compile and consider all your ideas and come up with a general direction for the next stage of the project, and we can start talking in more detail about things like functionality and layout concepts.

Ready to get this thing started? Good! 1…2…3… GO!

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

In the spring of 2006, I graduated from University (for the second time)  my Master’s degree in English Literature. As fate would have it, within a matter of weeks, I was working full time at Highland Marketing, primarily in the area of web and graphics design. Who knew…

Actually, I had been doing this sort of stuff since 2000, when I graduated from high school. I’ve always been artistic and good with computers, so when I started working at Highland Marketing (a job I got because my father owns and operates the company), those were the skills that had the greatest value. I had also done a bit of work with Corel Draw in a couple of my high school classes, so I spent a lot of time doing getting my feet wet with some really basic and primitive design stuff.

By my 2006 graduation, I had been maintaining the website and doing some really basic graphic stuff off and on, usually during my summers. Being finished university, though, and looking at starting to work full time, I decided to really take the time to learn and invest myself in learning about graphics design in more detail.

That was just over three years ago. Today, I want to look at six technologies that I have been introduced over that time period, and which have ultimately changed my life, at least in terms of design.

1. Cascading Style Sheets

Okay, I admit it – there was a time when I actually did use… tables… to structure my website (oh how it hurts). That’s right, stupidly massive tables that contained all of my content. In retrospect those were dark days for me. Dark days, indeed.

Cascading Style Sheets were like a revelation

So, one of the first things that I did when I started to really learn about design – in this case, design for the web – was to dedicate myself to actually learning CSS. I had learned to use some basic classes and such, but  I really didn’t understand it as a technology. So, I took a trip to one of our local book stores and picked up Charlie Wyke-Smith’s Stylin’ with CSS, which I proceeded to read from cover to cover.

It was like a revelation.

The book taught me the purpose of CSS – to help separate presentation from content – and precisely how to write vastly more efficient style sheets that interact with properly coded HTML. It forever transformed the way that I approached web design and actually made coding a vastly more pleasant task (no more updating hundreds of font tags).

Today I use styles for absolutely everything I can, and spend a lot of time carefully crafting and tweaking the style sheets for the websites that I design. It has also opened up an entire new realm of design possibilities, since there is so much more that you can do with CSS than you could every have dreamed with bulky and awkward presentation-based HTML.

2. Adobe Creative Suite

As I mentioned before, I did have some experience with Corel Draw, and when I first started doing some graphics at Highland Marketing, they purchased me a copy of Corel Draw 8, which came packaged with Corel Photo-Paint. For years I did all of my graphics work in those two applications. I even did a few brochure designs in Draw, which, in retrospect, was a design nightmare.

Eventually, though, I upgraded to Creative Suite 2, and like learning CSS, that turned out to be a revelation. I basically started with what, for me, is the great trinity of design – Photoshop/Illustrator/InDesign. Of the three, InDesign came the most naturally (probably because I had never used a page layout program before). After that, it was Photoshop. The most difficult adjustment was moving into Illustrator, which functioned so much differently from Corel Draw.

Today, though, I know my way around those programs very well. I wouldn’t go so far as to call myself a master, but I am  actively writing tutorials for both Illustrator and Photoshop, and I use the programs on pretty much a daily basis, often in tandem. I don’t use InDesign quite as frequently, but it remains my application of choice whenever I have a design that involves a lot of text.

So, basically, these three programs form the very foundation of all the visual design that I do. As such, I guess it’s easy to see how they changed my life. Without them, I’m not sure where I would be in terms of design or what tools I would be using.

Oh yeah, and since I have recently upgraded to CS4, I have also added Dreamweaver and a bit of Flash in the repertoire of Adobe applications that I use on a regular basis.

3. Wacom Tablet

This was a piece of technology that I didn’t get right away. I certainly wanted to try one, and I knew it would be great for some of the more illustrative projects that came up from time to time, but for quite some time it just wasn’t in the budget.

A drawing tablet offers so much more control

Eventually, though, I did get my hands on an Intuos tablet, and now I couldn’t imagine doing what I do without one. The moment I open Photoshop or Illustator, I have to have my tablet plugged in. It gives me such precise control, and in a manner that just feels so much more natural than using a mouse.

For me, this is now pretty much an essential piece of equipment. If you’re debating whether or not it would be worth it to pick one up, let me offer you this bit of advise: do it! You can get some basic models for a very reasonable price, and I can almost guarantee that it will make your life a heck of a lot easier.

4. MacBook

When I first started seriously trying to improve my design skills, I actually did most of my work from home. There really wasn’t a lot of available desk space on site, and I was able to work efficiently in the quiet of my own apartment office. At the time, I did all of my work on my desktop PC. Later, when I started actually going into the office (just before the birth of my daughter and after some restructuring freed up some desk space), I transferred my work to my Toshiba Satellite, complete with Windows Vista.
CS2 ran… but just barely. Everything took forever.

So, when it came time to finally upgrade to CS4 (I just skipped CS3), I knew that it was also time to power up. And so it was, that I acquired my MacBook. It was worth the investment. I do all of my design work on the Mac and it flies. CS4 runs more smoothly than it ever did on my PC, and I can push Photoshop further without having to worry about running out of memory.

Also, OS X is just so much nicer to work in than Windows. Everything just feels more intuitive, and I really get the sense that the operating system actually works to make my job easier, rather than to just look pretty and eat up all my RAM.

5. WordPress

You may find this one odd, I’m dead serious. Several years ago, I was given the task of creating a blog for Highland Marketing (which has since kind of died… but we’re working at bringing it back, bigger and better and more manageable). I wanted to keep the blog hosted with our own provider, so a separate engine like Blogger was out of the question. At the time, our hosting package did not include any MySQL databases (which I didn’t even understand at the time anyhow), so I managed to track down a system called Blosxom, which was essentially a Perl script that could fetch data from individual text files on the server and mash it all together in a blog like format.

It was elegantly written in its own way, though certainly simplistic and perhaps somewhat inflexible. It did the job, though. Actually, as of the time of this post, the Highland Marketing website is actually being run by an extremely hacked and customized version of Blosxom. It’s not the best solution, but there is so much interconnected code that it would be a huge undertaking to port it all. I probably will eventually, though. Just not right now.

Enter WordPress.

WordPress proved to be an incredible application

I had a friend who was looking for a website designed, part of which included getting a blog up and running. I knew that I wanted something more than what I had been using, so I did a bit of research and started learning more about WordPress. I downloaded a copy and installed it, just to give it a whirl.

I loved it. And still do.

The application has a simple and intuitive shell which makes it really simple to use, and with its extensible architecture and vast collection of plugins it’s absolutely incredible how flexible WordPress can actually become.

But the real way that the program changed my life was through the concept of server side content management, which is a vastly superior way of maintaining content. Now, I use some sort of CMS for every website that I design!

6. Open Source

The last technology that I want to talk about today isn’t so much a technology as it is a mindset for developing technologies. I’m talking about Open Source. I love it. WordPress is Open Source. So is Concrete5 – the other CMS that I use. I’ve also found a number of other Open Source applications that I totally dig.

Firefox is probably a prime example. It has been my browser of choice for years now.

I also use LimeSurvey, which is really awesome Open Source, server side program for creating and managing complex surveys. I use the application to create questionnaires that I have clients complete, in order to help me achieve the best possible design for them.

Most recently, I discovered an application suite called OpenOffice. I really didn’t want to buy Microsoft Office for my Mac, but I was getting frustrated with not being able to access Excel files, and with having to use TextEdit to do all my writing. So I did a bit of research to see if I could find a couple of different Open Source programs to fill the void. Instead, I found OpenOffice, which is essentially a Microsoft Office clone.

I now have a word processor (like Word), a spreadsheet application (like Excel), a presentation application (like PowerPoint), and a database application (like Access). It’s such a relief, and I didn’t have to spend a dime.

These days, if I need an application to do something, I usually turn to the Open Source community first, to see if I can find a solution there. It’s absolutely amazing what you can find out there!

So there you go – six technologies that have really changed my life in terms of the way I design. What about you? What programs, gadgets, tools and/or philosophies have had an impact on your life as a designer? What would you recommend to people just getting into the field?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd