Today I get to make a bittersweet announcement. Project83 is no longer taking on new clients. After more than five years in business, we are closing up shop on our terms.

Running a client services business has been one of the single best experiences of my life. It's been challenging, rewarding and educational. I'm proud of what we accomplished. My only complaint is that we've spent our days (and nights) working on things that aren't ours. We never have the opportunity to own something, see it through and reap the benefits.

Our creative outlet for the last three years is a company called Brightwurks. We built a product called Feed My Inbox for fun and it actually turned into a legitimate business, 175,000 customers and growing. It's been a nice little side project to keep our creative juices flowing.

Our second project called Help Scout is attempting to solve a very challenging problem: email for teams. We're making it easy for groups of two or more to easily collaborate on email. It's perfect for customer service, following up on leads or any number of scenarios.

We've been presented with some fantastic opportunities for Help Scout in the last few months, so we're going to make the most of them. As much as we enjoy working on client projects, having a chance to build something that's ours is a dream come true.

If you are reading this as a Project83 client, you will receive a personal email within 24 hours. We will continue to support all our current clients until they choose to move onwards. A trusted member of our team will be dedicated to keeping up with day-to-day support, but we most likely won't take on any new projects.

Most of our blogging will now take place on the Brightwurks Blog, so please keep in touch with us there. It's been a great run!

Good web designers understand that quality content is what distinguishes a website and triggers desired results. Design plays an important role, but it always follows the content. The better quality the content, the more we can do visually to emphasize it within a design, which is why we always require finished content before designing a page.

Not many people like to talk about content because it’s really hard and few consider themselves “a good writer”. In an age when more of our communication is in writing than at any other time in history, it’s crucial that we all learn to be writers. We all appreciate good writing, whether sub-consciously or not.

Writing good copy for the web is different, because users “scan” web pages rather than read them from top to bottom. Most users are looking for something, so they scan quickly until they find it. 

Here are some tips on how to write “scannable” web content that performs better on the web:

1. Keep paragraphs short and sweet. Each paragraph should be no longer than 3-5 sentences.
2. Write like you have to pay by the word. Users won’t read every word, so don’t waste any. This is not the place to be verbose. Get to the point and be as clear as possible. Make it a game if you have to. How can I cut this paragraph in half and make it even more clear?
3. Use bullet and numbered lists. Lists are very scannable and they usually signify important content the reader is interested in. Use this to your advantage, just like I am in this article.
4. Pepper with Headings. Every 2-4 paragraphs needs a heading to tell the reader what the content is about. If the page has 500 words or more, there should be several headings throughout so that the reader can easily comb through the page.
5. Emphasize whenever possible. Bold and italics are great ways to set aside important content without breaking up a paragraph. It’s a great way to point readers to the most important points.

Book Recommendations

There are some great books available if you are interested in writing better quality web content. My favorite so far is Killer Web Content by Gerry McGovern. For a classic dedicated to writing better in general, try On Writing Well by William Zinsser.

Dropbox is the most important application I use because it keeps all my files in the cloud, syncs them across devices, shares them with my team and backs them up. It's spoiled me, because now I expect all my applications to be in sync no matter what computer I use.

The problem with native software (as opposed to web-based software) is that your data is stored locally. If I use an app for an hour on my desktop then pop open my laptop, I can't expect to open the same app and see all the data I just worked on because it's a different computer.

Several applications circumvent this problem by syncing your data with Dropbox or another online source. 1Password and Things are good examples of Dropbox support, while an app like Evernote syncs your data with it's own servers.

For apps that don't have a way to sync your data, there is a slightly less perfect (see below) solution at your disposal. It's worth trying if you don't have another way to keep things in sync.

In this example we're going to sync the Address Book application, so that your contacts are available on any computer you have setup with Dropbox. The same steps are involved in syncing most any other Mac app also.

Step One

Close the application you want to sync. Then click on your home folder and navigate to Library/Application Support/. Drag the AddressBook folder into your Dropbox. You can put the folder anywhere.

Step Two

Open the Terminal application. Type in:

cd ~/Library/Application Support/	

This just tells Terminal to "change directory" and navigate to the Application Support folder we were just in.

