Archive for the ‘Browser Compatibility’ Category

Making A Website From Start To Finish – Part 3

In Part 1 and Part 2 of this tutorial of how to make a website from start to finish, I talked mostly about the preparation before you begin the development and publishing process of the website. Now, in Part 3, I’ll talk about the actual coding and development of the site, the publishing process, and then how to test and improve your site once you’ve finished it. Here’s a list of each item we’ll talk about:

  • Database Design and Creation
  • Site Development
  • Cross Browser Testing
  • Installing Analytics
  • Publishing Your Website
  • A/B Testing, Data Analysis, and Site Optimization

As in Parts 1 and 2 of this tutorial, I’ll use our fake restaurant website as an example for each item in the list.

1. Database Design and Creation: Before you go ahead and build your website, you should determine if you need a database to store any information for display or interaction purposes. If you are using WordPress, then there are tons of plugins that can help with this. If you aren’t using WordPress, then you should build out your table structure, determine the foreign key relationships between tables, build them, and insert at least some test data before you begin your site development. I’m not a database expert, so I won’t go on to describe the details of this step, that’s up to you, I’m just saying you should handle it before you start developing.

For our restaurant website, we can go in one of two directions. We can have hardcoded menus, or, we can use a database to power the menus. If menu items are consistent in structure (if individual items all follow the same pattern of a name, description, and price for example), then I’d opt for a database. I’d set up a table of menu items and menu categories (such as appetizers, salads, desserts, etc.), and possibly seasons since we talked about the menu changing seasonally before. Then I’d handle the foreign key constraints from the categories and seasons tables into the menu items table so that each menu item has a name, description, price, availability (boolean flag so we don’t have to delete items), category foreign key, and season foreign key. I’d handle the interface for editing these database tables later.

2. Site Development: Now that you’ve got your designs, content, database (if needed), and CMS (if needed), you’ve got all the tools to complete your site development. Here’s how I’d recommend going about the development process:

Step 1. Get your header and footer templates or master file set first. To do this, build out a full single page in static HTML with your CSS in a separate document. Now that you’ve gotten a full single page, you can identify where the content is going to change from page to page, thus allowing you to pull out the parts of HTML that will remain the same on every page. With this knowledge, you can separate out your header and footer files (or master file, depending on what environment you are coding in), leaving you with a single working page that uses template file/s plus and external style sheet.

Step 2. Begin building out your other individual pages. Add more CSS as needed. Add in your content as you encounter each page. Hook in your database if appropriate. Focus primarily on all of the static content (whether it is hard-coded or brought in from the database doesn’t matter), and leave the interaction for later.

Step 3. Finish off your development with javascript. Once you are done developing a bulk of (or all of) your pages, you can add in javascript to improve usability and add fun and interesting effects. Javascript is a basic component to a majority of websites now, and many even rely on it. Javascript, being a client-side language, has the potential of really improving user interaction and bringing your site to the next level.

3. Cross Browser Testing: After you’ve finished development of your site, it is time to test! Depending on the complexity of your site, you could include some other quality assurance in this testing, but for simpler sites, for the most part, cross-browser testing is probably sufficient. Currently, it is important to test in IE, Safari, Firefox, and Chrome. It is also ideal to test those browsers on both a Mac and a PC (except for IE on Mac). Depending on what you expect your user base to be like, you may also want to test on an iPad, iPhone, and Android. Between those three mobile devices, you’ll cover a huge majority of your smaller screen sizes.

For our restaurant site, I’d open up the same page on each browser, and fixing any issues that arise in all browswers before moving on to another page. I’d also go through the navigation in an intentional and systematic way. I find this is the best way to ensure you don’t miss any issues.

4. Installing Analytics: Analytics will help you track how many people see your website, and how effective your website is at accomplishing various goals. I’d recommend Google Analytics, a free analytics tool powered by Google. It is very powerful, incredibly easy to setup, and offers all the tools you need to analyze the effectiveness of your site. Google Analytics, as most other analytics tools, require a small amount of javascript code on every page. Add the code to your template files before you publish so that you’ll be good to go when people start accessing your site.

5. Publishing Your Website: Now that you are sure your website is ready for public view, it is time to upload it! If you are using a CMS (such as WordPress), then publishing is easy. If you aren’t using a CMS, then you need some way of putting your new website files onto your server. I use Filezilla for Mac, an excellent FTP client, but there are a ton of good FTP programs out there. With your setup hosting, you should have received FTP credentials. Add them into your FTP software to access your server, and then drag and drop your files in. That’s it!

