My first article as an author for Smashing Magazine published today and I'm extremely pleased with it. It's called "Web Development for the iPhone and iPad: Getting Started".

Vitally and the team at Smashing are first class in every way. I'm looking forward to writing more for them if they let me. If you don't already, subscribe to their feed. It's one of the very best for web designers and developers.

If you create websites or web apps for the iPhone OS (iPhone, iPad, iPod Touch), it's important to setup a solid local development environment for testing. Using a desktop web browser (even Safari) or one of the many available "emulators" for testing is worthless because the real thing looks different.

The only way to test properly is with Apple's iPhone Simulator. Since you can't just type a local file path into the simulator, I'll show you step-by-step how to get it working (on a Mac).

What You Need

• Latest version of the iPhone SDK
• MAMP for Mac
• A text editor of your choice ... I love Textmate. You won't have to use Dashcode.

1- Install the SDK (with Xcode) and MAMP

The SDK is about 2.8GB so you should give it a while to download. Installation took about ten minutes for me.

What's MAMP?

MAMP is a great little application that gets you up and running with the local server environment on your Mac in about five minutes. All you need to do is install it like any other application.

2- Setup the location of your website or web app

Create a folder for your project. It can be anywhere on your computer. Place an index.html file in it with "hello world" or whatever you need to test that it's working when we open the simulator.

For this tutorial I'm going to call my folder "iphone-site" and put it in /Users/Nick/Sites/ on my computer.

3- Create an alias in MAMP

Go to the location where you installed MAMP (probably Applications), then open this file: /MAMP/conf/apache/httpd.conf. Around line 655 you should see the following code:

Alias /MAMP "/Applications/MAMP/bin/mamp"

<Directory "/Applications/MAMP/bin/mamp">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

Add a line of space after this code, then create your alias with this code:

Alias /iphone-site/ "/Users/Nick/Sites/iphone-site/"
<Directory "/Users/Nick/Sites/iphone-site/">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

Replace the file path above with the file path to your site in both places.

Save the file and close it. Please note that if you ever make edits to the httpd.conf file while your MAMP server is running, you will have to restart the server to see those changes take effect. Also, if you ever change the location of your site, of course this file will have to be updated with the new file path.

What this does is keep the URL clean and easy to remember. Setting up an alias is not technically required, but I highly recommend it. Instead of the URL being this:

http://localhost:8888/Users/Nick/Sites/iphone-site/

The new, clean URL would look like this:

http://localhost:8888/iphone-site/

4- Test It

Launch MAMP and make sure that the server is running. The window should look like this:

Now it's time to open the iPhone simulator. Open a finder window and navigate to the drive you installed the developer kit on (eg. "Macintosh HD"). The simulator is in the /Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/ folder. It's a good idea to add it to your dock so you can access it easily in the future.

Once the simulator is running, open Safari. Navigate to http://localhost:8888/iphone-site/. Of course you will want to substitute iphone-site in the URL for the name of your project. You should see "hello world" (in very tiny text), which means you are good to go!

Now you can develop iPhone websites and web apps without depending on an internet connection, which should speed up development time significantly. Whenever you start another iPhone project, simply add another alias to your httpd.conf file and get started!

Testing on the iPad

The iPhone OS SDK version 3.2 and up includes support for the iPad in the iPhone Simulator application. It's a little confusing, but think of the iPhone as more of an operating system rather than a device in this context. From the iPhone Simulator, click "Hardware" in the main menu, then "Device" and you can select between the iPhone and iPad.

What about debugging?

Mobile Safari has a debugging console, but I didn't find it too helpful for basic front-end development. There isn't a substitute for Firebug or Safari's developer tools, so I would suggest continuing to use those in a desktop browser if you get stuck. Using the same localhost URL will work in other browsers as well as the simulator.

Resource Library

Once you have your test environment going, it's important to familiarize yourself with the mobile Safari browser and how to make the most of it. Here is a set of articles to get you started:

• Apple: Getting Started with iPhone Web Apps- all of the resources available on this page are very helpful
• Apple: Preparing Your Web Content for iPad- a good basic introduction to formatting web content for the iPad
• jQTouch- in my opinion the best library for developing native-style web apps for the iPhone
• O'Reilly: Building iPhone Apps with HTML, CSS and Javascript- A book that's free to read online and a GREAT resource.

CSS Sprites are a technique made popular back in 2004 by Dave Shea. In short, creating a sprite means combining a bunch of images into one, then using CSS background positioning to display images individually. Built properly, sprites cut down on page weight and minimize http connections required in order to load a web page. Bottom line: it makes things a lot faster.

Still, using sprites isn't all that mainstream because it takes longer to code a website with them, and making regular updates can be tedious without proper planning. For many smaller sites, the benefits simply aren't overwhelming enough to invest the additional time.

If you haven't been using sprites on projects for whatever reason, my hope is that this case study will tip the scales for you.

The website we worked on for the case study is ErgonomicsMadeEasy.com. We created this site a couple of years ago with only one sprite for the navigation. After improving the home page with sprites, image optimization and roughly five hours of time, here are the results we saw:

