Previous Blog Design

I knew when I started selling on Theme Forest a little over a year ago, that I needed some kind of online presence. This was all back before I had ever created any kind of brand around the “Theme Blvd” name.

The main goals of the last design were simple. I wanted to seem personable to buyers with some sort of big goofy photo, and also have a place where I could post tutorials that I could then link buyers to when dealing with customer support questions.

The problem was that I didn’t have much time to devote to a personal site where there’d be no instant money rolling in afterwards. So, I did what we all do… I bought a theme on Theme Forest and whipped it up real quick!

First Design Attempt #fail

It’s only natural that our skills progress quicker than we can update our old stuff. I know I’m always looking back at designs I’ve done only months before, and thinking to myself, “What the heck was I thinking?”

So, it was clear that I needed to redesign my site. I didn’t think it would take much, as I figured my experience as a mediocre Theme Forest author should mean I’m qualified enough to design something at least a little unique, right? Well, it’s actually harder than you’d think to step outside the comfort level of designing business sites that all have the same layout.

This is that standard corporate layout I think many of us are really getting bored with.

Taking the redesign of my site too lightly, I was originally just planning to take another Theme Forest theme and modify it like I had done the last time. I even had the perfect one picked out. I was going to rip the “blog” part out of IvorPadilla‘s awesome theme, Americana.

I started with a screenshot of his blog design and started customizing it while watching my nightly fix of NHL on the Fly. This is what came out.

I actually sat tweaking that design for many hours, two nights in a row in front of the TV. Inevitablly, I knew that design wouldn’t cut it, and I needed to re-think my entire plan.

Goals for the New Site