6. A/B Testing, Data Analysis, and Site Optimization: After setting up analytics and publishing your site, the job isn’t quite done! Now you’ve got to analyze any data that is coming in, and spend a little time optimizing language to increase various conversions and actions on your site. You might want to verify that certain language is getting across your message or bringing people to a different page. I’ve used various A/B testing services, but currently, I’m hooked on Optimizely. This service is not free, but there are free ones out there.

For our restaurant site, there may not be a ton of A/B testing to do, but I would definitely want to see if users were visiting the site, how much time they were spending on it, what content they mostly wanted to read, etc. You can learn what keywords are bringing users in, which can lead to good marketing tools down the line.

That brings us to the end of this three part tutorial on making an entire website, from start to finish. We talked about the beginning stages of branding, planning, and designing, to the middle stages of development preparation, to the final stages of development, publishing, and analysis. I hope it helps you understand how a website comes together, and all the things that you should consider when working on a project the whole way through. If you have questions or comments, obviously, feel free to share or contact me directly. Best of luck on your website projects!

Email Client Compatibility – HTML Friendly Emails

As a web designer, I actually do not frequently find myself working with email designs. So when my employer requested some HTML email templates, I had to do some research. I found a fantastic article on HTML emails that really helped me out. It was a bit long though, and I discovered some additional things along the way that I thought I’d share.

The first thing you have to do as a web designer when working with HTML emails is forget everything you know about modern coding standards. HTML email is years behind the curve. You’ll find yourself using inline CSS with limited shortcuts, tables instead of divs, and even deprecated attributes that haven’t been used in years.

The second thing you have to do is settle on a simple design. If you thought cross-browser testing was a miserable experience with four to five browsers (Safari, IE, Firefox, Chrome, and maybe Opera… plus mobile if you desire) try the dozens upon dozens of different email clients that all render differently! There are some good resources out there for cross-email-client compatibility testing such as Campaign Monitor or Litmus, but most charge, and if they don’t, they have a lot of restrictions like frequency of checking.

So here are the secrets to making your emails look good across all of your major email clients:

1. Use Tables For Layout because floating and positioning doesn’t work all that well. If you need something to appear next to another item (such as an image next to text) you should still divide that up into two tables. I know I know, it goes against everything you’ve ever known about modern coding standards and practices. But trust me, it’s the best way to go.

2. Use Inline CSS Only unless you don’t want your emails to all look the same. Some email clients will strip out the head tag or any external style sheet references, and others anything within a style tag. Keep in mind, many of these email clients are browser based, meaning they have their own custom CSS. To protect that CSS, they’ll strip anything out that could interfere with it before displaying it. And don’t even think about javascript…

3. Don’t Shy Away From Deprecated Attributes like width and border for your tables. When in doubt, just include it, because W3C standards do not really apply in the same way for emails as they do for websites. I always double my declarations. If I want my table to have no border, then I put that in my inline style declaration, and as a border="0" within the tag.

4. Avoid CSS Shorthand like "font: 14px Arial;" and instead do it longhand like "font-family: Arial; font-size: 14px;". Some email clients won’t read the shorthand CSS, though admittedly a majority do.

Here’s a bare, one column template that you can use with a single h1, h2, p, and a tag. Notice the XX and YY for your own personal preferences. The 98% width on the main table prevents email client bugs that create horizontal scroll bars.:

<table style="width: 98%;"><tr><td valign="top" align="center">
<table style="width: YYpx;"><tr><td valign="top">
<table width="YY" cellpadding="0" cellspacing="0">
    <td style="width: 600px;" valign="top">
      Header Content Goes In Here
    <td style="width: YYpx;" align="left" valign="top">
      <h1 style="font-size: XXpx; color: #XXXXXX;
        font-family: XX; margin: XXpx XXpx XXpx XXpx;">Enter Your Header Here</h1>
      <h2 style="font-size: XXpx; color: #XXXXXX;
        font-family: XX; margin: XXpx XXpx XXpx XXpx;">Enter Your Subheader Here</h2>
      <p style="font-size: XXpx; color: #XXXXXX; font-family: XX;
        margin: XXpx XXpx XXpx XXpx;">Enter Your Main Content Here</p>
      <a href="" target="_blank" style="font-size: XXpx; color: #XXXXXX;
        font-family: XX; margin: XXpx XXpx XXpx XXpx;">Enter Your Link Here</a>
    <td style="width: YYpx;" valign="top">
      Footer Content Goes In Here

In a future post, I’ll discuss ways to avoid getting your email marked as spam, as well as other best practices for making a good marketing email.

