Motherfucking footer spacing.

And what did it matter? Are our clients really going to lose customers because there’s an extra 10 pixels of footer spacing in IE6 on one of the pages? Is the client going to refuse payment because of these pixels? HOW MUCH BLOOD ARE THESE PIXELS WORTH?

But it was never about the footer spacing. It was about quality. It was about cultivating a culture of relentless quality in everything we produced.

Quality versus the Ego

Every time Alex called me into his office and showed me a page with an extra 7 pixels of spacing my blood pressure went through the roof. I took it as a personal insult. But he wasn’t insulting me. It was about producing a quality product.

Quality has no room for egos. Other people will have better solutions. You are going to miss things. You are going to break things. You are going to make mistakes. And people are going to point it out.

And I think it’s okay to get upset. Take that feeling and turn it inwards. Vow to make things better. Make sure you’re always producing the best quality product you can.

Move fast and break things

If you take a look at any of Facebook’s recruiting marketing, you’ll see a phrase repeated over and over:

Move fast and break things

And with good reason — the idea it embodies is fantastic. Unfortunately I see a lot of people interpreting this quote as something like this:

It reminds me of another misinterpretation that’s always bugged me:

Quality isn’t something to be sacrificed. Move fast and break things, then move fast and fix it. Ship early, ship often, sacrificing features, never quality.

Embrace change. Ship. Never cut corners.

Quality is contagious

Which reminds me of the broken windows theory:

Monitoring and maintaining urban environments in a well-ordered condition may prevent further vandalism as well as an escalation into more serious crime.

Broken windows are the reason most large software projects suck to work on. A little technical debt here, a few shortcuts there, and pretty soon you’ve got a codebase so full of broken windows that no one even cares if they throw another pile of broken glass on the heap.

But just as broken windows are contagious, so is a dedication to quality. Carve out a little piece of a messy codebase and clean it up. Sharpen the edges, polish the surface and make it shine.

The caveat here is that you can’t half-ass quality. Dedication to “semi-quality” isn’t dedication at all. High-end design coupled with mediocre engineering can only produce a mediocre result.

And I don’t know about you, but I don’t dream of building mediocre. I dream of building the best. So I’m thankful to Alex for instilling this idea of relentless quality in me, even if I still have footer spacing related nightmares from time to time.

Can you describe a working day at GitHub? What time do people normally get in? How are features officially decided/approved? I’m sure anyone can’t just write whatever they want.

I love talking about this stuff. Not because I really dig working at GitHub (I do), but because I think we’ve finally figured out what makes us productive and happy. That’s hard to find in some companies.

These posts are ostensibly about GitHub, but that’s just so there’s something concrete to write about. These posts are really about how you can improve your company’s work atmosphere.

I hate multi-part everything on the internet, but not as much as I hate entirely too-long posts. So I split it up into three parts spread out over three days.

Hours are Bullshit

Most companies want you to get to work early and stay late. The metric should be productivity, not hours.

Be Asynchronous

You can get more done by being more direct, less intrusive, and more cooperative with your coworkers.

Creativity is Important

Code is creativity. Fostering an atmosphere where people can be creative will lead to better code.

Adobe have just released an alpha version of something called Adobe Edge. The product enables you to create CSS/jQuery animation without writing everything by hand.

My curiosity got the better of me and so I downloaded the alpha release.

I have no intention of reviewing the product at this early stage, because it is far from ready. However, playing with the software has left me with one fundamental question – why?

Do we really need a CSS animation tool?

To understand my concerns you must understand the direction that this tool is taking. For those of us who used early versions of Adobe Flash the similarities will be apparent. Adobe appears to be recreating the animation functionality provided within Flash using CSS and jQuery.

You may consider this a good thing. But is it really? Do we really need a “flash equivalent” that produces CSS-based animation?

What website needs a tool like this?

From my perspective most website animation falls into two categories.

There are those websites which make heavy use of animation. These are typically sites for sectors such as gaming or movies. They are high impact, visually appealing sites that are more about branding than content.

Then there are websites that use animation as small enhancements. On these sites animation is not critical. An example of this may be an e-commerce site where items visually move into the basket when selected.

If we look at these 2 scenarios it becomes apparent that there is no place for a product like Adobe Edge.

CSS animation should not always replace Flash.

For those websites that make heavy use of animation the basic features provided by CSS animation probably are not going to do the job. These sites typically include large amounts of interactivity, video and sound. It strikes me that in such situations Flash is by far the superior tool and should be used.

Do you really need a tool from Adobe to create basic CSS animation?

As for sites that only use animation to create small visual enhancements, a tool such as Adobe Edge feels like a sledgehammer to crack a walnut. There are a number of simple, free, online tools that can produce these basic animations. Alternatively you can just hand code them, it really isn’t hard!

To me this just feels like another example of using the latest technology simply because it is trendy to do so, rather than it being the right tool for the job.

A tool that encourages bad practice.

Maybe I’m turning into a snob, but as I look at Adobe Edge I fear we will see the same horrors that the web experienced when Flash came on the scene. This tool cries out for you to create pointless animations that add little value to your site. Worse still it requires any animation to occur within a fixed area (no responsive design here) and produces code that many will not have a hope of understanding.

Perhaps this tool is meant for the the low-end of the market, where websites are produced using WYSIWYG editors and next to no money. However just because this segment of the market has been the domain of bad design in the past does not mean it should be perpetuated. In my opinion a tool like Adobe Edge could well do exactly that.

So what do you think? Is there a place for a tool like this? Am I just being a miserable git or worse still committing heresy by suggesting that flash should not be replaced entirely? I’m sure you won’t be shy in letting me know in the comments.

Similar Posts:

• Podcast 39: Mature Flash
• Rich Media Advertising and Flash
• Podcast 29: The great flash debate
• Accessibility and the new headscape site
• National Trails web site launched

  

Truth be told, I am a philistine. When people talk about recycling, I don’t think of saving the planet.

In my earlier post, “Lessons Learned: Productivity Tips For Running A Web Design Business,” I wrote about how we can reuse and recycle what we do in the Web industry to save time and money.

Now let’s explore the subject further. We will look at how we can recycle existing work (done by ourselves or others) in order to be more efficient. By doing so, we can finish projects more quickly and generate a better profit margin. The great thing about recycling is that we can all do it, whether we are a developer, designer or website owner. Let’s begin our journey with the masters of recycling: developers.

Developers: The Kings Of Recycling

I was once told that all good developers are lazy. Having a design background, I thought this bizarre. And yet, good development involves discovering the most efficient way to do something. Of course, finding the most efficient way is not always easy. It largely comes down to constantly searching for new approaches and taking the time to try new ideas. The key is to never be satisfied with your current approach, but rather to always strive for and experiment with new approaches.

At the core of this “lazy’” approach to development lies the principle of “coding only once.”

Classes and Functions

Mid-project, it is easy to focus on the immediate challenge and fail to think long term. But a good developer writes code that is reusable in future projects.

Functions that can be used in multiple projects can save developers a lot of time.

To recycle, write reusable functions and classes, not project-specific code. This involves ensuring that code is modular and self-contained, not dependent on project-specific elements.

