Last week we launched a semi-new version of Project83.com, keeping the overall feel but re-working a few pages. As part of the process, we decided to be completely transparent about our pricing. Wow does it feel good to have it out there for people to see.

I've always been extremely frustrated by the fact that creative companies don't talk about pricing. Until recently, I thought everyone was merely too fearful and busy copying each other to actually consider it. While a bit of that still exists, I think the real reason is because of how bids and budgets are usually done.

For example, if a company budgets $20k for a project, they intend to spend it all. In organizations with more than a few people, the person leading the web project typically isn't the one paying for it. So it literally makes no difference to them whether they spend $10k or $20k. They just have to get the project done and might as well spend the entire budget making sure.

As a client, it's very difficult to assess the value of a creative service before it takes place. On paper, someone that charges $20k for a website looks like they provide a much higher quality service than someone that charges less. If I've already got $20k to spend, I'm going with the bid that is closest to $20k, thinking I'm getting the best possible service for my budget.

As someone that provides the service, why would I want to come in LESS than the budget if I'm only going to be penalized for it? If our bid is only $12k then the perception is that our work is not as good.

By not listing any of our prices, we can find out what the budget is for each project and come in right at that price. In the end, bidding right at the budgeted amount gives us the best shot to win the project.

We've lost at least two projects this year because our bid was too low. Since our pricing is available on the website, I can't fudge any numbers to match the budget. Even if we are a much better fit for the project, nine times out of ten we won't get it because the perceived value of our service is lower than the budget. How crazy is that?

Now that you know how the budgets work, why would a company want to show their prices? Here's why we do it:

1. Varying your prices based on a budget figure is dishonest. We choose to be honest, so we have no reason to hide our pricing.
2. A lot of organizations we work with truly appreciate upfront pricing. I believe we'll earn as many (or more) contracts as we lose by talking about money upfront. God forbid we save them thousands of dollars if our bid is lower than the budget.
3. Many of the fixed budget clients are organizations that probably aren't the best fit for us to do business with anyways. It's hard to relate with people that don't like to save money when it makes sense.
4. No one else lists prices, so we set ourselves apart right off the bat.

This is a tough decision all creative companies have to make. I know every project and client is unique, and with that comes customized pricing. However, there is no excuse for not providing general pricing guidelines in public at the very least. That's why I stand firmly on the side of transparency.

The only other company I know of that talks about pricing is Blue Flavor, so kudos to them for stepping out there as well. Is it time for you to re-consider your stance on pricing as well?

In January of last year our team took a little "company retreat" to Las Vegas. Why Vegas? ZAPPOS, of course. The phenomenal online retailer with the best customer service around also does tours at their headquarters and I knew we had to go.

Every second of our day there was a huge WOW factor, from the Zappos-branded Escalade that shuttled us to and from the hotel to the ridiculously friendly folks that work there (some of which we still keep up with). In no way is their culture or way of doing business an act. The people are genuine, the atmosphere is contagious and the methodology works. As a fan of customer service, you can't help but ooh and ahh about how they run the company.

Unfortunately it took nearly 18 months for me to talk about our experience on the blog and post the video we took. Hopefully this provides at least a glimpse into the awesomeness that is a Zappos headquarters tour. Please forgive the awful camera work by yours truly, I will do better next time.

Since our visit, they have formalized the whole tours thing a bit more. I highly recommend that you GO see Zappos for yourself.

Here's me taking a seat on their famous "Royalty Chair" (sorry the photo is scanned):

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.

"Most of the best decisions in my life came after I realized I don't know everything ... the more something feels like something you don't need to know, the better the chances are that it's something you could really benefit from."

— Merlin Mann on The Pipeline

I heard this interview with Merlin Mann recently and his thoughts on curiosity were right on. I haven't experienced enough success in my own mind to start dishing out advice, but I think if successful people have one thing in common it is perpetual curiosity. They explore things they are interested in for the simple sake of learning; not because there's something in it for them. In many cases, their curiosity ends up having a profound impact on their life and/or their business.

Merlin Mann's interest in productivity eventually made him one of the first full-time bloggers on the internet and a very highly-respected geek in many circles. Gary Vaynerchuk's interest in wine made him one of the first and still one of the most successful video bloggers around.

Fact is, you never know where your curiosity will take you. It could mean a new product idea, a new philosophy, a new job or just a new hobby in the long run. The end game frankly doesn't matter. Just never stop learning, because it could be the start of something great down the line.

Apple does a lot of things right. Over the last several years they have made some unpopular decisions that turned out to be good ones. For instance, their refusal to support Flash on the iPhone OS is criticized by many, but it's the right call. Most people know Flash sucks, but up until now no one has had the balls to do something about it.