Take a Stand: No More IE6!

It is time for the web design community to take a stand and stop supporting Microsoft Internet Explorer 6! That’s right, I said it, as many have said before me, and yet somehow, most web designers still cross-browser test in IE6. Well, guess what, I’ve stopped. Okay, not completely. With my freelance clients, I will probably still check IE6, because truthfully, many of my clients themselves still run IE6. However, at my fulltime job as the web designer we have officially stopped supporting IE6! So why did I push for this, and how are we handling it?

So, some quick stats on Microsoft Internet Explorer 6. IE6 was launched by Microsoft in 2001. Though it has had some minor updates since it’s initial launch, you know that doesn’t change anything, especially because some people out there are still using that first launched version! IE6 came standard on every Windows machine since then until IE7 was launched in 2006. Now last time I checked (aka when this post was written) it was late 2009. IE6 has been out of date since it’s inception, but has definitely been out of date since it was replaced by IE7 over 3 years ago. So how it is that still approximately 5% of internet users still use IE6? Well sadly, Microsoft does not require, or even really push users to update, especially in the olden days. I grabbed that 5% estimate off of Google Analytics for my own site, my fulltime employer’s website, and a few of my freelance clients. Though the percent is slowly falling, it will be around for a while I’m sure. So, based off of the small percentage, which is slowly falling, and the fact that cross-browser testing IE6 occupies at least 50% of my cross-browser testing time

The irony of it all is that even Microsoft is desperate for users to upgrade off of IE6 to IE7 or IE8. This of course begs the question, how stupid do you have to be to still run IE6!?! At least 90% of the display bugs I’m aware of are solely IE6 problems. Entire blog articles are devoted to listing bug fixes for IE6. Well, based off of all of those stats, our company finally let me move away from IE6. We put up a warning (only visible to IE6 users) that we don’t support IE6. We even included a link to download IE8, but somehow I don’t think that’s gonna do anything. I’m just glad to be done with it!

So if you know what’s good for you as a web designer, forget IE6! The more people that stop supporting it, the faster people will switch off of it, and the faster we’ll be rid of that evil browser that has trouble outputting today’s beautiful websites. Of course, if you are still making websites with red text on a blue background, maybe you should still be testing in IE6…

Cross Browser Testing

If you are making a website, you absolutely need to test it across browsers. This need increases even more when you use CSS heavily for your layout and other styling. Why you ask? Well, different browsers read CSS differently. In particular, Internet Explorer (IE) is awful because Microsoft doesn’t feel the need to ascribe to web standards. So here are some suggestions to get your started with your cross-browser testing:

1. Download every major browser to test your site in. Essentially, you should be working with Firefox, Internet Explorer, Safari, Chrome, and Opera. Opera is used by about 3% of internet users, and is the least common of the five mentioned here. There are also other browsers, but usually you need to stop somewhere, and I think Opera is a good place to end.

It might help to set yourself up with Google Analytics so you can know what percentage of your users are using what browsers. It will even break it down further into what version your users have, which brings me to my next point.

2. Make sure to test both IE7 and IE6. Internet explorer 6 and 7 are vastly different. Soon, IE8 will be out of beta testing and will be yet another version that needs to be tested. This is the biggest pain you’ll encounter. IE7 is actually pretty good at complying with web standards, but IE6 is like a death trap. The problem here is obviously you are only allowed to have one version of Internet Explorer on your browser at any given time. So, either install a virtual machine (much to techie for myself) or keep setup files for both IE6 and IE7 around, and just uninstall and reinstall (which is annoying, but it does the trick). Why must we go through such painful agony just to make sure our site looks good? Well, sadly, too many PC users don’t let Windows automatically update for them, leaving about 25% of IE users still with version 6. This is of course sensitive to the date of this post and will slowly decrease. Overall, in the past 6 months, I’ve found users of my company’s website go from about 18% IE6 users to 14%, which isn’t even statistically significant. Bottom line, test in both because they are vastly different!

3. Try out some of the free cross-browser compatibility testing tools out there. There are a lot of them, but most just want your money, and most aren’t very great if they are free. Short of shelling out some money, your best bet is probably However, last I checked they limit you to one page (with every browser imaginable though). However, this requires you to have your site live when you test, whereas installing the browsers on your computer allows you to test offline.

4. Keep an eye out for common errors with specific browsers. The more you test, the better feel you’ll get for the flaws of different browsers. You’ll learn that the default margin on paragraph tags is different in IE than it is in other browsers. You’ll learn that min-height and min-width attributes do not function on IE6. As you come to figure out these flaws, you’ll be able to preempt them by writing clean and efficient CSS. This doesn’t completely eliminate the need to cross-browser test, but it certainly will make the process go a lot quicker.