The principle of a reusable code library isn’t limited to classes and functions. It also applies to other aspects of your code.

Starting Points

Whether simple HTML websites or .NET applications, most projects begin with the same set of files. For example, on a simple HTML website, you would have a CSS reset, a jQuery include and maybe some basic print and IE6 style sheets.

Eric Meyer’s CSS reset should be included in the default code set of almost every Web project.

Setting up this default code for every project is time-consuming and unnecessary. Instead, create a generic set of code to use in every new project. This not only enables you to recycle code between projects, but it helps to keep your coding workflow organized.

Better still, you don’t even have to create these starting points from scratch. Projects such as HTML5 Starter Pack and HTML5 Boilerplate take all of the hard work out of getting started. They enable you to recycle the hard work of others.

This leads us right into libraries and frameworks.

Libraries and Frameworks

Many developers start learning how to code by adapting the code of others to their needs. But this just scratches the surface of what is possible. Today, Web developers have a big choice of libraries and frameworks that significantly reduce coding time, from JavaScript libraries such as jQuery to PHP Web application frameworks such as CodeIgniter.

CodeIgniter is one of many frameworks that enable you to reuse the development work of others.

Some would caution developers against using libraries and frameworks unless they understand their inner workings. Certainly, debugging a library that you don’t fully understand can waste hours. However, the time-saving benefits of these libraries and frameworks is so great that they outweigh the drawbacks in most cases.

Even if you use a library or framework, wasting time by repetitively entering the same code is still possible. In such cases, snippets are a real-time saver.

Using Snippets

Snippets are commonly used pieces of code that you can insert quickly with a keyboard shortcut. For instance, a WordPress loop can be entered simply by typing wloop or by pressing Command + W. Many coding tools, including Coda and Espresso, support snippets. But even if your coding environment of choice does not, you can use a text expander to add this functionality.

Also, there is no reason to create snippets yourself. Instead, you can reuse the snippets of others by using an online library. Two are WP-Snippets and CSS-Tricks Code Snippets, but there are many more.

Like many HTML coding tools, Espresso lets you save snippets of reusable code.

In addition to traditional snippets, plug-ins such as Zen Coding create a lot of code in a few keystrokes.

Of course, knowing about snippets is not enough. You have to take the time to learn them and then make a habit of using them. Many developers are aware of all of the options above and yet are always “too busy” to use them. That said, many developers are the kings of recycling, and you can learn a lot from them, whether you are a coder or even a designer.

Designers Can Recycle, Too

Most Web designers also code and so can use the tips suggested here. But they can recycle in other areas, too. Endlessly repeating the same action, whatever it is, wastes a lot of time.

Recycling Actions

Designers waste many hours laboriously resizing and reformatting images. And what about the time wasted saving titles as images? In fact, automating many of these tasks is entirely possible and can save the designer a huge amount of time and reduce the risk of repetitive strain injury.

Adobe Photoshop has some excellent tools for handling repetitive tasks. These “actions” are easy to build and can save hours in the long run.

Veerle’s blog offers a great introduction to creating Photoshop actions.

Even if you do not use Adobe Photoshop, there are other ways to create macros to handle repetitive tasks in most applications. Once again, the problem is not the tools we use, but rather in taking the time to set them up properly.

Grid systems are another area where a little effort in recycling returns significant time savings.

Using the Same Grid

Anybody who understands basic design principles knows how important a solid grid is. It also makes building a website a lot easier. Unfortunately, many designers approach the grid afresh every time they begin a project. Instead, look for ways to reuse a grid structure from website to website. This is not to say that we should use the same number of columns on every website, but rather that we should have an underlying system with which to work.

Having a consistent starting point will help you overcome the “blank canvas” problem and will also speed up the build process.

The 960 Grid System (960.gs) is a perfect example of a grid structure that is reusable from one project to the next. It works well because it can be divided into a variety of column configurations, suiting most projects.

960.gs demonstrates how the same grid can produce very different designs.

Designers also have opportunities to recycle the work of others and even themselves.

Recycling Is Not Stealing

There is a myth among designers that every new design should be fundamentally unique. In reality, nothing is truly original. All great designers know that their work is inspired and informed by design principles and by their own work or that of their peers. Think for a moment how many designs have been either cast aside as being inappropriate for the project or rejected by the client. This is an enormous waste of effort.

When appropriate, nothing is wrong with reusing old elements in new projects. Moreover, we should not feel ashamed for drawing inspiration from designs we have seen elsewhere.

I would urge every designer to keep a library of inspiration, including both their own work and the work of people they admire. Of course, we must be careful not to spend too much time obsessing over our inspirational libraries. Eventually, we need to stop thinking about our designs and just start producing them.

I find Evernote an excellent tool for collecting bits of inspiration.

Speaking of clients who reject designs, there is also an opportunity to recycle the arguments that we put forth to justify our work.

Recycling Our Arguments

As Web designers, we all know that the same comments come up time and again when speaking with our clients, everything from “Make my logo bigger” to “Why is there so much white space?”

Despite knowing that these issues will come up repeatedly, we do nothing to pre-empt them and so waste time covering the same ground.

A better solution is to discuss these concerns before they become major stumbling blocks. By sharing documents such as “10 Tips for Ensuring Better Site Design” and “Where Are My Rounded Corners?” I’ve been able to bypass many such laborious conversations.

Producing documents that tackle recurring issues (such as progressive enhancement, covered here) saves time in the long run.

The last area in which designers can recycle is with design assets.

Reusing Your Design Assets

We have already talked about reusing grid structures. But reusing other design assets is also possible. Images, icons, color palettes and typography are a few examples. All we need to do is organize them so that we can find the relevant asset for a particular project.

Do you tag your library of images according to mood, color and other keywords to make it easy to see whether anything can be used in a given project? Do you have a library of images that you’ve purchased?

By tagging your assets, finding ones to reuse becomes easier.

Also, is there any reason you cannot use the same icon set in multiple projects? This can save the time wasted searching for new icons and the money for purchasing them.

If you are reading this post, chances are you are either a designer or developer. But you’re probably also a website owner. There are significant recycling opportunities for this group, too.

Not Forgetting The Website Owners

Those of us who own websites are some of the worst recyclers. But we have two superb opportunities to simplify our lives. Whether you run a personal blog or a large corporate website, a bit of recycling goes a long way.

The area that offers the most possibilities is content.

Recycling Content

Whether you’re a humble freelancer or part of a large corporation, you produce content all the time, whether it’s an email about your latest work or a corporate announcement. There is potential to recycle every piece of content we produce.

There are interesting nuggets of information in what we produce that others may find useful and could be recycled on our websites.

Let’s say you respond to an emailed question about mobile websites. Instead of leaving the answer trapped in the email, with a little recycling, you can repurpose it into a blog post that everyone would find useful. The same is true for presentations, internal papers and even informal chats with colleagues.

Many of the presentations I give began life in another format, such as a blog post or even a tweet.

We should also consider content that has already been published online. Try updating and reposting old articles. Text on your website that explains your unique selling points might be better represented in video. Repurpose Twitter conversations with customers into frequently asked questions.

The opportunities to recycle content are endless if we only open our eyes to the possibilities. And nowhere is this clearer than with email.