After realizing this project would take me actually investing some real time in order to get it done right, I decided to do something that I learned from all that tuition spent on my superb college education (#sarcasm) … “Make a list, dummy!”

So I decided to do just that, and make a cheesy list of things I was looking to accomplish with this new website.

I have to say, this actually worked pretty well. Who knew something as simple as making a list of goals could put you on the right course?

The Wireframe

Taking the goals I listed above, the next step was to wireframe it out on paper before sitting down in Photoshop and just moving crap around.

So, here’s my initial sketch of the layout on my fancy-schmancy 960 grid system paper.

I actually starting doing a lot of these wireframes lately because I have so many ideas for new themes I want to create for Theme Forest, and the only way I can retain them quickly and not forget about them is to sketch them out.

The Design

Designing for me is by far my weakest skill in the entire website creation process. I spent a lot of time in Photoshop with this design trying different things out.

It was really difficult to come up with a “logo.” I mean what could I use as a logo for a website about myself? It seemed kind of pretentious to create some dazzling text treatment of my name. So, I decided to go with something that ended up summing up just about everything I was doing at the time, which was being confused and using Photoshop on my MacBook! Real creative, right? I know…

Two of my big design goals coming in were to create an ad space up top for Theme Blvd that people would immediately look at and that would also make people immediately associate my site with the brand. This was a bit of a challenge, but I think overall that turned out pretty well.

I also spent a fair amount of time mulling over the typography. This is also a pretty weak skill for me that I’m trying to improve on. I used these two e-books from Smashing Magazine to aid me along in the process:

• Getting the Hang of Web Typography
• The Big Book of Font Combinations

What ironically turned out to be the most important thing I wanted to accomplish (even though it wasn’t in the beginning) was to utilize WordPress 3.1 post formats to create a sort of Tumblr type of blog feel that would hopefully encourage me to post things more frequently by not always requiring me to write a lengthy article.

So, below you can see what I ended up with in Photoshop.

It actually did turn out pretty much exactly like my original sketch. The only major difference is that I ended up moving the sidebar to the opposite side. The reason for this was because the I needed more room for the main content area, and having the sidebar directly underneath the logo, but just barely not the same width, looked pretty funky to me.

The Development Process

Like every other step in the process, development ended up taking way longer than I had planned for. It’s obviously a given that I’d be using WordPress to create my blog, but going into the process, I wasn’t sure how much time I wanted to spend on making this into a properly coded WordPress theme. There’s a huge difference between making a theme for yourself and one for others to use.

Eventually, I decided that I wanted to take advantage of this time spent working on my personal site to “start” some other projects that I’d be doing after and also educate myself.

What I mean by that is that I was able to justify so much time spent on this website if I could get some additional value out of it. I did quite a bit of research on each element that I was inputting into this little WordPress theme. I looked up alternate ways of doing things that I thought I already knew how to do. Often when creating a commercial theme, it’s hard to find time for this.

I also spent a lot of time trying to come up with a way to utilize WordPress 3.1 post formats based on the brief information given over in the WordPress Codex.

http://codex.wordpress.org/Post_Formats

It’s not that it was difficult to code them into the theme, but it was difficult to come up conceptually with a good way to use them. The end result, as you can see here on this site, ended up being a blog format that resembles many blogs over on Tumblr.

So, while I didn’t code absolutely everything that I normally would with a theme I might be releasing to the public, I did end up with a pretty complete WordPress theme.

Aside from the WordPress part of the development process, I did spent a lot of extra time fine tuning and adding little random bits of jQuery effects like random pop up messages in different places, tooltips, etc.

Moving Forward

Making the WordPress theme for this new site gave me a lot of inspiration for some other things I’d like to do with WordPress. I’m really feeling this whole Tumblr vibe now. I’d like to utilize all the post format styling elements I came up with for this theme in some sort of WordPress theme I can release to everyone.

“Bloggy” WordPress themes don’t seem to sell well over on Theme Forest, so I’m thinking I’ll just make a WordPress theme similar to this site, copying and pasting a lot of the same elements, and release it out to everyone for free.

Also, I don’t want to take the time program in all the premium goodies that might be in one of my normal WordPress themes, so it’ll be nice to just put together a quick WordPress theme for once that doesn’t take months to complete.

With the themes I sell on Theme Forest, I get a lot of customer support questions regarding basic CSS issues. I understand that some people really are just looking to get whatever free work out of the theme author they can for that whole $15 the author just made off of the purchase when they simply drop a laundry list of CSS changes they want “help” with into the item’s discussion board. However, I also know that many theme buyers out there are legitimately trying to solve these issues themselves and they just can’t figure them out. These people want to learn and I’m sure they don’t like buying that WordPress theme and then feeling like they can’t move forward until the theme author finally responds to them telling them how to change the dimensions of the logo or how on earth that “one title” in that in that “one box” is styled.

So, now I’m going to give a very basic example of how you might go about making a minor CSS change with Firebug. Keep in mind that while I’m using my Theme Forest theme, Complexity, as an example, these strategies can be applied to anyone making any kind of CSS changes to their site. So, whether you’ve just bought a WordPress theme, or you’re diving into your partner’s sloppy code, these methods should work for you.

Download and install Firebug

Start by making sure you’re currently using the Firefox web browser. Then go to the Firebug website and download and install the addon.

CSS Example: Changing that random title in that random box

When you’re wanting to make a simple change, it’s not always so simple. It’s not enough to look at the HTML source code and determine what’s wrapped around an element and then know what CSS to apply in order to change it. You need to know exactly how that element is being styled in the current CSS files, so you can either change it, or override it.

Looking at this example, let’s say you want to change the font size of the titles of these three homepage boxes.

Many people might start by looking at the HTML source code and then determine that the title is wrapped in<h2> tags. However, this isn’t enough to tell you how to make your CSS change because you don’t know how the original developer coded it in the CSS style sheet. Sure, you could guess, but if you’re trying to make a bunch of CSS customizations, this is going to slow you down and take up a lot of your time.

So, let’s use Firebug to figure it out really quickly. Simply right click on the element you want to check out and click “Inspect Element” to open up the Firebug panel on the item you’re interested in looking at.

Now you’ll be shown exactly what CSS is being applied to that element and what file that CSS is located in.

Now you know that the CSS that controls this element is located in style.css and looks something like this:

#default-home-widget-area .widget h2 { font-size: 22px; }

From here’s it’s easy. You can either change that in style.css or write some CSS that overrides it somewhere else.

On my themes, and like many other authors, I generally have a place on my theme options page where you can put in custom CSS. So you might do something like this to change that above element to have a 15px font size instead of its default 22px size.

Why is this all so important?

The reason why Firebug made this so quick is because we needed to know the exact CSS declaration. With the above example, custom CSS like this would have had no effect:

1

.widget h2 { font-size: 15px; }

It needs to be like this or it wouldn’t have overridden the original CSS:

1

#default-home-widget-area .widget h2 { font-size: 15px; }

Because of how “cascading” stylesheets (CSS) work, anything that’s more specific or drilled down is going to take precedence over something that’s more broad.

It’s also a good idea to watch this helpful video walk through on all of the basic features of Firebug. You can do a lot more than just make simple CSS changes!

So, needless to say, I’ve been churning out a lot of WordPress sites recently at the agency. In this post, I’m going to talk about that last step you take in delivering your shiny, new WordPress site to your client filled with all of their content.

Generally, you’re not going to build the website on your client’s live domain. I usually develop the initial WordPress theme and put in whatever parts of the content I have at the start of the project locally on my computer using MAMP. Then I’ll transfer that site to a dev server where the client and everyone else my agency can view it. After a billion rounds of edits and changes, it’s finally ready to go live, and so then it’s transferred to the client’s live domain.

In creating all of these sites, it’s absolutely crucial to be transferring WordPress correctly. Your concern should be developing your client’s website and not struggling with elementary things like installing and moving around WordPress. If you’re new to the process of moving WordPress, don’t worry. I’m going to explain in it detail. I also would suggest that you practice moving WordPress a few times to different servers. After a few times, you’ll get the hang of it, and see how easy it is. If the first time you’ve ever moved WordPress is the time when you’re putting you client’s site live, you are putting yourself at some serious risk for embarrassment.

Keep in mind that if you’re simply moving your personal WordPress site a new server, all of the following steps are the same.

The Quick Version

To start with, here is a quick version of the process of moving your WordPress site from one to server to another. Even after you’re familiar with the process, it’s not a bad idea to have a checklist of all the steps you need to take sitting by your desk.

If all of those steps weren’t clear, don’t worry; I’m going to explain each one. In the following steps, I’m going to show some screenshots from when I transferred the demo site for my Complexity WordPress theme from my local computer to my live demo website.

The Long Version

Step 1: Export a copy of your dev site’s MySQL database as an SQL file.

The first thing I do is make a copy of the dev site’s database. Login to phpMyAdmin on your development server and export a copy of database.

When you do this, make sure you are actually within the database. You should see all of the tables of your WordPress installation as the screenshot below shows. Then, click “Export.”

Next, configure your export file as I have in the screenshot below. Make sure you have all tables of your database highlighted on the left side. Also, make sure you have the “save as file” checked at the bottom. Click “Go” and a copy of your database should be saved to your computer as an SQL file.

Step 2: Open this SQL file in a text editor and do a mass find and replace of your dev site URL with the new server’s URL.

Open up the SQL copy of your dev site’s database you exported in the last step in a decent text editor like Dreamweaver, Coda, Textmate, Netbeans, etc. Avoid using a default text editor that comes with your computer (like Notepad with Windows, for example). With large files, sometimes screwy things can happen.

Do a mass find and replace of your dev site’s URL with your new server’s URL.

This is a very important step. If you do this properly, all of your hyperlinks throughout your entire WordPress site will linked up properly on the new server (i.e. manual links you put to other pages in your content, links to images you’ve uploaded, custom links you’ve used in the menu builder, etc.)

I personally use Coda for Mac OSX for all my coding, and below is an example of how to do a mass find and replace with your database SQL file in Coda.

I know Dreamweaver is much more popular, and so here is a screenshot of doing the exact same thing in Dreamweaver.

Step 3: Make a copy of your dev site’s files so they’re ready to upload to the new server.

I personally feel it’s a good idea to actually make a copy of the files of your dev site because if you screw something up, it’s nice to know you have a fully functional dev site still sitting somewhere. So, make a copy of all files, meaning your entire installation of WordPress.

If you have your website locally because you’re using MAMP or WAMP, make a copy of the files. If you have your dev site on a live web server, download all the files to your local computer.

Important Note: Confirm everything in your wp-content directory gets copied. This directory contains everything crucial in the actual configuration of your WordPress site – Themes, Plugins, and Uploads.

Step 4: Create a MySQL database on your new server.

If you’ve created your dev site, I’m going to assume you know how to create a MySQL database. So find where your new server’s database management is (usually in cPanel or whatever similar software your web hosts uses) and create a new, empty database and assign a new username and password to it.

Step 5: Configure your dev site copy’s wp-config.php file with the new server’s database information.

Within the copy you made of your dev site’s files, open up the wp-config.php file and put in all the information from the database you created in the previous step on your new server – database name, database username, database password, and database host.

This is the typical process of installing a WordPress theme, which I’m sure you’re already familiar with. However, it’s a good idea to have your wp-config.php file all ready to go before you upload your files so you can minimize the amount of downtime on the new, live server before the site is actually running.

Step 6: Upload the dev site files to the new server.

Now that you have a copy of all your files, you’ve made sure everything in your wp-content directory is there, and you’ve configured your wp-config.php file, you’re ready to upload!

So, use an FTP client and upload all of your files.

Simply uploading all of your files via FTP is the most common way of doing this process, and it’s perfectly fine to do it that way. However, I do have a tip if you want to be a little more efficient.

Archive all of your files into a ZIP package and then upload that ZIP file to your new server. Most hosting accounts have an interface like cPanel with some kind of File Manager interface, which you can log into and then extract the ZIP package. And if you’re a little more saavy, you can shell in with an SSH client, and unzip that package really quickly.

There are a few of reasons why it’s a good idea to ZIP the files first before you upload the files. When transferring a WordPress site that has been fully developed, chances are you have a lot of files (i.e. your plugins, uploads, themes, etc). These files will take a while to upload and it’s much faster to upload an archived ZIP package.

Other than just the files taking forever to upload, another issue arises sometimes when uploading a lot of files at once through an FTP program. Often, your upload will time out or there will be a temporary connection loss to your server, or something breaks the upload for whatever reason in the middle of the uploading process. When you’re dealing with your client’s new, live site, you don’t want to be wondering if you’ve missed any files. By uploading a ZIP package you can be a lot more certain that you’ve gotten everything successfully to the new server on the upload.

Also, if you are uploading the files one at a time to your new server and someone happens to visit the live URL, they’re going to be presented with funky error messages because WordPress is only half there. This is actually more for the benefit of your client. Clients are always excited about their new website and will keep checking the live domain like an eager schoolboy on Christmas morning, waiting for it to be up. When they see some PHP error, they are going to freak out and call you. You’re going to have to then explain to them that you’re still in the process of uploading files and working on the site.

Step 7: Make your uploads directory writeable (permissions 777).

If you want your client to be able to upload images and files via the WordPress admin panel, make sure you remember to make the uploads directory writeable (permissions 777) on the new server.

You can go in do this with any FTP client.

Step 8: Confirm your database is linked up correctly by going to the new site and seeing the Install WordPress screen.

Now that all of your files are uploaded and in place, it’s a good idea to make sure the files are there and that your wp-config.php is connected properly to your new database. So, if you visit the URL of the new site, you should be forwarded to WordPress Installation screen because your new server’s MySQL database is still empty.

If you’ve inserted something incorrectly in your wp-config.php file or the new server’s MySQL database was not setup properly, you’ll know because you’ll see WordPress’s database connection error.

Step 9: Import your dev site’s SQL into your new server’s database.

Now you’re going to need that SQL file you created back in steps one and two.

Login to the new server’s phpMyAdmin and navigate to the database you’re using. If you’re unsure how to do this on the new server, make sure to contact the web host’s customer support and ask.

Click the Import tab. Then, select the SQL file from your computer and click “Go” to import the data.

You should see a message that lets you know your query was successful, and you should see that your database is now populated with all of WordPress’s content.

Now if you go back to the new, live site, you shouldn’t be forwarded to the WordPress installation page. You should see your website!

Step 10: Login into the WP admin of the new site and go to Settings > Permalinks and click “Save Changes” so an .htaccess file with permalink structure is created on the new server.

At this point you should be just about finished. If you had permalinks setup on your dev site, and you start clicking around the new, live site, you might initially notice that none of your pages are showing up when navigating away from the homepage. What the hell? Don’t fear! There’s a simple answer.

Basically, your WordPress database is configured with the correct permalink structure, however the needed .htaccess file that gets created back when you setup your permalink structure on your dev site isn’t there anymore on the new server. So WordPress is trying to navigate to the correct links, however, your server isn’t setup to handle them yet.

The fix is easy. Login in to your WordPress admin panel and navigate to Settings > Permalinks and simply click “Save Changes” so WordPress can create a new .htaccess file on your new server.

With some web hosts, WordPress will give you an error message when you try and save your permalink settings, telling you that it couldn’t create an .htaccess file. This just means that you need to go into your web host’s file manager and create a new file, name it “.htaccess” and then make it writeable (permissions 777).

With that said, there have been times where I want to slap every browser upside the head, but with a little focus and research, there’s always a fix!

I see a lot of novice developers, beginning authors on Theme Forest, and developers just learning how to code tableless designs complain that their website works perfectly in Firefox, but then completely breaks in Internet Explorer. It’s one thing if your website is totally destroyed in IE6. I get it. It takes a lot of practice to understand why IE6 does what it does, and none of us will ever fully understand what Microsoft was trying to accomplish there. And even though I do generally try and support older IE’s, I don’t expect everyone to do that. It’s a personal call from developer to developer, depending on the situation you’re in.

With that said, there’s really no reason why a website you develop would work in the latest version of Firefox, but then be totally destroyed in the latest version of Internet Explorer. This just means that there are clearly some things that you don’t understand, and there’s absolutely nothing wrong with that; this is how you learn. Just don’t bitch about it in a forum and curse IE because you don’t understand basic web development concepts work, like the box model, for example.

Oh the box model, you say?

Yeah, I just threw it out there! We’re getting closer to the reveal of the Bobich Law of Browser Compatibility.

For those of you that don’t know, the CSS box model describes the boxes that are formed around elements of content in a Web page. Every element in a Web page is in a box or is a box. The boxes on Web pages are constrained by rules defined by the CSS box model.

Well, I already know about the CSS box model, so what’s your point?

This is all nothing new, right? Many developers know all about the CSS box model, but choose not to think about it until they see a broken website in IE.

I used to have a partner at the Advertising agency I worked at that was so adamant about W3C compliance that he would always say with his nose pointing up to the sky, “I design for W3C standards only. IE comes later.” Then after the site was essentially finished, he’d view his broken site in Internet Explorer and start going through and making changes in a stylesheet called with an IE conditional statement. No offense to him if he ever reads this, but while neatly commented, his HTML/CSS was quite sloppy and he spent way too much time trying to configure this sloppy CSS file for IE.

But would you believe there’s a way for your website to have totally W3C compliant CSS while still having all of your boxes be the same width in both Firefox and Internet Explorer?

So what the hell is it already?

It’s so simple, you’re going to be embarrassed I had to tell you, but this is a rule I’ve developed for myself and I always follow whenever I code anything. And finally, this is what I’ve dubbed the Bobich Law of Browser Compatibility:

Never set a width to a box that has right/left padding or right/left border, and conversely, never set a height to a box that has top/bottom padding or top/bottom border.

Easier said than done, Jason! I need padding and widths on all my divs, how will I ever trudge on?

Don’t worry, friends. I’m not going to just throw out something as mind blowing as the Bobich Law of Browser Compatibility without giving you some helpful information on how to work with it.

Keep in mind that many developers might disagree with the methods I’m about to share because they could be said to add too much cumbersome HTML markup to your site, but I don’t care. If you’ve purchased any of my Theme Forest themes, you’d know that I write extremely clean HTML and CSS that looks almost identical in most browsers.

Basically, on all of my major layout divs that need a width, I also add in a nested div that will have any padding or borders associated with it. Here is an example of a box that will be 300px no matter if it’s viewed in Firefox, Safari, Chrome, Opera or even Internet Explorer.

Here’s the code that produces the above box:

1
2
3
4
5
6
7
8
9
10

<style type="text/css">
.example-box {
  width: 300px;
  background: #f2f2f2
}
.example-box .pad {
  border: 1px solid #ccc;
  padding: 10px
}
</style>

1
2
3
4
5
6

<div class="example-box">
   <div class="pad">
    This is a box that's 300px wide in all browsers with 10px
of padding and a 1px border.
   </div><!-- .pad (end) -->
</div><!-- .example-box (end) -->

Now, I’m not saying you need a div inside of every div in your website. If I were saying this, I’m sure Nick La would slap me across the face! Nick La runs the super awesome web design blog, WebDesignerWall. He’s even written a post about not having nested divs all over the place, and this is why I made sure to say I do this only on my major layout when I need to. So, I definitely agree that wherever possible, as Nick stresses in his post, that you should avoid extra divs.

For example, say you have some HTML like this:

1
2
3
4

<div class=”box”>
  <h2>The Title</h2>
  <p>The content…</p>
</div>

If you have a set a width to that “box” div and you want there to be padding within it, there’s no need to put another nested div inside when you can just add padding to the <h2> and <p> tags.

The idea here is to follow my silly Bobich Law of Browser Compatibility while still trying to write as little code as possible.

While we’re at it, here’s another quick tip for writing easy-to-manage CSS that will help:

Don’t declare a width on an element when you don’t have to.

In my opinion, putting widths on every div within a div means that most likely you don’t fully understand how margin and padding work or you’re not planning out your design very well before coding. Before you code, you should have a plan. You should know that if you have a column that’s 300px wide with 10px of padding and you place a nested div inside of that, it will automatically fill 100% of the width, resulting in a div that’s 280px. That’s a very basic example, but you could see how this could get really confusing and out of hand if you have many boxes within boxes and you’re not planning these things out.

These are some very elementary tips, I know, but they might help many developers who are either just learning tableless design or just that have never thought of the obvious, I guess.

I always find it interesting when other web designers and web developers talk about how they go about their business. So, I thought I’d share my basic workflow process for putting together a website. This isn’t any kind of fancy how-to, but simply an explanation of some of my methods. Now I’m not going to tell you I follow the same, rigorous workflow with every project because that would just be a lie; I’m totally not organized enough for that!

By day, I’m a web developer at a fancy-schmancy advertising company, but by night I’m a web developer for the people! With my personal projects and templates that I make from home, I follow a much less structured workflow. With no budget or deadlines, I’m free to spend as much time as I want adjusting my drop shadows and gradients until they look just right. Unfortunately, for now I’m stuck in the real world and my day-time job calls for me to be much more organized and productive with my time. Some times it feels like I’m “cookie cutting” out websites day after day at work, but it is what it is.

Now keep in mind that when I make a website at my agency, I don’t deal with clients, I don’t budget finances or hours, I don’t write any content; there are different departments that handle all of these things. I simply design and develop. So when I get a new docket on my desk this is the basic process of how I bust out a website over the course of a few days. I’m going to skip all the boring pre-meetings, planning, and approvals throughout the process and just share the good stuff.

1. Design

I do all my designing in Photoshop. Sorry, I’m not much of a Fireworks guy. I’m in love with the 960 grid system. I start most of my designs with the 12-column Photoshop file you can download from their site. With that said, I’m way too anal about my CSS to use their CSS framework, so I’m only down with the 960 grid system for the initial design.

This web layout was originally designed by MSI's ultimate art guru, Scott Mlynarczyk, for Carlile Transportation Systems.

I can honestly say that I do not consider myself much of a “graphic designer.” Sure, I can make clean, minimalist designs with good typography and proper spacing, blah blah, but when it comes to actually adding hardcore graphical elements I head to Graphic River and drop $3 here or there. If you’re ever at a loss for design ideas, don’t hesitate to search the web for inspiration or even buy a few graphics from a site like Graphic River. You find a stock image or another website design you like, you start off copying a few things, and before you know it, you have a completely different masterpiece that you can call your own. By the end, you won’t even see a resemblance between your final product and whatever things you originally got inspiration from.

I’m very meticulous with my measurements. I use round numbers whenever I can. For example, I wouldn’t ever make a header section that is 88px in height; it would be 85px or 90px. I’ve found that the more you measure out in Photoshop, the more symmetry you plan into your design, and the more round numbers you use, the easier things are when you take it into development. I’ve worked with many artists who think my OCD for pixel measurement is overkill, but I think I just have more going on in my mind when I’m laying it out aside from simply how it will look.

Even in a time crunch, I still attempt to be at least somewhat organized with my layers and layer groups within my Photoshop file. A lot of the times I’m rushed by my agency due to a low budget or a time crunch, however the client, the account managers, the creative director, and the “higher ups” will always want several edits. So keeping an organized Photoshop file that I’m familiar with always keeps making edits a breeze.

Also, many times a site is designed for me by one of the other graphic designers, in which case it’s often done in Adobe InDesign. If you know anything about web development, I’m sure I don’t even need to voice my frustration with this. Designing something for a world of pixels in a software that creates for a world of print is a definite sin in my bible. Either way, it is what it is. You gotta to roll with the punches. So, a lot of times, my “design” phase consists of taking an InDesign file and creating an actual workable psd file that I can develop from.

2. Development

If you haven’t figured out by now from the screenshots, yes, “I am a Mac.” I’m not exactly proud that I jumped on the band wagon of locking myself in for a lifetime of addicting, overpriced computers and gadgets, but none the less, I couldn’t help but get sucked in.

I have to say my absolute favorite thing about being a Mac user is the software, Coda. I’m really obsessed with Coda. I finally got my ad agency to dig deep into their pockets and find me the $99 for a Coda license about 2 months ago. Right away, I setup all my current projects in Coda and told Dreamweaver to step off.

Also, I now use PHP for every project even if it’s a static site. In my opinion, there’s just no reason not to have simple header/footer includes on even the most simple websites. We have a web server in our offices that all of the web developers work off in order to have all the websites in a place where any of us can access them. But, at home, I’m 100% MAMP…. Once again, this is another treat of being a Mac user. For those of you that don’t know, MAMP is a free software that allows you to run PHP/MySQL locally on your mac for development purposes.

Now getting into it, the development process is my favorite. After all, that’s why I’m writing more about it than any other of the other steps! I am an absolute CSS dork. I’m always looking for tips, tricks, and ways to improve my CSS and make my HTML markup as minimal as possible. The development process is the one time at work that I can really put my headphones on, jack up the Pandora, and crank it out. With other web developers assigned to their own projects, there’s absolutely no one else that can stand over my should and critique. Believe me – the day an account manager looks over my should and says, “Um, you’re definitely gonna want to hide the overflow on that div,” is the day I will quit. No worries on that one, though. When I’m in a sea of code, no one bugs me. It rocks.

I make so many small, low budgets websites at work, that it’s really important for me to bust these things out as time efficiently as possible. I start my sites with a little starter template I keep on my desktop. It includes the basic folder structure and some initial files I use for almost every website. This is the case whether I’m making a static site or WordPress theme because I always make WordPress themes completely from scratch. Sure, I’ll copy and paste snippets in later on, but the initial process always starts with a single static HTML page.

I almost always have already planned out the HTML markup in my head while I was laying out the design in Photoshop. This is another reason I’m so meticulous with my measurements in Photoshop. Besides, most sites I do are not mind blowing Internet phenomena; they pretty much all have your standard elements, and that’s another reason why it’s easy for me to sort of formulate a plan of attack in my mind.

So, I continue by saving out the images I need from my Photoshop file in the images folder I already have made in my starter template. This is a random tidbit, but I do not “slice” in Photoshop. I think it’s silly. You can do it if you want, but don’t insist that I do it. Then I write out all of my HTML markup. Next I write out all of my CSS.

I’ve gone through this process so many times that I pretty much have a good idea of how what I’m coding is going to appear in all the browsers I plan to support (generally IE6+, FF2+, Chrome, Opera, Safari). So, with following a few simple rules I’ve made for myself, I go forth coding and only viewing what I’m doing in Firefox.

I think I’m actually going to write a blog post later on about my simple rules I’ve made up for myself to stick to while coding in order to avoid conflicts with different browsers… And by different browsers, I mean all browsers versus the IE browsers!

3. W3C Compatibility

This is usually very painless for me and a quick task. There’s not much to say here. I open up the website I’m working on in all the standard browsers and check to make sure they look passable. They generally do.

4. Internet Explorer Compatibility

It always used to be a pain in the ass checking my sites in Internet Explorer, but I’ve slowly began to make my life easier and easier over the last few years. I have a few simple rules that I follow while coding my sites, and usually when I open it up in Internet Explorer, it looks how I intended it to. If I ever have Internet Explorer issues, it’s due to some javascript error that I can usually find and fix pretty quickly. I know I make this sound very easy, but keep in mind that none of the sites I’m creating at work are very “out of the box.”

You also may be wondering if I code for IE6? I did say it earlier, but yes I do. Even though every web developer thinks IE6 is the Satan’s spawn of a browser, I still support it. Why? Click here for my IE6 rant.

To accomplish this dirty deed, I use VMware Fusion, which allows me to run Windows 7 on my Mac. Then I open up the handy IETester and give whatever website I’m working on a quick spin in IE6+.

5. Post it for review

After I’ve cycled through the same songs on my Pandora channel a crap ton of times because I’m too picky with adding variety and thumbing songs up, it’s time to post the website live on the Internet at a top secret location now that I’ve finished it.

Keep in mind that most sites that I “finish” are far from finished. It’s rare that I was given everything I needed when I was tasked with actually developing a website. Generally more copy and content is still to come. The sitemap is in for a big change from it’s original mockup. Images are to be replaced. Decisions that were made before will inevitably change.

So, I email that top secret web address off to my creative director, and I assume it travels through about 20 different people and the client inevitability? I’m not really sure. But low and behold, a month or so later I get back edits. But it’s good that I write consistent, neat code because I can always pick up a project right where I left off no matter how many other sites were in between!

It’s really peculiar when I compare the amount of websites I work on with the amount of sites that have actually gone live… Anyway, that’s my workflow process. I know that kind of turned into more of a “Confessions an Agency Web Developer” post, but I hope you found it interesting!

Feel free to comment below on your own personal experiences and methods.

Let me start off by yelling from the rooftop, “I hate IE6!”

How many times have you heard that around the web development community? I have to be honest. I’m really tired of hearing everyone’s bitching. If you’re really making a cutting edge website, then don’t bother with supporting IE6. I think your website’s users can appreciate a simple upgrade notification or something similar.

Okay. So here’s my answer on the subject as a web developer at an advertising agency:

I do support IE6. I have to. I live in the real world where not everyone is a web developer. A world where people don’t all have new computers. A world where not all people upgrade their computers. A world where many people don’t even know what a web browser is. The point is, in most cases, you’re going to have clients that have all kinds of Internet users. Whether you like it or not, you have to support them.

Did I mention I live in Anchorage, Alaska? Yeah! Needless to say not all clients have Windows 7 installed with the latest version of IE. Not to mention we have tons of clients that serve smaller, remote parts of Alaska.

It seems that any time I make a site that doesn’t work in IE6, I hear about it. I generally have an account manager come to me, and say, “The client says the site doesn’t work. Can you fix it?” This is code for “it doesn’t work in IE6.” If you think supporting IE6 is ridiculous, try explaining to your account manager when they tell you “it doesn’t work” what this mystical IE6 thing all the web developers are bitching about is. Prepare yourself for a nice, “Can you fix it anyway?”

For me, telling an account manager that I’m not going to fix a website because we shouldn’t be supporting IE6 is like telling a child that Santa isn’t coming this Christmas. They don’t understand, they don’t like it, and they want it anyway.

Now here’s my answer as a Theme Forest newbie:

Basically, I support IE6 if it’s convenient for me. I try to abide my simple CSS methods that generally make my sites look similar in all browsers. However, in the end if it doesn’t look perfect in IE6, I really don’t sweat it. If something looks really screwy and I don’t have to spend much time fixing it, sure, I’ll do it.

There are definitely a lot of times that when I’m making sites at home that are more “out of the box” I run into a complete mess in IE6 at the end, and you know what? I say screw it. Believe me, I’ve never seen a drop in sales on a template for it not working in IE6; that’s for sure.