When I was studying at CMU, I learned the mantra of usability research, “The user is not like me”. It is so true that it’s cliche, but it also applies to web design. You just can’t assume that your users see the same thing as what you see unless you go about finding out how they see it! Different browsers display code differently. Account for all your users or suffer the consequence and lose some of them to layout bugs…

CSS – IE6 Bugs and Hacks

In a few previous posts, I’ve mentioned the all too scary issue of cross browser compatibility. In particular, Internet Explorer seems to always come up, and even more specifically, Internet Explorer 6 (or IE6). There are dozens of bugs that arise with IE6 because of how the browser reads HTML and CSS. I’ve found the best solution when you encounter a problem with how IE6 renders your code, google it. But, to make things easier for some of you, here is a compilation of some of the most serious problems that I have encountered with IE6, and if their is a good hack or fix for it, I’ll tell you about that too.

1. Padding discrepancy:
IE6 and below calculate the width and height of sizable objects differently than other browsers. This issue is easy to demonstrate with the following example of a div’s css:

   width: 100px;
   height: 100px;
   margin: 10px;
   padding: 5px;
   border: solid 2px black;

Normally, this div should be rendered as actually having a width and height of 114px (100px defined width + padding-left of 5px + padding-right of 5px + border-left of 2px + border-right of 2px). Though this might seem counter-intuitive, it actually makes sense when you consider wanting to define space for copy or images, but still have padding with a background color (for example). IE6 and below makes the mistake of still defining the width and height of the div as 100 each, meaning the actual usable space inside the padding and border is now down to only 86 pixels.

There are two fixes to this. One is avoid using padding, and use margin instead (which is not included in the same way that padding and border are) when working with objects with defined width or heights. This is what I tend to do, because it doesn’t require using a hack. However, this is not always possible, especially when you are working with divs that have background colors and text inside. So, the best hack I’ve discovered so far is actually the underscore. Yeah, that’s right, _ does wonders when put immediately before a CSS style definition because every browser except IE6 ignores that line. So what you’d want to fix the above problem is the following CSS:

   width: 100px;
   _width: 114px;
   height: 100px;
   _height: 114px;
   margin: 10px;
   padding: 5px;
   border: solid 2px black;

IE6 will read the first width definition, but then correct it with the second, whereas other browsers will simply skip over the second definition, leaving you with uniform renderings for the div!

2. PNG transparency:
To bring you up to speed, PNGs are far superior to GIFs in every way but one: IE6 displays PNGs with transparency incorrectly. Obviously, there are two fixes yet again. One is avoid using PNGs with transparency and use GIFs when transparency is necessary. I personally do not want to do that because the transparency on PNGs is much better than GIFs (GIF transparency can look rasterized in comparison). The other solution is some handy dandy javascript. There are a lot of these out there. You can check out this one or just google “png fix”. The only issue with these fixes is they often cause problems with background positioning for images. Sadly, you’ll have to live with that bug if you want to fix the first bug…

3. Double margin with floated objects:
Let’s say you have a div that you float to the left for positioning. Then you give it a margin on the right and bottom to give it some space before the next object begins. IE6 has a bug where it will actually double the right margin because the object is being floated. This is incredibly annoying and 100% a bug (as opposed to a discrepancy in how the browser will render something). To fix this evil little bug, add a display: inline style definition inside the floating object. That won’t work 100% of the time, so if it doesn’t work, then use an _margin: definition with half the margin that you defined. For example:

   float: left;
   margin-right: 10px;
   margin-bottom: 10px;
   display: inline; /*This will usually do it and is much easier to apply*/
   _margin-right: 5px; /*This ALWAYS works, but is more tedious and technically not valid*/

As discussed above, the underscore is only read by IE6 and below but will be ignored by other browsers. This should be used when display: inline will actually mess with your layout, or if for whatever reason it does not work properly.

4. Inability to center divs using auto margins
Centering a div is easy unless you are using IE6. Normally, a div with a defined width and a left and right margin setting of “auto”, will automatically center within it’s parent element. However, IE6 doesn’t like that. To fix it, add a simple “text-align: center;” definition to your html and body tags. This of course will center all of your copy, so add a “text-align: left;” to all of your other tags that might contain copy (p, div, h1, h2, h3, a, etc).

Got other bugs? Got other questions? Got other fixes? Post a comment! Also, check out the second installment of IE6 bugs!