Email and Answering User Queries

Whether your website is big or small, you will find yourself answering the same types of inquiries. This repetition is not only time-consuming, but frustrating.

I for one get asked the same questions again and again:

• Can I advertise on your website?
• How do I start in Web design?
• What books do you recommend?
• Can I book a consultancy clinic?

The list goes on, and despite blogging on these issues and even having offered an FAQ section at one point, I still get the same questions.

You can save time by having stock answers to these questions ready to copy and paste. Taking a few seconds to store the answers will save you time later on.

TextExpander is one of many tools that enable you to easily reuse answers to common questions.

Make your life easier by storing your answers in a text expander, such as the one above. Simply typing a few characters will give you a comprehensive answer that addresses all of the key points.

Recycling Does More Than Save The Planet

As I said at the beginning of this post, recycling is not just about saving the planet. It’s about saving time, money and, most of all, your sanity. By taking the time to find shortcuts and work smarter, you make your job more enjoyable and end up working less.

I like to think of myself as a bit of a recycling ninja, but I know there is always more to learn. I am sure you guys have identified some great recycling tips that enable you — in the words of my developer friend — to be lazy. I would love to learn them, too, so please share them in the comments below.

(al) (il)

© Paul Boag for Smashing Magazine, 2011.

On getting seen

In order to get people to apply for your job, you will have to get them to your listing first. There are a few places that will help with that: our text ads on Stack Overflow (see image), various places on our web site and our tweets. Due to space considerations there isn’t a whole lot for people to base their decision on (to click or not to click?). They’ll see:

• The title
• The employer
• The location
• Whether the job is telecommutable
• Tags (during the research period only on our website)

That’s all you have to sell your position with, so you have to make it count. While you (probably) can’t do much about your name or location, the telecommute status, title and tags you choose can make a difference.

We provide roughly 60 characters of title space when displaying jobs on Stack Overflow, and yet a lot of jobs simply have “Developer” or some such as a title. It’s like the seller of luscious, beautiful, high piled, soft shag rugs made with the wool of virgin sheep fed nothing but the finest ambrosia taking out an AdSense ad that says: “Rugs for sale”. Wouldn’t you rather click on “C# developer; work on massive, scalable social solutions” (if you were into such things)? Something as simple as mentioning a technology in your title can improve the percentage of people that apply to your job after seeing the listing (apply rate) by about 25%. While it doesn’t necessarily improve the number of views, it improves the relevance of the viewers, leading to more applications. If you can also give some sense of what type of work people will do, all the better.

In January we did something new: we added the ability to tag your job listing. As it turned out, this was a good thing. Listings with tags get on average between 40 to 60% more views than jobs without tags. Based on this finding we now also show the tags in our ads on Stack Overflow. It’s still too early to tell if this will make a difference, but we are thinking it will.

For telecommute jobs the numbers are even more dramatic. Jobs that are marked “telecommute” receive on average 2.25 times more views and 2.125 times more applicants.

On getting applicants

Eyeballs, while important, are at best a measure of how successful you are at attracting people to your listing. The real objective is to get the right people to apply and it turns out there are certain things you can do to improve the number of applicants (just like there are things that will drive most applicants away).

To determine what these factors might be we looked at some of the best performing listings and some of the worst ones as measured by apply rate. The difference between the two groups was quite dramatic:  The average apply rate for the high performing group was 30.9%, and the average for the lower was 3.2%.

For both these groups we looked at a number of factors that might influence a listing’s performance, both positively and negatively, and scored listings accordingly (+1 for positive factors, -1 for negative ones, 0 if not applicable). On average, the well performing listings had twice the score of the low performing ones. Some of the things we found:

Do’s

The three biggest factors associated with a high apply rate are:

• Culture description (5 times more prevalent among the well performing listings)
• Does the work advertised sound cool? (As measured by the admittedly somewhat arbitrary measure of: “would we like to do this?” – 3 times more prevalent).
• Few bullets (seen in 20% of the high response listings and none of the low response listings).

With regards to culture description, we should note that where the culture was mentioned it always was a good one, which may be the real reason this has a positive effect (we’re fairly certain that describing an average or downright sucky culture would not do much to help). So the Do should really read: If you have a great culture, list it. If you don’t, create one, then list it.

Not all work is inherently cool. But even then, the way it is described matters. Do you give an example of the type of problems candidates will be working on? Of what their work might mean to others? In short, do you tell potential candidates why they should care? (Wrong answer: to make us more money and keep the shareholders happy – we’re paying you a salary after all)

Other things we looked at included company description, whether the listing company was well known, position description, telecommute status, salary range posted, and willingness to sponsor H1Bs, but these either didn’t differ from one group to the other or there were too few listings that had these to say something conclusive about them.

Don’ts

We also looked at some potentially negative influencers:

• A plethora of bullets (46% of the low apply rate listings vs. 7% of the top)
• TL;DR (31% vs. 0%)
• Generic title (46% vs. 40%)

We are talking lots of bullets, 10-15+. There were a even few listings with over 25 bullets between the various sections. The worst offenders had multilevel bullets with no descriptive text.

TL;DR really indicated our inability to finish reading the listing, either because of excessive length, dryness or marketing speak.  Clear, to the point descriptions of your company and the work the candidate will be doing are good, copying your PR department’s latest press release, not so much. You’re courting here, save your life story for the 3^rd date.

Final thoughts

When you are hiring a developer you enter a highly competitive market, and to attract stand-out candidates, you need a stand-out listing. While your mileage may vary, the above could help you increase the number of applicants by a factor of (almost) 10. We hope this will help both employers (by getting them more applicants) and programmers (by having better listings to choose from).

That’s what we found, but we would love to hear from developers and potential employers — what works for you?

My official job title at GitHub is “Ego Surfer”, a tongue-in-cheek reaction to my stars project, a command line interface I wrote to tell me who have starred my tweets. GitHub job titles are given to employees in a comical fashion, but in my case I like to think it’s fairly accurate: I really like to discover and manage people’s reactions to my blog posts, tweets, and product launches.

I use “assholes” in the title somewhat loosely; I hate spam like the rest of you and being an asshole who pushes their work with wanton disregard for how disrespectful they’re being is never a good idea. That said, if you’re writing good content that could stimulate an appreciative audience, I see nothing wrong with putting your best foot forward.

This isn’t some old-school post about getting indexed in Technorati. Getting buzz about the posts you write today is a bit different. How you initially react to someone’s own reaction to your work can turn your small buzz into a lot of fucking eyeballs.

Writing your launch tweet

Twitter is the most important technology to leverage. As I wrote in Fame, tweets and their subsequent retweets can really snowball a mediocre post into one that’s discussed all over the internet.

Not all tweets are created equally. Here’s how to win:

• When you write a post, simultaneously tweet a link to it.
• Make the tweet body interesting. Either overtly make it vague, or catchy. I tend to swear a lot, which can jump out at you. (Or backfire, of course.)
• It’s helpful to get others to tweet you at around the same time. I’ll usually pop into Campfire and pre-announce a post. If my coworkers decide to tweet it at the same time, you end up generating a lot of talk on the same link. If you have overlapping circles of followers, you can build a feeling of urgency and freshness that is appealing to click on — and retweet.
• Reply to criticism and to compliments over Twitter. It’s sometimes surprising how many outsiders read public @replies. Not only does replying to someone directly generate goodwill (regardless of whether or not they ultimately agree with your position), but you can sometimes generate interest in third parties that would have otherwise missed your post entirely.