Highlights

• Total page weight decreased by 270.7k or 42%
• 55% fewer HTTP calls
• Page loaded in 2 seconds, a 70% improvement
• Total number of images decreased by 45 or 62%

Four total sprites come together on this website, three of which were new. The navigation was already a sprite, so it remained the same. Here is a link to see each:

• sprite-icons.png (10.1k, 15 total images)
• nav_bg.png (21.4k, 3 total images)
• sprite-tabs.png (2.4k, 2 total images)
• sprite-footer.png (4.8k, 5 total images)

Why four sprites and not one big one? Two reasons:

1. When optimizing images for minimum file size as a PNG-8, the image quality deteriorates with more color diversity.

2. Big huge sprites are typically very hard to maintain.

Non-sprite optimization

As part of this project I also did two other things not related to sprites that made a nice dent in the overall file size on the home page:

1. I highly recommend saving any JPG images with Adobe Fireworks CS4. Don't ask me why, but the process is completely different from how Photoshop saves JPGs for web. It's quite common to save 20% or more in file size by using Fireworks over Photoshop. However, I still use Photoshop for PNGs.

2. I noticed about ten background images that were being loaded on the home page through the stylesheet, which were only necessary on category pages. So I took that CSS code and put it in a separate stylesheet that is only loaded on categories. If you have large background images being referenced in your stylesheets that are only necessary on a couple of templates, I recommend putting them in a different stylesheet and only calling it when they are needed.

What Now?

These numbers should be proof enough that sprites play a crucial role in maintaining a fast website. Not only that, but running your own tests and optimizing is important before launching a site.

It takes time to understand the right uses for sprites, but the only way to learn is to work with them. Here is a collection of my favorite articles on creating sprites:

• A List Apart: CSS Sprites: Image Slicing's Kiss of Death (where it all started)
• Smashing Magazine: The Mystery Of CSS Sprites: Techniques, Tools And Tutorials
• CSS Globe: Creating easy and useful CSS Sprites
• mezzoblue: Sprite Optimization
• Tutorial9: Building Faster Websites with CSS Sprites

Lastly, I don't recommend any auto-magic sprite generators because they don't account for some important criteria like images that repeat or may not have a defined width/height. Create/code your sprites from scratch and I believe you will get much better results in most cases.

Part of your website development process should include coding and testing a print stylesheet. One thing that took me a long time to figure out is how to properly insert a logo at the top of the page. The technique is very easy.

Two things are tricky about printer-friendly logos:

1. Logos are typically background images and print stylesheets don't print background images
2. Often times the logo is over a colored background, which you don't want on white paper, so you need to specify a different image for printing

The code I use will work every time, no matter what the website looks like in a browser. Start with the following at the top of your layout in the main container:

<img src="/images/print-logo.png" alt="Website/Company Name" 
id="printLogo" />

Your main stylesheet should have the following:

#printLogo {
	display:none;
}

Your print stylesheet should have the following:

#printLogo {
	display:block;
}

Easy, right? For the longest time I was looking for a way to do this without adding an image to the top of the layout, but I've found this to be the most consistent, reliable method.

A nice looking print stylesheet is a huge wow-factor; especially when you have taken the time to add the logo to the top. Here are a few examples of sites we have done that have the two different logos:

Building on the momentum from my last post, it's a perfect time to talk about when it's okay for web designers to drop support for IE6. Of course WE want it, but I don't believe designers and developers get to make this call when they choose. Lots of prominent designers disagree with me, but I don't think it's up to us to decide.

Fact is, studies show that most people still using IE6 don't have a choice to upgrade. As of May 2009, 60% of companies still use IE6 as their default browser. That's something we are compelled to take into account.

In recent memory we've seen popular web apps like 37signals apps, Apple's MobileMe, Google Apps and YouTube stop support for this browser. Since these apps cater to a more computer savvy audience, I believe it's makes complete sense for them. However, it doesn't provide just cause for people that build public websites to stop supporting it without more research. I don't believe Apple.com will stop optimizing for IE6 anytime soon if it means they can sell more Macs.

I did a quick survey of a bunch of our clients. I saw anywhere from 5-15% of users to our client websites are still using IE6. That's too high for me, so we're going to keep supporting it. Until that percentage creeps to roughly 3% or lower, I believe it's our obligation to make sure it works.

"Making it work" can mean a number of things. I don't think websites have to look exactly the same in IE6 as they do in modern web browsers. We geeks call this progressive enhancement, but as long as the website is still functional and degrades gracefully I have no issue with it.

A slightly more aggressive approach is being taken by the creators of IE6nomore.com, which I find pretty interesting. They have created some really simple code people can add to their website, which shows a banner like this to any IE6 visitors:

That's a pretty cool idea!

No matter what, if you do choose to drop support for IE6 make sure you are doing it for the right reasons. Doing it out of frustration, laziness or indifference isn't the best way to communicate expertise to clients and potential clients.