More recently Apple has been criticized for updating their terms of service to block applications created by 3rd-party frameworks that allow people to write code in another language, then compile it into Objective-C (Apple's native programming language). Again, it's the right call. It may be convenient for some to write Mac and Windows apps in Flash or ASP or Hebrew for that matter, but that's not how it works. Apps should be created in the language they were intended for. It's a ballsy move, but in my opinion it's absolutely the right one.

Now that Android phones outnumber iPhones and Apple has some legitimate competition, it's time Apple makes another bold move: fix the App Store.

What's the Problem?

Great developers have already ditched the iPhone OS by the boatload because of the App Store's flaws. Here are just a few:

1. Developers are 100% at Apple's mercy with regards to the approval process, which has been inconsistent at best. They can't release products, bug fixes or so much as a launch date for their apps because they are restricted to a vague approval timeline controlled by Apple.
2. Marketing efforts are limited because you can't give out promo codes or even 30-day trials
3. It's costly to have a customer refund policy because Apple keeps their 30% cut either way
4. App Store exposure is difficult to say the least and developers have little to no control over marketing their app from within the proprietary store
5. Forget the prospect of measuring conversion and analytics surrounding the sale of your application because you can't even sell it on your own website

Imagine buying OSX apps this way ... what a nightmare! Imagine having to drop by the Apple store just to check out an app you read about, then pay more than you normally would because Apple takes 30%. I believe this process stunts both application developer growth and Apple's growth of the iPhone OS. It may be profitable in the short term for Apple, but could be devastating in the long term.

Solution #1: Make Inclusion Optional

1. Selling your product in the App Store should be optional.
2. Developers need the means to distribute, promote and sell their application however they want. Apple only gets their 30% cut for products sold in their store.

The App Store would still exist as a formidable way to sell your app without having to worry about payment processing or a website. But if some developers prefer do it all on their own, they deserve that opportunity.

Solution #2: Make the Approval Process Optional

Apple's argument against this suggestion is all about security and performance. They want the ability to keep the iPhone OS as secure and bug-free as possible. I totally get that, which is why application approval/certification should still be available to all developers whether they sell their product in the App Store or not.

As a developer, even if I don't want to sell my product in the App Store I should be able to pay a flat fee structure for Apple to review and approve my product just like all the ones in the App Store. Developers that pay the fee get the exact same treatment as App Store products.

While I completely understand the approval process and why it exists, I still believe it should be optional. iPhone users don't lease the devices from Apple, they own them. Therefore it's my right to screw it up with applications Apple doesn't support or approve if I want. Apple could limit the APIs and access in the SDK for unapproved apps, or throw up a big warning before installation; either would be reasonable. I just don't see why this has to be any different from installing an application for OSX.

Solution #3: Ditch iTunes

iTunes was awesome 10 years ago. Since then it's progressively morphed into the slowest, most bloated app on the Mac platform. It makes no sense for iTunes to serve all the purposes it does today. It should be scaled back to the music player/organizer it was always meant to be. Here's how:

• Make the iTunes Store web-based. The irony of Steve's open letter blasting Flash is that he talks about Flash being a proprietary platform. Guess what iTunes is? Proprietary! Thanks to all the great technologies talked about in that letter (HTML5, web standards), the store would lose nothing if they transitioned to a web app. Hopefully that's the direction they are headed by acquiring LaLa.
• Re-work iSync. Apple's iSync used to be pretty good at syncing Macs with other devices. iPhone OS devices should use a dedicated application like iSync to keep all their data in check. Furthermore, developers should be granted access to sync their applications through iSync as well, instead of forcing users to do it over WIFI as a completely separate process.

I could learn to love iTunes again if it just did what it was intended to do and played/organized my music.

In the end I have no problem with the iPhone OS being proprietary. So are OSX and Windows. But I think developers must continue to publicly challenge Apple's unfair practices with regards to the App Store. The iPhone OS will not scale or perform at it's full potential as long as it's constrained by the App Store bubble. When Apple decides to put developers in a position to succeed, they in turn will achieve a greater level of success.

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.

Thanks to my two partners Jared and Denny, I recently joined the masses of early adopters and became a proud iPad owner. Big shocker, I think it's an outstanding device that will change how we do things.

The iPad is so useful in fact that I think that's the biggest problem. It's another device that keeps me in perpetual "connectedness" with all things digital. At what point does this become a detriment to my attention span, productivity and physical well-being? I don't want to be more comfortable working in front of a screen than reading a new book or having an engaging dinner conversation, yet sometimes I feel that way.

This reminds me of a great scene in the movie Wall-E. Remember the spaceship all of the humans are on in the "future"? They are all plugged into these little pods and glued to a screen 24/7. They all get fat, no one uses the swimming pools and no one even talks face to face anymore. It's like they are zombies.

I feel more and more like the zombies in Wall-E every day. I wake up to an iPhone, exercise to a DVD, work in front of a screen 8-12 hours, then come home and regretfully spend at least a couple more hours in front of a screen of some sort.

Of course, this isn't the iPad's fault. I'm responsible for how I spend my time each day. I just find it amazing that technology is at a level where people have to purposefully make time to unplug and do things that are truly worthwhile in life.

Today I'm making a decision to try and unplug for at least 4-6 hours per day. No screens of any sort, except for the Kindle because I can read books on it without being disturbed. On weekends I hope it will be more like 8-10 hours. The iPad rocks, but nothing that creates lasting happiness can be found there.

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.