Monitoring tweets

On a good post, you’ll see a lot of activity in the first hours and day. The best ways to monitor that are using Favstar and Summizer.

Favstar was created by Tim Haines as a way to track who retweets and stars your tweets on Twitter. I use it as a quick benchmark of how quickly a post is taking off. It’s helpful to track who exactly is checking your post out; sometimes you’ll catch some larger players, sometimes you’ll be able to click through and read some discussion on your article. Sometimes it’s just fun to have an ego boost.

Summizer is an iPhone app by Fantzer that is effectively an interface for saved Twitter searches. While there are plenty of Twitter search apps out there, Summizer does a great job of keep track of read state (which, surprisingly enough to me, I end up using frequently), and the interface itself is very quick. I initially assumed that I wouldn’t use Summizer more than once or twice, but find myself using it often: second only to my main Twitter client on my phone.

Twitter saved search bonus round

Another hint for Summizer and Twitter saved searches in general: you can do some fairly powerful stuff in your search. I track the term “zachholman.com”, which returns tweets that link to this site (which even works through link shorteners).

You can also use it as a form of filter. If we just searched Twitter for “github”, we’d pull in a lot of extra noise: post receive Twitter hooks, blog posts on pages.github.com domains, etc. We want to see the discussion, not the noise. A lot of us at GitHub have a search saved similar to github -merge -commit, which will strip tweets with “merge” and “commit” in the URL (which are usually just notification tweets).

Footer hacks

Right now I have a few things in my footer after my posts. One of which is the tweet button, a brain-dead easy way to let visitors tweet your URL.

Secondly, I have Boastful, a tiny jQuery plugin I wrote that displays the smiling faces of everyone who tweets a link to your post. Humans are ego-centric. They like seeing their faces in public places. I don’t do comments on my blog posts, but I do like offering this small bit of community.

Thirdly, on more substantial posts I’ll add a link to the Hacker News story submission (either submitted by me or whoever else gets to it first). This serves as a way to facilitate the discussion that I don’t allow on the post itself, and it provides a easier connection for Hacker News visitors to my site to upvote the actual Hacker News submission. I really like this setup: Hacker News tends to give you some honest, respectful feedback, and exposes you to movers and shakers in the industry.

You don’t need to go crazy with these sort of “footer pieces of flair”, but having a few smart integration points goes a long way.

Analytics

I hate Google Analytics. I really care about 1) trends, 2) referrals. Anything more than that is interesting, but a distraction from those first two expectations. Google Analytics is a pain to use.

Gauges is not.

Gauges is a newcomer this year to the stats game, but it’s beautifully-designed and gets me the information I need quickly (and in real-time, with maps!). The reason I love Apple is the reason I love Gauges. If you’re feeling that Google Analytics is too heavy for you, check out Gauges. Seriously.

Always Be Closing

Look. I loathe that there are jobs in “Marketing”. I hate that very word. But you can be smart about a few things and get the word spread about your project or post faster.

More importantly: everything I’ve said in this post is completely bullshit if your content is bullshit. I play the social card heavily on the assumption that people will want to share my content. If I write a crappy post, people won’t share it and I leave it at that. Get that house in order first, and then from there you just take steps to make sure more people have the opportunity to talk about your work.

• 2008: Contribute to an open source project
• 2009: Make it to a Ruby conference
• 2010: Maintain some sort of popular open source project
• 2011: Speak at a conference

All of these seemed daunting at first. And then I did them. Now I wonder why I didn’t do all of them earlier. I want you to experience that same progression, regardless of what goal you might have. It’s easy to improve yourself.

2008

2008 was before GitHub really started picking up momentum, and as someone feeling somewhat new to Ruby and to open source in general, figuring out which project to contribute to and how to do it was fairly challenging. Eventually I made a few different contributions (one of which was for restful_authentication to my future coworker, Rick Olson, who unceremoniously shot down my patch and made me whimper in a corner for a few weeks). But I got my other contributions in.

2009

Being young, dealing with scheduling, and the lack of a company sponsoring my travels meant heading to a technical conference felt a little out of reach. But I made it to RailsConf 2009.

2010

In 2010 I found myself with a couple different open source projects taking off: both in developer activity (forks of my dotfiles) and in end-user activity (usage of boom). I learned more about what versioning a project meant. And releases. And encouraging contributions. It was initially intimidating, but now it feels so second-nature.

2011

In 2011, I sent a talk submission to RailsConf. I felt silly: I hadn’t given a talk before, and choosing the largest Ruby conference seemed an intimidating first step. It was accepted, and I gave my talk in May. Now I have four other talks scheduled for the rest of 2011 so far, including some international conferences.

Being better

I felt a little embarrassed putting my timeline at the top of this post. Everything on that list seems so trivial now that I’ve done it. Of course it’s easy to contribute to a project. To attend a conference. To prepare a talk.

But they all felt daunting before I did them.

A big part of my job involves talking to a lot of software developers, from Ruby to Cocoa to young to old to stern to playful. And I usually find myself encouraging people to give a talk. To write blog posts. To publish more open source.

I’ll look at them and see the same feeling I felt. It’s not a feeling of incompetence. It’s a feeling of a lack of belonging. That they’re not ready to be indoctrinated into the special Club of People Who Are Ready.

Being Ready is only accomplished after you’ve done something. Before you’ve done something, it’s daunting. After you’ve done something, it’s easy.

So do something.

JSON

Verdict: no brainer

Flexible. Understood by everybody. (Sorry, Dave Winer!)

OAuth2 and HTTPS-only

Verdict: as good as it can be

OAuth2 is fairly straightforward to implement (although the spec is still churning a bit – the userless flow arrived too late for us to use it!) for both servers and clients, and offloading encryption to HTTPS instead of implementing it ourselves makes it light years easier to get right.

Consumers pushed back a bit on our decision to not let third party applications just use usernames and passwords to authenticate (instead, we force them to use a web-based authorization page). We often tell people, “You shouldn’t be any more comfortable entering your foursquare password into some random app than you are putting your Facebook password into some random app.” Still, the user experience for mobile applications could be better, and on some mobile platforms like Blackberry and Nokia, it’s hard for application developers to interact with the browser in the way that OAuth requires.

The security properties of OAuth2 are far from perfect, but it’s not the protocol’s fault. It would be great if client devices provided a way to keep client secrets secure, even from self-signed SSL certificate man-in-the-middle attacks. And it would be great if the “implicit grant” flow could be more robust against token leaks by the consuming page.

REST lite

Verdict: good!

We decided to use resourceful URLs for certain key objects, like users/USER_ID or venues/VENUE_ID, with actions and connections hanging off of them. But not every resource has a URL (e.g. badge unlocks, todos, comments). This keeps the API minimal and reduces the surface area we need to keep backwards compatible.