By far the most difficult thing to master when learning to code with web standards is browser optimization. It seems like every layout presents a different challenge than the last one. It's taken me years to figure out pretty much every bug Internet Explorer can throw my way, but I still struggle from time to time.

Part of coping with Internet Explorer (versions 6 and 7 in particular) means having some nifty tricks that can help you in a pinch. Some of my tricks aren't very well publicized, so I'm posting them here in hopes of saving at least one person from taking their frustration out on their innocent laptop, wife or dog.

Target IE6 or IE7 with a single character

A quick way to set a specific style that applies only to IE6 or IE7 without the use of conditional comments or javascript is to try the following simple syntax in your stylesheet. Just add a simple asterisk or underscore before the property:

#someElement {     
	background: red; /* modern browsers */     
	*background: green; /* IE 7 and below */     
	_background: yellow; /* IE6 exclusively */  
}  

Credit: NetTuts.com- http://bit.ly/8TIJSs

Using text-indent on an input in IE6

If you use image sprites (which I highly recommend), you are likely to run into this problem. The text-indent property does not work on an input. So you may get an image that looks like this:

Instead of hiding the text and replacing it with an image, both show up in IE6. The following three lines must be added to your IE stylesheet for the input in question to fix the problem:

display:block;
font-size: 0px;
line-height: 0px;

Usually the display:block property is unnecessary if you are using a sprite or image replacement technique to replace the text (because it's already a block level element).

Credit: ProductiveDreams.com- http://bit.ly/12YKXi

IE8 Rendering Modes

In typical Microsoft fashion, they actually present you with a bunch of rendering mode options in Internet Explorer 8 instead of just doing it the right way all of the time. So if you write code properly and it validates, you will want to add the following meta tag to the <head> ALL of your layouts moving forward:

<meta http-equiv="X-UA-Compatible" content="IE=8" />	

This tag enables the IE8 standards compliance mode on your website, which you would think should be active all the time.

Credit: Zurb.com- http://bit.ly/4RGzk

CSS Browser Selector

When all else fails, I use an amazing 1.1k javascript file called CSS browser selector. This script lets you code styles for tons of different technical configurations. You can set attributes by operating system, browser and browser version. It also cleverly adds a "js" class when javascript is enabled so that you can set styles up for when it is disabled. Pure awesomeness ...

Credit: http://rafael.adm.br/css_browser_selector/

The Alpha-transparent PNG Paradox

One super-annoying issue with IE6 is that it doesn't know how to read alpha-transparent images properly. So if you have an image with a shadow over a transparent background or something with an opacity less than 100%, chances are it won't look so hot in IE6.

This isn't an easy fix. There are a number of recipes that cover different situations. Frankly, we try to avoid all of them if we can and simply use different images in IE6 that don't have alpha-transparency. It doesn't look as cool, but that's what they get for using a crappy browser. Here are the best solutions I know about:

• Unit PNG Fix (lightweight, my favorite right now)
• Supersleight (doesn't work for background images)
• DD_belatedPNG (I haven't used before, but it seems very solid)

A few weeks ago, the Google Analytics team released some fantastic updates to their software. Of particular interest to me was enhanced mobile tracking and reporting capabilities.

The first thing to understand about mobile website reporting is that it works differently than regular websites. Many mobile browsers do not yet support javascript, the language that platforms like Analytics depend on to track website stats. Instead of the browser doing the work, mobile tracking leans on some server-side code to track visitors properly.

Don't be intimidated by all the geek-speak though. It's not rocket science to implement analytics on your mobile site. If you've got five minutes, know how to use FTP and don't mind copy/pasting some code, you can do this!

1. Add a new profile

From your Google Analytics account, add your mobile site as a new domain.

2. Get advanced tracking code

Once your site is added, Analytics will give you a Web Property ID like normal. Keep this around for future reference. In the example below, the Property ID is highlighted.

Click on the "Advanced" tab under the instructions heading. Then click on the radio button to select "A site built for a mobile phone". Finally, select the server-side language. I will be using PHP for this example.

3. Insert the snippets

There are two snippets of code that you must copy/paste onto each page of your mobile website. One goes at the top of each page, right after the <html> tag. The other goes at the bottom of each page, prior to the </body> tag.

Note that the third line of the top snippet includes your Web Property ID. This varies for each domain, so be sure to change it if you ever re-use this code.

4. Upload the file

Lastly, you have to download this file called "ga.php" and upload it to the root directory your domain. This means if your domain is m.yourdomain.com, this file needs to be at m.yourdomain.com/ga.php.

5. Test and Celebrate!

Give it a few minutes and refresh the tracking status in Google Analytics. Assuming you followed the directions, you should be in great shape.

Known Limitations

Lastly, it's important to familiarize yourself with the currently known issues, published by Google in the sample code instructions:

• Multiple instances- you can't run multiple copies of the script on your website, or use it in conjunction with the standard javascript tracking code.
• Inaccurate locations- Since Google determines users' location using their IP address, tracking this from a mobile device is not as accurate.
• Server load- Due to the additional code required to track visitors properly, additional server load may be possible.