Step Three

We're creating a "symlink", aka a symbolic link. It's sort of like creating an alias in OSX, but an alias won't solve our problem in this case.

Now type this code in Terminal:

ln -s ~/Dropbox/AddressBook .

This creates a symlink permanently connecting the AddressBook folder in your Dropbox with the AddressBook folder in your Application Settings.

Step Four

Test your symlink by navigating to Library/Application Support/Address Book in the finder. If you see the files, your symlink worked!

Now your Address Book is being synced with Dropbox! The only thing you have to remember now is to not open the application on another computer until your Dropbox has finished syncing. Opening the app before it syncs can sort of blow everything up, which is what makes this solution shaky.

Deleting a Symlink

Keep in mind the actual files are now being stored in Dropbox. The AddresBook folder in Application Support simply points to those same files. So if you want to undo everything we just did, you can delete the AddressBook folder in your Application Support folder. Then move AddressBook from your Dropbox back to it's original location in Application Support.

I use this solution to sync applications like Billings or even my iTunes music library. Hopefully it can help if you use multiple computers. Rest assured that in "the future" stuff like this will get much easier as software becomes more web-connected.

One tool every front-end developer should be using is a solid template or framework for new projects. "Frameworks" in general have gotten a bad reputation for being bloated with unnecessary code and classes just to save a few minutes. I don't use any layout or CSS frameworks precisely for those reasons. However, creating an HTML framework that is customized to your own coding style and tastes, while leveraging the latest technologies is definitely worth considering.

The goal of a framework is to set a foundation for new projects so you can hit the ground running. It should include elements and styles that you use for most projects, but the key is to not waste any lines of code. As a general rule, I only include code in my framework if I use it in 80-90% of my projects. If not, I cut it out to make sure I'm not wasting valuable kilobytes.

There are currently two open source HTML5 frameworks: HTML5 Boilerplate and HTML5 Reset. I think both are very solid and worth checking out when you create or update your framework. The problem is that I don't believe there is a "one size fits all" solution for this stuff. Every developer has their own style and preferences, so in the end you should build a framework that suits you. Hopefully this article will give you a good foundation of resources, code and advice to get going.

Can we use HTML5 yet?

Whether to use HTML5 or not should be assessed on a case-by-case basis. I'm using it in client projects unless over 2% of the visitors have javascript disabled, which means I am using it in almost all new projects. HTML5 is already very well supported by modern browsers and it is simple to bring old ones up to date with a small amount of javascript. Richard Clark and Remy Sharp put together a really good article summarizing the positives and negatives of HTML5 on HTML5doctor.com, called "How to use HTML5 in your client work right now". It's a very good read.

While CSS3 is a bit more complex with regards to browser support and new syntax, HTML5 is straightforward and easier to pick up. Adding HTML5 support to your project involves one line of CSS:

section, article, header, footer, nav, aside, hgroup { display:block; }

Of course, Internet Explorer isn't exactly what we would call "modern". It requires a 4kb javascript file called html5shiv, created by Remy Sharp. I have seen estimates that put javascript adoption above 99% at this point, so it's safe for most projects to depend on a small javascript file for proper rendering in IE.

If it's learning HTML5 you are hesitant about, fear not! Anyone that has a good understanding of HTML4 should be able to pickup the new HTML5 elements in 2-3 hours. Here are a few resources I used to get up to speed:

• HTML5 for Web Designers by Jeremy Keith - I LOVED this book. It's a great desk reference.
• html5doctor.com - A great all-in-one resource
• HTML5 and the Future of the Web - Another great intro to HTML5 here on Smashing Magazine

Code Cleanup

Whether you choose to use HTML5 elements in your framework/projects or not, much of the code in your framework can be still cleaned up, especially in the <head>. Take a look at how we can clean up the DOCTYPE declaration:

Before:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" 
"http://www.w3.org/TR/html4/strict.dtd">

After:

<!DOCTYPE html>

The only downside of updating your doctype is that validation is a bit more difficult. The W3C validator now includes "experimental support" for HTML5 ... it's just not full proof yet.