On the flip side, we decided not to have deeply nested URLs, e.g. users/USER_ID/tips/TIP_ID, instead opting for flat tips/TIP_ID. This led to much simpler URLs. And having only one path for, say, the details about a tip, let us avoid making developers choose between multiple ways to do the same thing. As a bonus, this explicit, DRY approach to API design makes monitoring and debugging much easier.

Finally, we avoided using the extended set of HTTP verbs beyond the web’s idiomatic POST and GET, in favor of putting the action into the endpoint name, such as tips/add or tips/TIP_ID/markdone. Developers may be using stacks where these verbs are impossible or confusing, and if we supported a workaround for a lack of verb support, we’d be back at having two ways of doing things.

Generic structures and indirection

Verdict: good!

In APIv2, lists use a general structure of { count: X, items: [...] }. This lets us vary the amount of data we want to include in a given context (e.g. the number of tips in a venue response) without breaking clients. And it makes it easy for developers to understand how much data there may be to page in and to share list-handling code across endpoints.

Grouped lists extend this paradigm, where groups are represented via data, not structure. Rather than tips: { friends: [...], others: [...] }, we do tips: { count: X, groups: [ { name: friends, count: Y, items: [...]},.... ] }. This is more wordy, but it allows us to add and remove groups without breaking clients, especially in cases where the data is being pulled into objects where field names map to members. It also allows us to specify an order of groups and to structurally group sub-counts with sample items (e.g. the count of tips from my friends is next to tips from my friends).

In general, we tried to live by not using keys as data. Although it might be intuitive to say something like notifications: { mayor: { .. }, points: { .. } }, this structure suffers from the same problem as the groups above: it’s hard to add and remove groups without breaking consumers, and there’s no order. Instead, we opted for notifications: [ { type: “mayor”, .. }, .. ], which is much more flexible.

Finally, where possible, we use indirection to guard against the introduction of additional data. For example, rather than notification: { type: “special”, item: { ...specialdata... } }, we opted for notification: { type: “special”, item: { special: { ...specialdata... } } }. Although wordier, this format is much more explicit, and it allows us to add additional objects related to a given notification without perverting the form of a “special” object.

Documentation

Verdict: good!

Never underestimate the value of documentation; it’s been one of the largest sources of positive feedback, especially combined with the API explorer, which is built using standard OAuth2. To make it easier to write documentation given our itty bitty team, we hacked together a really simple documentation generation system in python that takes text files and spits out Lift templates, and it’s part of our main code repository. No engineer developing new endpoints has an excuse not to document them, and the documentation is the go-to source of information even for internal developers.

Timestamps as seconds since epoch

Verdict: good!

Not human-readable, but so easy to parse, and nobody has complained.

CamelCase

Verdict: meh

They look okay on field names, but they still look a little funny on parameter names, don’t they? It’s also a little lame that our endpoint names still aren’t camel case, as well as certain, uh, special field names.

Images

Verdict: meh

We had a lot of debates about representing images and surveyed a lot of other APIs. Sadly, we still ended up with slightly different treatments of representing the available sizes and filenames for photos, category icons, badge images, and point icons, depending on the number of sizes we anticipate offering, squareness of images, and our own evolving sense of what is easy to use. In general, the badge response seems the least wordy and most user-friendly way of representing a range of image sizes, and we’re using it where we can throughout the API.

Versioning

Verdict: jury’s still out

The hardest part of designing an API is that you’re stuck with a bunch of decisions you can’t take back easily. But in some cases we needed to take them back anyway, and, for those we came up with the idea of clients sending back a version like 20110708 and promising to be compatible with all changes up to the date. This can lead to some tricky coordination problems between internal test clients and new server releases, and it places a large burden on clients to avoid regressing, but it’s also very simple to explain, and we’re trying to keep the number of breaking changes really, really low. We do wish we’d gone out the gate with this versioning plan, since now we’re forced to break the “default” behavior at some point.

Category representation

Verdict: oops!

Some things require testing with a range of clients to really show their warts, and unfortunately our category representation was exercised too late. It quickly became clear that the way we represent categories in venue JSON is an awkward compromise between brevity and utility by excluding the category ids and icons of parents. For any application where you may want to roll up the category hierarchy, you’re stuck loading the whole hierarchy just to contextualize a small set of results. In the users/USER_ID/badges response, we tried out a sort of “foreign key” approach where part of the response contains IDs pointing back into a dictionary of details that is part of the same response. In hindsight, we should have considered using something like this in more places. Although less straightforward than a totally-inline API like Twitter’s, it still avoids the extra call overhead of a normalized API like Facebook’s.

Object consistency and level of detail

Verdict: meh

This is the more general case of the category problem. It’s always hard to decide how much detail to include in an object, and we largely let the requirements of our own clients dictate what to include where. In APIv1, it felt arbitrary which fields would be present in, say, a user, when seen in a friends list versus in a list of checkins. In APIv2, we tried to be more principled by describing “compact” and “full” JSON representations with a minimal number of optional fields, most of which were optional because of context or absence of data. This sometimes meant sending down extra data in a given context, but we felt it made it easier to consume on the client, especially if the client wanted to cache data.

However, we’re starting to hit the limits of this. Do we add tipCount to compact venues? Does that adversely impact server performance or client speed? Do users always include their twitter contact information, if visible? We’ve discussed adding a detail=high parameter, or something like Facebook’s fields=X,Y,Z parameter, but we’re not excited about the complexity that results.

Envelope

Verdict: good!

Our decision to wrap all responses in { meta: { … }, response: {...} } has been well received, as well as the error details that we pack into the meta block. The decision to only provide error messages intended for developers, plus an error type for developers to switch on, seems to be working relatively well.

Grouping versus ranking

Verdict: meh

Although grouping tips by self, friends, and others seemed reasonable given our UI treatment, this doesn’t really make sense in the long term if we start to more aggressively rank tips from your friends against other popular tips. In fact, we already threw out the grouping of venue search results.

Halllllllp

These are just some of the decisions that we made in building APIv2. Is our assessment correct? Are there other things you’re curious about? Hit us up in the comments.

Enjoy trying to elegantly trade off performance and ease of use in APIs? We’re hiring.

- Kushal Dave, foursquare engineer

Instead of limiting elements to floating either to the left or right relative to their position in the document flow, positioned floats can be positioned at a specified distance from the top, bottom, left, or right sides of a containing block, while remaining part of the document flow.

How does it work? A new value is proposed for the float property: positioned – which becomes -ms-positioned in Microsoft’s first implementation. If you apply this in conjunction with position: absolute, you can position an element while it still affects the flow of the page. So inline content will not be overlapped by an absolutely positioned float, it will wrap around it.

It’s a pretty interesting answer to a common problem. It remains to be seen if the W3C deems it a good and complete solution however. There’s more details about the implementation of positioned floats on the IE10 Platform Preview docs.

Here's a simple array of users:

<?php
 
$users = array();
 
$users[] = array('username' => 'shiflett', 'name' => 'Chris Shiflett');
$users[] = array('username' => 'dotjay', 'name' => 'Jon Gibbins');
$users[] = array('username' => 'a', 'name' => 'Andrei Zmievski');
 
?>

There are a few different ways to create this array. Here's the output of print_r($users), so you clearly understand the structure:

Array
(
    [0] => Array
        (
            [username] => shiflett
            [name] => Chris Shiflett
        )
 
    [1] => Array
        (
            [username] => dotjay
            [name] => Jon Gibbins
        )
 
    [2] => Array
        (
            [username] => a
            [name] => Andrei Zmievski
        )
 
)

If I want to sort by username, I first create a separate array of usernames:

<?php
 
$usernames = array();
 
foreach ($users as $user) {
    $usernames[] = $user['username'];
}
 
?>

I then use array_multisort():

<?php
 
array_multisort($usernames, SORT_ASC, $users);
 
?>

Here's the output of print_r($users) after sorting by username:

Array
(
    [0] => Array
        (
            [username] => a
            [name] => Andrei Zmievski
        )
 
    [1] => Array
        (
            [username] => dotjay
            [name] => Jon Gibbins
        )
 
    [2] => Array
        (
            [username] => shiflett
            [name] => Chris Shiflett
        )
 
)

To sort the array by name instead, I'd do something very similar:

<?php
 
$names = array();
 
foreach ($users as $user) {
    $names[] = $user['name'];
}
 
array_multisort($names, SORT_ASC, $users);
 
?>

Here's the output of print_r($users) after sorting by name:

Array
(
    [0] => Array
        (
            [username] => a
            [name] => Andrei Zmievski
        )
 
    [1] => Array
        (
            [username] => shiflett
            [name] => Chris Shiflett
        )
 
    [2] => Array
        (
            [username] => dotjay
            [name] => Jon Gibbins
        )
 
)

There are many more uses of array_multisort(), and there are many other useful sorting functions. Please feel free to share some of your favorites in the comments.

Update: If your array isn't too big, and especially if you find it easier to understand, you might prefer usort(). Thanks to Franco Zeoli for this example:

<?php
 
// Sort the array by username.
usort($users, function ($a, $b) {
                  return strcmp($a['username'], $b['username']);
              });
 
?>

With mixed feelings toward our loyal and awesome friend, we bid adieu to CSSEdit as a standalone application. That’s right: CSSEdit 3 is a tightly integrated part of Espresso, bringing the best features of CSSEdit’s tools and previews to Espresso, and likewise introducing the flexibility and power of Espresso’s publishing system, editors, themes, and more to our CSSEdit users.

Was CSSEdit’s transformation the only reason for the long wait? No. Long story short, we bit off more than we could chew. In addition to a completely re-architected publishing engine, we improved and significantly future-proofed many aspects of Espresso. Instead of ruthlessly limiting the scope of the new version, we allowed the schedule to spiral out of control. In the future we will try to trade some of our traditional “splash releases” for more regular incremental improvements.

Espresso 2 is not quite as polished as we would like yet. At the same time, we think the included improvements outweigh the remaining rough edges for most users, and since many of you have reminded us that you are eagerly awaiting it we’ve decided to release a public Kaboom. Visit macrabbit.com/espresso/2 for all the details on our plans for Espresso 2, the Mac App Store, and to help us test and refine the final release. Thank you for listening, and we hope you enjoy the new Espresso!

Today we're happy to announce GitHub for Mac.

What does it look like?

When you first launch GitHub for Mac, we'll help you set up your GitHub account and find repositories already on your computer. From there, you can start managing repositories.

Once you dive into a repository, you'll be able to view the commit history just as you would on the web.

And you can of course dive in to a specific commit to see the diff and perform some operations.

Once you've made some changes, you'll be able to create commits.

When you want to change branches quickly, press ⌘ + B and a branch selector will show up.

Changing branches automatically stashes any changes until you switch back to the branch — switch branches with wild abandon. If you need to publish branches to GitHub, create a new branch, merge branches, or delete branches switch on over to the branches tab.

Once you're ready to share your commits, or pull in remote commits — just press the Sync Branch button. We'll perform a smarter version of pull --rebase && push that reduces merge commits but doesn't rewrite your merges.

Automatic updates

Once you download GitHub for Mac, we'll send out updates and the app will automatically download them. Keep an eye out for a little upgrade notice with a list of changes.

Behind the curtains

GitHub for Mac wouldn't have been possible without some awesome open source projects:

• libgit2 powers much of the Git operations for the app, making every interaction smooth, responsive and fast.

• objective-git libgit2 bindings bridge the gap between Cocoa & libgit2.

• Chameleon powers a good portion of the GUI. We're working with the Chameleon guys to get our changes into the main project, but in the mean time you can check out Josh's fork with all our modifications.

Just the start

This is just the beginning — we're really stoked for the future of GitHub for Mac and hope you will be too.

When most people think about grids, they think about engineering and architecture. However, the grid is an essential tool for graphic design as well, and the use of grids in website design have exploded in popularity in the last few years.

Using a grid is more than just about making elements on the page be square and line up: it’s about proportion as well. That’s where the theory comes into grid theory. Many art historians credit Dutch painter Piet Mondrian as the father of graphic design for his sophisticated use of grids. Yet classical grid theory has influenced successful artistic efforts for thousands of years. The concept of dividing the elements of a composition extends back to the mathematical ideas established by Pythagoras and his followers, who defined numbers as ratios rather than single units.

The Pythagoreans observed a mathematical pattern that occurred so often in nature that they believed it to be divinely inspired. They referred to this pattern as the golden ratio or golden ratio or divine proportion. The basic idea is illustrated in Figure 1.6, “The golden ratio”.

Figure 1.6, “The golden ratio”

A line can be bisected using the golden ratio by dividing its length by 1.62. This magical 1.62 number is really 1.6180339 …, an irrational number that’s usually represented as Φ (pronounced phi). Explaining the math used to come up with this number is a bit too involved for this discussion, and is likely to be of no real help to you becoming a better designer, so I’ll spare you the details. Besides, my math is a little rusty.

So just what does this ratio have to do with graphic design? In general, compositions divided by lines that are proportionate to the golden ratio are considered to be aesthetically pleasing. The artists of the Renaissance used divine proportion to design their paintings, sculpture, and architecture, just as designers today often employ this ratio when creating page layouts, posters, and brochures. Rather than relying on artistic notion, divine proportion gives us logical guidelines for producing appealing layouts.

This sunflower is an example of the golden ratio in nature, as Figure 1.7, “The golden ratio in nature” shows. The diameter of the sunflower’s center the total diameter of the sunflower, including the petals, divided by Φ.

Figure 1.7. The golden ratio in nature

4.1. The Rule of Thirds

A simplified version of the golden ratio is the rule of thirds. A line bisected by the golden ratio is divided into two sections, one of which is approximately twice the size of the other. Dividing a composition into thirds is an easy way to apply divine proportion without your calculator.

For quick layout experimentation, I like to start off by drawing a bunch of simple rule-of-thirds grids with pencil and paper. Just draw a rectangle, divide it into thirds horizontally and vertically, then draw a line between each vertical line to create six columns to work within.