Another nice little change is that the "type=" attribute is no longer necessary. Here are a couple of examples:

Before

<script type="text/javascript" src="js/script.js"></script>
<link type="text/css" rel="stylesheet" media="screen, projection" 
href="css/styles.css" />

After

<script src="js/script.js"></script>
<link rel="stylesheet" media="screen, projection" href="css/styles.css">

You can update the DOCTYPE and lose the type attribute now, as all common browsers support these changes (including Internet Explorer 6). View source on the Google home page and you will see that even they are following both of these rules.

Meta Tags

Must-haves

<meta charset="utf-8">
<meta name="description" content="">
<meta http-equiv="X-UA-Compatible" content="IE=8">

The first two lines are straightforward and don't require any explanation. The third line forces "standards mode" in Internet Explorer 8. I find it hilarious and somewhat sad that Microsoft let users choose whether they wanted to render pages properly or not in IE8, but at least we have a way to force standards support.

HTML5 Boilerplate stretches IE a little further and forces support for the very latest IE rendering engine with the following code:

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

I'm with Aaron Gustafson and his article, "Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8". He says that using IE=edge is risky. There's no way for us to predict IE's next move and I would prefer it not breaking any of my sites. Still, this is something worth your consideration.

Optional

<meta name="robots" content="index, follow">
<meta name="keywords" content="">
<meta name="author" content="">
<meta name="Copyright" content="(c) 2010. All Rights Reserved.">
<meta name="viewport" content="width=device-width; initial-scale=1.0; 
maximum-scale=1.0;">

Keywords: I want to touch on keywords and why they are now an optional meta tag. For search engine optimization purposes, keywords are practically useless because they are far too easy to manipulate. None of the major search engines consider them for this reason. The only reason to include them now is if you have a site search that uses meta keywords to assist with indexing.

Viewport: Apple introduced the viewport meta tag for mobile Safari on iOS devices. Setting the scale at 1.0 prevents the user from zooming or scaling the site, so it should only be used if your site is optimized for mobile devices. However, now that Mobile Firefox (aka Fennec) and Android WebKit support the tag as well, it could get tricky as devices differ in screen resolution. If you are optimizing for mobile, the best practice at this point is to use the tag and test it as thoroughly as possible across different browsers.

There are still many other optional meta tags, but none seem common enough to include in a framework. I found it interesting that HTML5Reset has DC (Dublin Core) meta tags in their framework even though major search engines are not recognizing it yet. I'm not willing to go there yet.

Javascript

Browser Selector

Browser Selector is a very useful 1 kb javascript file I use on some projects, but it's not yet included in any HTML5 frameworks. The script started as an idea by 37signals back in 2006. Within a couple of days there was a working version. Browser Selector adds classes to the <body> tag that define the user's operating system, browser, javascript support and in most cases, browser version. Using the script, you can target users on virtually any specific platform and create styles uniquely for them. I comment this script out by default, but it can come in handy every so often.

When there's only a need to optimize for Internet Explorer, Paul Irish has a nice solution for using conditional comments to isolate different versions without the use of javascript. However, in most cases I prefer browser selector because of how flexible and expansive it is.

Modernizer

Modernizer is a popular 5 kb javascript file that uses some of the same awesomeness that Browser Selector does. Instead of targeting specific platforms though, it detects the platform's level of support for CSS3/HTML5 elements. For instance, if the browser supports border-radius, a class of "borderradius" will be added to the body tag. If it does not, a class of "no-borderradius" is added. This way you can create specific styles for each case.

An added bonus of Modernizr is that it adds support for the new HTML5 elements, thus eliminating the need for html5shiv. For a great tutorial on using Modernizr, check out this A List Apart article.

DD_belatedPNG

There are several scripts and solutions available for adding alpha-transparent PNG support to IE6. I think DD_belatedPNG is by far the best, easiest to implement and most flexible. The compressed file is only 7 kb.

Not every project needs to support alpha-transparent PNGs in IE6, but this is a great solution to have on hand when it is required. When building your framework, this is the kind of script you can comment out by default and activate when necessary. Just be sure to read through the known issues before getting started.

Google Analytics