With this simple gridwork in place, we can begin to lay out our elements. The large, original rectangle represents the container that we talked about in “Web Page Anatomy”. When using this method of layout design, I like to place the biggest block first. Usually, that block represents the content. In my first rule-of-thirds grid, I place the content block within the two-thirds of the layout at the lower-right. Next, I place my navigation block in the middle third of the left-hand column. I place the text part of the identity block over the left side of the content, and the image part of the identity over the menu. Finally, I squash the copyright block below the content, in the right-hand column of the grid. The result is the top-left of the four possible layout arrangements shown in Figure 1.8, “Four layouts in grids that follow the rule of thirds”.

Figure 1.8. Four layouts in grids that follow the rule of thirds

These initial sketches provide a quick look into what general layout approaches might work for your website. No need to stop there, though—the growth in popularity of grid-based design on the Web has inspired many great articles about—and tools for—designing websites on a grid.

4.2. 960 Grid System

One of my favorite tools for laying out website components are the templates and sketch sheets from Nathan Smith’s 960 Grid System. Inspired by articles from web designers Khoi Vinh and Mark Boulton, the 960 Grid System is primarily a CSS framework. The width of the templates comes from an article by Cameron Moll. In contemplating what width would fit within 1,024px wide displays, Moll landed at 960px, and pointed out that the number was divisible by 3, 4, 5, 6, 8, 10, 12, 15, and 16—making it an ideal width for grids. Nathan combined these ideas into a framework and created three layout foundations: one with 12 columns, one with 16 columns, and one with 24. I personally prefer to work from the 12-column templates, as they allow me to easily divide content into quarters by spanning four columns, thirds by spanning three, and halves by spanning six.

As you experiment with different arrangements for your own layouts, use the columns of whatever grid you’ve chosen as alignment guides for the identity, navigation, content, and footer blocks. It’s very tempting to arrange all your elements within the same one or two blocks, but try to avoid this—it’s not very interesting visually. Instead, consider pushing some elements into another column or off the grid entirely. One of the biggest complaints new designers have about working with grids is that everything looks boxed in and griddy. To those opposed to using grids for this reason, I say take a look at websites such as 10K Apart, seen in Figure 1.9, “10K Apart website with 16-column grid overlay” (on the next page). The red columns you see are from the 16-column 960 Grid System template, and do not exist in the actual website. With those columns hidden, you might never realize this design was created on a grid.

To quote Josef Müller-Brockmann, graphic design pioneer (and author of Grid Systems in Graphic Design): “The grid system is an aid, not a guarantee. It permits a number of possible uses and each designer can look for a solution appropriate to his personal style. But one must learn how to use the grid; it is an art that requires practice.”

Figure 1.9. 10K Apart website with 16-column grid overlay

The longing we have for structure, grids, and ideal proportion is deeply ingrained in human nature. A layout that “doesn’t look quite right” can often be fixed by moving elements and resizing them on the grid. So if a layout isn’t working, keep experimenting. At some point, all the pieces will click together and the Tetris level-up sound will play in your head. You will have achieved balance.

The Principles of Beautiful Web Design

This article is from Jason Beaird’s The Principles of Beautiful Web Design book (the second edition of which is out now). This is the fourth part of the first chapter.

If instead color is more your thing be sure to check out the existing digitization of the color chapter here on Design Festival.

<a href="http://twitter.com/kneath" class="twitter-follow-button" data-show-count="false">Follow @kneath</a>
<script src="http://platform.twitter.com/widgets.js" type="text/javascript"></script>

I love the idea of using regular HTML with feature-flags in data attributes combined with a common script. Can’t wait to play around with this style on Gist.

Documentation is the single most important change I’ve made to my coding style in the last year.

Documentation is Personal

I’m not talking about injecting a few comments in front of confusing lines here and there. I’m talking about taking a firm, consistent view at how you document your methods, your classes, and your projects, and then sticking to that mentality. Documentation is mostly described as a way to communicate your thoughts to other developers, but honestly, other developers can eat it. Documentation is the best way to communicate your thoughts to yourself.

Documentation is Clarity

If you don’t have an absolute clarity in the code you’re pushing, it rears its head by way of bugs, confused coworkers, and slow code. Straightforward documentation has given me that clarity.

I typically hate process. From TDD to BDD to Agile to everything else, it usually feels too cumbersome for me to stick with it. But two mentalities have really impacted me: TomDoc and Readme Driven Development. Both were designed by Tom Preston-Werner. Both have documentation at their core. Though they’re both obviously helpful for other developers who look at your code, I’ve found them to be extremely helpful to me as I code.

Writing the README first means you think about the end-product first. That seems somewhat silly — I mean, I’m writing this library, don’t I already know what’s coming next? But that’s usually not the case. More often than not I would jump straight into the challenging part of the project since I thought that’s where the substantive part is. It’s not. The end result is always the substantive part of your project. Forcing myself first to consider the API, the interface, and the end result led to a clarity that inspired less code and a more impactful project.

I feel similarly about TomDoc. TomDoc is a mentality that places emphasis on clear, straightforward, explicit documentation. Here’s a simple example taken from the TomDoc spec:

# Duplicate some text an abitrary number of times.
#
# text  - The String to be duplicated.
# count - The Integer number of times to duplicate the text.
#
# Examples
#
#   multiplex('Tom', 4)
#   # => 'TomTomTomTom'
#
# Returns the duplicated String.
def multiplex(text, count)
  text * count
end

You describe your method arguments, and you detail your response. Every time. It can sometimes feel repetitive, but that repetitive feeling is one of those I strongly welcome. It improves the clarity of my code. I get more done in less lines. The documentation style itself is clear, too. I write this blog in John Gruber’s Markdown because Markdown looks and feels like plaintext. I use Tom Preston-Werner’s TomDoc because TomDoc looks and feels like plaintext. There’s very little interface to learn between writing it down and rendering it in your head.

Documentation is Testable

Documenting code in TomDoc has lead me to two big testing personal “breakthroughs”, if you will. Since you’re required to detail every method argument, you’re forced from the beginning to consider how those inputs end up impacting that method. You think about the edge cases explicitly. Conveniently enough, those edge cases almost always translate into real test cases. I don’t consistently TomDoc first or write my test first, but they almost always happen simultaneously, since they effectively work in tandem. One helps you write the other.

My second “breakthrough” is realizing that if some method is hard to document, it’s too big. Ruby in particular has been harping for years that you want short, focused methods. I know that. Everyone’s known that since their third week using Ruby. But even if you’ve been writing Ruby for years, you can pretty quickly fall into the classic “oh I’ll just handle this here too” mentality. Once I do that, I end up trying to document more method arguments, more possible method outputs, and it’s just more work. Once that happens, it’s an obvious reminder that I messed up this method and should break it into two or three other methods. That means smaller, more resilient and easier-to-test methods, which directly translate into less brittle code.

Documentation is Diffable

Over the last year or so, we’ve been adding more and more TomDoc to code that we push here at GitHub. It’s not high priority or anything, but if you refactor or touch old code, it’s nice to add documentation for it.

We’re now at 30-plus employees, and there’s a lot of code flying around. When someone pushes to a GitHub repository, Hubot, our trusty Campfire bot, jumps in and posts a Compare View of the changes:

This hook is important. It’s how everyone at GitHub can see how GitHub is changing incrementally. The commit messages in Git are helpful to see what’s happening, but sometimes the commit message and (particularly!) the code doesn’t really give you a good idea of what or why something is changing.