I know including this script is a bit obvious for analytics users, but I mention it so that your framework has the latest version of the Google asynchronous tracking code. Google says the optimal position for the code is on the bottom of the <head>, after any other scripts have been loaded, so that's where I like to keep it.

Stylesheets

One thing to keep in mind that some HTML/CSS frameworks have forgotten is that each stylesheet is another HTTP connection the browser has to make when loading the page. Don't load five or six stylesheets on every page just because you are a neat freak, because it slows everything down.

One to three stylesheets is enough for most projects. I like to have one stylesheet with default framework styles that are re-used on each project, then one stylesheet with styles that are all specific to the project. Here are some good tips:

Browser Reset

The godfather Eric Meyer gave us Reset CSS in order to put all browsers on a level playing field. More recently Richard Clark gave us the HTML5 Reset Stylesheet. The only thing I don't like about Richard's version is that he goes a little further than doing a browser reset. Adding any colors, borders or text styles should not be included in a reset, but that's just my opinion. Study these two in order to define your own reset styles.

Clear Fix

Another snippet of code that is a great addition to most default stylesheets is the clearfix, which most of you are familiar with using. Simply add the class to any div containing floats to clear them properly. For a more detailed explanation, Position is Everything has a nice article on it. Here is the syntax I use:

.clear { display: inline-block; }   
.clear:after, .container:after { content: "."; display: block; height: 0; 
clear: both; visibility: hidden; }
* html .clear { height: 1%; }
.clear { display: block; }		

Default Styles

I found a few different resources to be helpful in creating default styles over the years. The first is Blueprint CSS. Some of the text and form styles in their screen.css file are great, but I don't use anything else because it's too much to include in a framework. The second helpful resource is HTML5 Boilerplate. Some of the styles included in the style.css file are really useful ... kudos to that team. I have tweaked the classes to my liking but, here are a few of my favorites:

.hide { display:none; visibility:hidden; } /* hide from browser & screenreader */
.browserHide { position:absolute !important; clip: rect(1px 1px 1px 1px); 
clip: rect(1px, 1px, 1px, 1px); } /* hide from browser, not screenreader */
.inv { visibility: hidden; } /* hide from screenreader, not browser */		

h1,h2,h3,h4,h5,h6 { text-rendering: optimizeLegibility; }
html { -webkit-font-smoothing: antialiased; }

.replace { display:block; text-indent:-9000px; overflow:hidden; } 
/* for image replacement */

My final source of inspiration for default styles is personal experience. I regularly review my default styles, deleting code that is used in less than 80-90% of my projects. It keeps the styles from getting bloated, as page load time is always priority one in my opinion.

Print Styles

Like many people, my first print stylesheet was based off Eric Meyer's 2001 article called, "Going to Print". It serves as a nice introduction, but more recently I started implementing an open source print framework called Hartija. With some minor modifications, those styles have served my projects well for quite a while now.

One unfortunate thing about print stylesheets is that they are loaded whether the media is set as print or not. So in many cases, it's an extra HTTP connection that is not necessary to render the web page. In other words, it wastes precious page load time. I learned a solution on Stoyan Stefanov's blog (in the comments), which has now been implemented as part of HTML5 Boilerplate too. Simply add your print styles to the default stylesheet like so:

@media print { ... styles here ... }

By using the media declaration instead of a separate file, the styles don't require another HTTP connection and are still loaded when users print the page.

Other Elements

Favicon and Webclip

<link rel="shortcut icon" href="images/favicon.ico">
<link rel="apple-touch-icon" href="images/webclip.png">

Two must-have links as part of your framework are the favicon and the webclip icon. The favicon is a mainstay, so we won't cover that. Webclip icons are specifically for iOS devices. They appear when someone saves your website to their home screen. The dimensions are now 114x114 thanks to the new high-resolution iPhone4 retina display.

Print Logo

Another strategy I've blogged about before that has not yet made it to the public frameworks is printer-friendly logos. Having the company logo show up on printed pages is a nice wow-factor that most coders seem to ignore.

The company logo is usually a background image on standards-compliant websites, but background images don't show up on printed pages. The solution isn't innovative or sexy, but it works really well.

1. At the top of your wrapper, add the printer-friendly logo as a static image, giving it a unique ID like so:

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

2. In your main stylesheet, make sure to set the following styles:

   #print-logo { display:none; visibility:hidden; }

3. Now in the print stylesheet or separate print styles, set the following and the logo will print beautifully:

   #printLogo { display:block; }

Images Folder

One final strategy that works really well for a framework is organizing your images folder properly. I like the idea of setting up two sub-folders, called "content" and "temp". Any temporary or placeholder images from the mockups should be stored in the temp folder so it can easily be emptied at a later date. Images that are part of the website content should be stored in a separate folder in case the website is ever re-designed. Then you know to keep images in the content directory and all others can be replaced with the new design.

My Framework

It's only fair to do all of this talking about frameworks if I make mine available for download, so you can download it here and use it however you like.

As a whole, my framework does less than what is out there. HTML5 Boilerplate and HTML5Reset both go a little further than I'm willing to, but that's totally fine. For example, they both include jQuery, whereas I'd prefer to include it on a case-by-case basis. HTML5 Boilerplate even includes an .htaccess file, which is very cool, but not for me because those things tend to vary for my projects.

Otherwise there's nothing special about my framework other than the fact that I've created it to suit my style and needs perfectly. That's exactly what I'm encouraging you to do.

HTML5 frameworks can only exist as a result of web developers sharing their ideas and code with others. Each framework is the result of many, many smart people sharing their ideas with the web community. It's up to you to take these great resources, make them your own and eventually contribute cool things to add back to the community as your framework improves.

Finally, it is inevitable that some great resources and ideas have been left out of this article, so I encourage you to contribute what you know in the comments or to an existing framework so that everyone can benefit.

Tomorrow I have the opportunity to speak at the Next BIG Nashville + Leadership Music Digital Summit event in Nashville. It's basically a conference and music festival rolled into one, like South by Southwest on a smaller scale.

I'll be talking for 20 minutes about making users happy, since that's what I'm most passionate about in our business. Please come check it out if you are around!

Venue: Curb Events Center, 2002 Belmont Blvd, Nashville, TN 37212
Time: 12:10pm - 12:30pm
Panel Name: The Site Doctor is in
More Info: http://www.nbnsummit.com

I am currently on vacation in Greece, pondering customer service as I often do. It's fascinating to be in a foreign country observing how all the different hotels, restaurants and shops value customer service. No one does over-the-top customer service like many (certainly not all) companies in the United States, but still we've had great experiences almost everywhere we have been.

In my opinion, one single principle exists in every great service experience. Once mastered, it can have an extraordinary impact on your personal and professional life, no matter what business you are in. It consists of remembering four simple words: don't pass the buck.

Passing the buck comes in two important forms. Firstly, it is a lack of responsibility when something goes wrong. In these situations, you have a choice to own it or pass the buck. Owning it means not making any excuses, taking responsibility even when it's not your fault, giving a heartfelt apology and making the situation right to the best of your ability. Passing the buck usually involves blaming someone else and convincing yourself there was nothing you could do.

A few days ago I experienced a great example, when I passed the buck and our hotel manager owned it. We decided to walk to a nearby winery, a mere 2 kilometers away from our hotel. I took a map that was provided by the hotel and we were on our way. We ended up getting lost and ultimately found out the map was wrong.

With my male ego and directional pride fully in tact, I got really frustrated blaming the map for about 45 minutes. I was making excuses, when I could have devoted my energy to asking the hotel for directions before we left, calling the winery for directions or verifying the directions with another map. Even though the one map was wrong, I'm still responsible for choosing it and not double-checking. I had to eventually make it right with my wife for leading her in the wrong direction.

On the other hand, our hotel manager handled the situation beautifully. She apologized profusely for the map, even though she didn't create it or have anything do to with it. She said it was her fault for putting out the map and that she would call the people that made it immediately. She also made it right by giving us a ride in her own car down to the winery. I was humbled.

The second form of passing the buck is much more common, because something doesn't have to go wrong for it to happen. Many people do it several times per day without even noticing, by delegating to others. In some cases delegation is appropriate, but it's usually not necessary. If you choose to go out of your way and sometimes beyond your job description to help someone out, you can usually provide an outstanding experience without passing the buck.