Seeing the changes in a huge block of documentation in the Compare View on GitHub ends up being much easier to parse. You can see which arguments got removed, which new edge case is defended against, what changes are made in the public API. It’s another tool in your belt to help communicate code changes to everyone else.

Documentation is Marketing

I love the idea of documentation as marketing. A good README gets people to jump into your project much, much quicker. Heavily-documented code means others can read your project much, much quicker. Heavily-documented code means others will tend to break your tests less.

This extends to project websites and documentation as well. In fact, I love this documentation-as-marketing concept so much that I wrote about it. Even though I get a lot out of my documentation, that doesn’t mean that it can’t serve as a promotional vehicle for my project, either.

Documentation helps you in the bedroom

Well, I’m still trying to test the validity of that. But documenting your code is cool as hell. More importantly, it makes me feel more confident about my own code. You don’t need to go full-bore Readme Driven Development, you don’t need to use TomDoc, you don’t need to follow any particular process. But improving your documentation skills will make you a better developer.

Tweeting from the D9 Conference today, Jason Snell wrote:

Attitudes of Elop, Sinofsky, Apotheker all show huge impact Apple (once considered an oddity to be ignored) has had on tech industry.

That’s Nokia CEO Stephen Elop, HP CEO Leo Apotheker, and Steven Sinofsky, Microsoft’s president of Windows and Windows Live — all of them on-stage guests at the conference today. There’s no denying that all three of their companies are now following Apple’s lead in mobile computing. If not for the existence and success of iOS, Nokia wouldn’t be in trouble (and thus, Elop wouldn’t even be its CEO), HP wouldn’t have bought Palm (and Palm wouldn’t have come up with WebOS), and Windows 8’s innovations wouldn’t primarily revolve around how it looks and works on thin touchscreen tablets.

But I think it’s a fundamentally flawed idea for Microsoft to build their next-generation OS and interface on top of the existing Windows. The idea is that you get the new stuff right alongside Windows as we know it. Microsoft is obviously trying to learn from Apple, but they clearly don’t understand why the iPad runs iOS, and not Mac OS X.

Microsoft’s demo video shows Excel — the full version of Excel for Windows — running alongside new touch-based apps. They can make buttons more “touch friendly” all they want, but they’ll never make Excel for Windows feel right on a touchscreen UI. Consider the differences between the iWork apps for the Mac and iPad. The iPad versions aren’t “touch friendly” versions of the Mac apps — they’re entirely new beasts designed and programmed from the ground up for the touchscreen and for the different rules and tradeoffs of the iOS interface (no explicit saving, no file system, ready to quit at a moment’s notice, no processing in the background, etc.).

The ability to run Mac OS X apps on the iPad, with full access to the file system, peripherals, etc., would make the iPad worse, not better. The iPad succeeds because it has eliminated complexity, not because it has covered up the complexity of the Mac with a touch-based “shell”. iOS’s lack of backward compatibility with any existing software means that all apps for iOS are written specifically for iOS.

There’s a cost for this elimination of complexity and compatibility, of course, which is that the iPad is also less capable than a Mac. That’s why Apple is developing iOS alongside Mac OS X. From a piece by yours truly, writing for Macworld back in January:

The existence and continuing growth of the Mac allows iOS to get away with doing less. The central conceit of the iPad is that it’s a portable computer that does less — and because it does less, what it does do, it does better, more simply, and more elegantly. Apple can only begin phasing out the Mac if and when iOS expands to allow us to do everything we can do on the Mac. It’s the heaviness of the Mac that allows iOS to remain light.

When I say that iOS has no baggage, that’s not because there is no baggage. It’s because the Mac is there to carry it. Long term — say, ten years out — well, all good things must come to an end. But in the short term, Mac OS X has an essential role in an iOS world: serving as the platform for complex, resource-intensive tasks.

Apple’s radical notion is that touchscreen personal computers should make severely different tradeoffs than traditional computers — and that you can’t design one system that does it all. Windows 8 is trying to have it all, and I don’t think that can be done. You can’t make something conceptually lightweight if it’s carrying 25 years of Windows baggage.

New Feature Overview:

RGBA

We now support RGBA color values. In browsers that don’t support RGBA, the nearest backgroundColor to the element will be used to calculate a “blended” approximation of the color. Although this isn’t “true” alpha, it will at least provide the illusion of alpha when dealing with solid background colors.  This is a screenshot of Opera 10, Chrome 10, Firefox 3.6, and IE 6 all running this demonstration of alpha blending:

HSLA

We also now support using HSLA color values across all browsers, with the execption of alpha, which uses the same techniques described above.

Easy-to-use API

Instead of a simple group of private utility methods, $.Color() now creates a new Color object. The new Color object can be initialized in a few different ways: color names, hexidecimal color codes, css style rgba/hsla, an array of rgba values, or an object with the color properties. There are now helper methods for each color property, like .red() and .hue() that can get or set the particular value. Combined with helper functions like .toRgbString(), .transition() and .is(), $.Color can now handle whatever color needs you might have. Refer to the README on github.com/jquery/jquery-color for an overview of all the new functions available. No longer is jQuery.Color just providing you with animation of simple colors, you can now use its API to do complex color calculations and animations!

Quick Examples:

// Create a red Color object:
var red = $.Color( 'rgba(255,0,0,1)' ); // using a css string

// Create a red Color object, then make orange:
var orange = $.Color( '#FF0000' ).green( 153 );

// Get the color halfway between red and blue:
var between = $.Color([ 255, 0, 0 ]).transition( "blue", 0.5 );

Animating Partial Colors

We have added support for only defining one or two properties of a color object so that you can animate using a partial color like this:

// desaturate the background of this element
elem.animate({
    backgroundColor: $.Color({ saturation: 0 })
}, 1000);

Reporting Problems / Requesting Features:

If you find any problems with the new color plugin, or would like to request a feature, please create a github issue.

Also, we’d love to see and showcase some excellent uses of the new $.Color beta, so please be sure to share it with us in the comments.

You can now search for shots by color. Just head over to the color search page (accessible via the Explore menu). There are color swatches at the top. We tried to provide broad coverage, but the swatch results are far from exhaustive coverage of all shots on Dribbble.

The color picker on the right allows you to select your own hex code and get as broad or precise as you like. There are two sliders for adjusting results:

Color variance widens or narrows the range of color used to search. A higher variance tends to produce more, but less precise, results. Results at a lower variance will be closer to the selected hex code, though fewer in number.

Color minimum specifies the minimum percent of a shot that contains colors in the selected range. For example, searching green with a color minimum of 50% returns only shots that are half green.

If you’re confused by these definitions (we had a hard time writing them :), play around a bit. See how changes to the sliders affect your results; it’s probably the best way to learn. You should be able to use them to get very precise results when needed.

Our color database is generated from the shot images themselves by quantizing (reducing) all colors in a shot to a set of (up to) eight. The quantized colors for a given shot are displayed on its details page. Each color is linked to color search, so you can click on any color to search for other shots in the same color range.

While testing colors, we’ve found many new people and shots that we love, so we’re thrilled to open it to the public. Color us excited!