A simple example we have all seen is when you are deciding on a place to eat with someone. "Where should we eat?", someone says to you. You respond with, "I don't know, what do you think?". Wrong answer. That answer passes the buck without providing any help at all. When someone asks that question, the right answer is to respond with a single restaurant or choice of restaurants. Own it.

One we typically see at Project83 is when a customer emails me saying that someone saw a problem on one of their website pages. The typical, pass the buck answer (I'm guilty of it) is to respond and ask for the browser name and version. It delegates the responsibility to someone else. Sometimes this information really is required, but in many cases you can check yourself. Test the page in every browser and version on your own. It takes more time, but in the end it provides the customer with a MUCH better experience, saving them time and resolving the situation in a single email.

These are simple examples, but I see people pass the buck every day and it's bad customer service, whether you think of it that way or not. Taking ownership means being responsible to make the very most of your interaction with someone, resolving the situation in the shortest amount of time possible. Anything less is passing the buck.

I encourage you to be mindful of passing the buck in your interactions over the next week. It's an awesome feeling for you and whomever you are dealing with when you own it.

I think about customer service all the time. It's become a legitimate obsession of mine over the years. I love hearing great stories of customer service, learning from companies that value it, criticizing companies that suck at it and trying to build businesses that stand out as a result of it.

The ultimate challenge for a customer service aficionado is running  a creative, client-based business. It's truly a marathon. Great customer service is defined not by one or two interactions, but by month after month of consistent communication, met deadlines and work that exceeds expectations.

Like many small web design companies, we depend solely on happy customers. We don't spend any dollars marketing our services; it's all based on referrals. The company literally sinks or swims based on the quality of our customer service. Despite innumerable mistakes and learning experiences, we're still quite successful today because our team spends a lot of time polishing our customer service skills.

Aside from every-day communication, here are 5 things we pro-actively work on to deliver a WOW experience to clients:

Proposals

I believe proposals are an awesome way to deliver WOW, which is why we constantly refine the copy and design of our proposals. The template goes through at least 2-3 major revisions per year. The biggest factor is working to make each proposal unique. Clients can smell a boilerplate proposal from a mile away, so be sure to personalize it.

Also keep in mind that the client will probably not read every word of the proposal. They will scan it and follow-up with questions. So don't get mixed up in creating an extremely detailed scope or including fine print that should be meant for the contract. Simply provide an overview, find creative ways to be memorable and leave them wanting more.

Handwritten Notes

I'm a big fan of handwritten notes and their ability to really create a WOW moment. Most every potential client we deal with gets a handwritten note at some point during the process; even the ones that say no. If the client uses someone else for the project, a handwritten note virtually guarantees they will consider you for work in the future.

Our notes are beautiful letterpress cards and envelopes. We think it's a true WOW to get one of these babies in the mail. Even if the client doesn't acknowledge or thank you for the note, it is still something they don't soon forget.

Professional Comps

Another WOW moment you can create with clients is in how you deliver design comps. Rather than simply attaching them in an email, putting them in a PDF or linking to straight JPGs, we've created a little PHP script that presents them in a really cool way.

Each page is branded with the company name and date. Each comp has a section for people to leave comments on the bottom. We like it so much that we're hoping to open-source the project at some point in the near future so others can use it as well. Until then, here's a little sample of our comp viewer ...

Do a Little Extra

Proper budgeting for a project means including enough padding to account for anything that may go wrong or drag out further than expected. In times when the project goes off without a hitch, it's an opportunity to do a little extra.

"Extra" simply means going over and above what you originally agreed to do. It could mean a couple hours of updates free of charge after launch or an extra round of design changes after the fact. Maybe it means adding a requested feature to their CMS that wasn't in the original scope.

Instead of getting greedy or stingy with a project budget, make sure you use padding to go the extra mile whenever possible. The client will clearly notice when you go over and above the call of duty. If they don't notice, make sure you let them know you are!

Celebrate

Some of our best memories have been celebrating with clients after a project. If they are local we often provide a pizza lunch or bring the whole team by for something fun. For out-of-town clients we have tried a variety of things, most recently sending Nashville's famous Christie Cookies their way.

Often times the method of celebration depends on the client, but it does require thought and planning. It's an awesome way to clear away any tensions that may have developed over the course of the project and express your gratitude in person for their business and continued partnership in the future.

So those are some things we're proud of. What's the coolest customer service interaction you have had in the last six months and why?

PS - I love customer service so much that we're even building a web app to help people manage customer service over email better. You can follow our progress on the app here.

Being the business junkie that I am, one of my favorite things to do is read company stories. Large or small, my favorite companies value their culture and cultivate it in unique ways.

I'm going to share culture stories from time to time on this blog because I think we can all be encouraged and inspired by them. Our trip to Zappos was the first one I talked about. Culture is not a buzz word to these companies; they live and breathe it.

First up ... Southwest Airlines.

I've been reading a book called Nuts: Southwest Airlines' Crazy Recipe for Business and Personal Success. It's a great history of the early days and talks at great length about the culture they built over the years. One particular thing I'm fascinated by is how they hire people.

How Southwest Airlines Hires

In 1995 (the book was published in '96), the Southwest Airlines People Department (they don't do HR, just people) received 124,000 applications and only hired about 5,400 folks. Guess what the #1 criteria is? Sense of humor.

Founder Herb Kelleher says, "We look for attitudes; people with a sense of humor who don't take themselves too seriously. We'll train you on whatever it is you have to do, but the one thing Southwest cannot change in people is inherent attitudes."

How would you answer if someone posed the following question in an interview? "Tell me how you recently used your sense of humor in a work environment." If you don't know the answer, I wouldn't suggest applying at Southwest Airlines.

In what very little experience I have hiring people, it's not surprising Southwest hires for personality first. Although our industry in particular requires technical expertise, it's not worth hiring someone unless they have a personality that compliments everyone else.

Now you know why the most memorable flight attendant you've ever encountered was most likely on a Southwest flight. I know mine was.

Ever wondered what the difference is between a logo, identity and brand? Maybe you've just wanted to impress all your friends at parties with your intimate knowledge of all things visual. Either way, our resident logo guru Kevin Burr is here to bestow some wisdom for us.

Kevin designs logos and websites at Project83 along with our team.

Logo

Out of the three, the term logo is the easiest to understand. A logo is a symbol or font based design, also known as a logotype, that represents a company or service. The logo works much like a signature. It can be a mark like the Nike tick or a purely type driven logo like FedEx.

Logo Examples

Identity

The identity is more global. It influences how an individual feels about a company through visual consistency across various mediums. For example, color schemes, stationery, photo styles, font styles, logo guidelines (i.e. spacing, sizing, reproduction) and grid systems all take part in defining the company's identity.

Identity Examples

• Business cards, stationary and print collateral
• Style guides, including approved colors, typography and logo usage
• Product packaging

Brand

Think of the brand as something less tangible. A brand can't be designed or created. It's the collective perception one builds about a company based on the logo, identity, goods or services provided and also their experiences with the company. Brand value is built over time in the minds of your customers.

Brand Examples

• Zappos: synonymous with great customer service
• Crate & Barrel: modern furniture and clean design
• BP: big oil company that prioritizes profits over safety and the environment
• Starbucks: good coffee that's always around the corner

While Project83 is where we do client business, our same team also operates another business called Brightwurks that builds web applications. So far we've created two, Feed My Inbox and Linkpatch, along with a mobile website gallery called Mobile Awesomeness.

We've decided to start work on a new web app recently, and blog about the entire process publicly. Being transparent and sharing our secrets is another way of proving that ideas are worthless. Everything from inspiration to wireframes, logo to launch will be written about and covered in detail. It's a really great way to learn about our process first hand and even follow along and participate if you want.

The project is called B Combinator. We've published two posts so far outlining what B Combinator is and what we're building. I'd  love for you to subscribe and participate as we try to do something that's never really been done before. I'll be hard at work working on the app and writing all about it in my spare time over the next several months. Cheers to taking risks!