Author Archive

What’s your focus?

Every great website has a focus. If you can’t summarize the purpose of your website into one sentence, ten words or less — your idea will almost certainly fail. Talking to founders, I’d say this idea is pretty well established. Now let me reveal a secret that is not so well established: your website’s design should follow this same focus.

Learn by example: source hosting sites

Let’s start off with a field I’m pretty familiar with: source hosting sites. I’m talking about GitHub, BitBucket, SourceForge, Google Code, Launchpad and the likes. These sites all have a common focus: sharing code. I’m going to show you why GitHub is the only site who’s design follows it’s focus.

If your site’s focus is sharing code, the design should focus on sharing code. If you ever talk to any of us GitHubbers, we’ll always say that the site is all about the code. Let’s look at project landing pages in each of the above sites.

GitHub

GitHub

When you visit a GitHub project page, the first thing you see is the source code. Right below is the README pulled straight from the code.

BitBucket

BitBucket

BitBucket chose to highlight the shortlog (recent commits) on the project page. If you want to see the code, you need to go to the 3rd tab.

SourceForge

SourceForge

Sourceforge chose to highlight downloads (in this case, a compiled jar file — not the code) on the project page. If you want to see the code, you need to click Develop, and then fish around in the sidebar for the correct VCS and click browse.

Google Code

Google Code

Google Code chose to highlight the wiki on the project page. Getting to the code in Google Code is probably the most interesting of the bunch because many projects don’t even host their code there (example: redis).

When you click the Source tab you actually get a wiki page which many projects use to point to another repository. If the project hosts it’s code there, there is a sub link under Source that is labeled Browse that you can finally see the code.

Launchpad

Launchpad

Launchpad decided to highlight everything but the source code on the project page. If you want to see the code, there is a tiny link in the middle of the page that says ’View the branch content.’

Great examples from other fields

Source code hosting is just something that I’m extremely involved with. That doesn’t mean that focus is limited to code.

Flickr

Flickr

Flickr is all about sharing photos.

Facebook

Facebook

Facebook is all about connecting with your friends.

Daring Fireball

Daring Fireball

Daring Fireball is all about John Gruber’s writing.

Sites that have lost their focus

There is a huge genre of sites that seem to have completely forgotten their focus. I’ll see if you can guess the genre.

MSNBC

MSNBC

NYTimes

NYTimes

Rolling Stone

Rolling Stone

It’s no wonder news sites can’t get people to pay for their content. You need to focus on your content to get people to pay for it.

Charging for your focus

Many sites don’t want to give away their focus for free. That’s perfectly fine. But it doesn’t change a thing. Replace what people are going to pay for with an opportunity to pay you.

PeepCode

PeepCode’s focus is great tutorials. But the tutorial is not the focus of the product page — instead a teaser and a purchase button are.

Lots of people think that replacing their paid focus content with advertising is the solution — but that just redirects the focus on advertising — not getting paid.

Premium content is not about removing access, it’s about charging for access. Don’t focus on removing content, focus on charging for it.

Find your focus and focus on it

If you work on a website for a living, you should be thinking about your focus every single day. It doesn’t matter if you’re a copywriter, project manager, designer or sysadmin. What’s the focus of your site? Does your design reflect this? Run that through your head for every decision.

The beautiful thing about focus is that it’s not about the details. It doesn’t matter if you add some advertising to a sidebar, links to your header, change the background color or add administrative debris — these are all minor subjects. Focus is more about aiming in the right direction. Worry about the details later — but never aim in a different direction.

1 Comment more...

Optimizing asset bundling and serving with Rails

I wrote up a pretty lengthy post over at the GitHub blog explaining how we do asset bundling and serving. Well worth the read for anyone who’s interested in front end performance and works on ruby apps.


It’s not about how many hours you work

My favorite discussion amongst web professionals is when people start talking about work/life balance and how many hours they’re working. There’s been no end of interesting ideas to pop out from this — everything from 4 hour work weeks to 100 hour work weeks. And everyone thinks that they’ve got the answer. But I think everyone’s just arguing about an irrelevant metric: the hour.

Let’s talk about that work/life balance thing

Most of this discussion always seem to revolve around the idea of a work/life balance. The basic idea is to keep yourself sane. Don’t abandon your real life for your work. That makes sense, until people start attaching hours to it. I’ve had discussions with people where they try and argue to me that 40 hour work weeks keep them balanced. But I have to wonder, where does that magical number 40 come from?

The fallacy here is that people are thinking in black and white terms of “work” and “life.” I never really understood that, and I think I’ve gotten to a point in my life where I can see why: it’s a bunch of bullshit that employers made up to promote 40 hour work weeks. If you really think that there is a certain number of hours you can work a week to balance your life, you’re doing it wrong. So let’s ditch this idea of a work/life balance, because it just doesn’t make sense.

It’s about creating a creative environment in your life

It’s just that simple. If you’re in the creative field, you need to make sure your life promotes a creative environment. There isn’t one catch-all formula to do this. There isn’t a number of hours you need to work. You just need to experiment and find out what works for you. What I will do is try and offer some advice.

Find your passion in life and try to make money from it

If you hate your job, it’s unlikely that you’ll be successful in fostering a creative environment. Try your best to fix this. Find out what you’re good at, and try to make money from it. You’ll be producing better (more valuable) work and enjoying life more.

Explore projects that are explicitly not for profit

Money taints things, there is no denying this. So I suggest to find an outlet that you purposefully can’t/don’t make money from to help exercise your brain. That might mean creating websites, making music, or hacking on an epic perl script that no one but yourself will use. It doesn’t have to be something different from your work — it just has to be separated from your work. Something you can change or destroy without worrying about what others think.

Stop working if you’re producing crap

The only thing worse than being unproductive at work is forcing false productivity. If you find yourself at your desk and you can’t come up with anything useful, just stop trying. Leave your desk and go do something else. Maybe for a few hours, maybe for a week, maybe for a year.

Accept that there is no way you can be productive for 40 hours a week

The 40 hour work week is completely unsustainable. Human beings are not meant to sit down and really focus for 40 hours a week, 50 weeks a year. Our brains can’t handle it. I’m sure startup founders will come in here exclaiming how they’ve been working 100 hour work weeks for 6 months now and every hour was well spent. They’re lying.

Your brain needs to purposefully not think in order to come up with creative ideas. That might mean relaxing to your favorite book or movie while your subconscious attacks your latest project. You’re not working in the strict sense—but you’re getting work done.

That’s not to say you can’t have weeks where you get hundreds of hours of work done. But in my experience, after a week like that, I need another week or two to decompress.

Focus on what matters

My goal with this post is to hopefully get people to stop thinking in hours. Start focusing on making great things. It’s about the things you produce, not the hours required to make them.

Once you realize you’ve been focused on the wrong metric I think you’ll realize arguing about a work/life balance is just ridiculous. Spend time on your life. Spend time on your work. But always strive to do better. That’s all you need.


Joining GitHub

I still feel like it was last week I decided to give up my “safe” job at Web Associates Level Studios to play around with the ENTP crew. Well, it’s time for another move. Last week I was given an offer I just couldn’t refuse—to join the amazing GitHub team (my GitHub profile. For those of you who don’t know who GitHub is: shame on you. GitHub has taken something as boring as source control and made it something that brings people together. Social coding, indeed.

A brief look at the past couple years

The past couple of years have been a crazy blur of projects for me. Most of what I did for ENTP was for [redacted], so you won’t be seeing most of what I did, but I thought I’d spend a few minutes to archive (for my own good) some of the public-facing projects I completed.

Tender

Tender's Marketing Site

By in large, the biggest project I worked on ENTP was Tender — and I’ll be honest, it’s going to hurt to let this go. Tender was my baby, and I did all of the IA, design and front-end work for the site as well as some marketing and analytical work. The shining side of that tunnel is that of course GitHub uses Tender for their support, so I’ll at least get to use it and see how ENTP shapes the product.

Lighthouse iPhone

Lighthouse iPhone Screenshots

Designing an iPhone optimized interface was one of my first projects at ENTP. It doesn’t benefit from any of the OS 2.0+ features (HTML5, CSS Animations, Etc) since the code was created before these came along, but it gets the job done. It was a great exploration in turning a complicated interface and trimming it down to the bare essentials.

ENTP.com

ENTP.com Screenshot

I designed this in collaboration with Justin Palmer when ENTP decided they needed a new site. It’s got a few interesting features (like pulling in our current GitHub projects on demand in the footer), but it’s mostly just a brochure site for the agency.

Hoth

Hoth Screenshot

Hoth is ENTP’s blog. This design accompanied the new ENTP.com design and added in a bit of tumble-like functionality to the templates.

On to the next chapter

So now I enter the third dream job I’ve had in the 4 years since I graduated college (none of which have been slightly related to my degree). I’ll be diving into a design/front-end role for the team and help clean up and take the product to the next level.

OctoCat

I’ll see ya’ll at the next GitHub drinkup.


Installable apps

I’m getting kind of tired of all these web developers complaining about the time it takes to get updates to their apps up on the iTunes App Store. The truth is this complaining has some merit. But you have to realize that these people are not making web applications, they’re making installable applications. The problem is not Apple. The problem is lack of QA testing.

Your application will have many bugs

The first rule of development: your code is going to have a lot of bugs. I don’t care if you’ve got 3 days experience or 30 years experience in the industry. Your code will have bugs. This isn’t a pride issue, it’s a fact of life. Good developers know this and rely on testing (code, user-acceptance, performance) to expose bugs so they can fix them.

Bugs will appear after your code is deployed

Whether it’s the Y2k bug, deprecation of a technology, or your application getting blacklisted from a web service — some bugs are going to show up after your code is deployed. This is something you should expect. Again, this is not negotiable. It is going to happen.

The web makes us lazy

The truth is, developing web applications makes us lazy. I can fix a bug, deploy, and it’s fixed in about 15 seconds. This is why I love working on hosted web applications. You’ve got such immense power over the deployment process. Some things that rock about web apps:

  • You can be really lazy with UAT (User Acceptance Testing). Users will do your UAT for your and you can fix it on the fly.
  • You can be really lazy with bugs that will appear after deploy. If a web service changes, you fix it and redeploy. Done.
  • You only need one computer to test your application. No need to purchase multiple hardware platforms, video cards, or install multiple operating systems!

You can’t be lazy with installable applications

I once worked on a desktop application that was being sent out on millions of machines. This application was going to be the first thing that started up when the user booted the machine. It also meant we didn’t have the option to issue updates for the application after deployment. We spent tons of time doing user testing on dozens of machines. And then the client did user testing. And then the client’s QA department did even more testing. And then the client’s QA department did more testing throughout the whole time they were writing hard drives.

Remember the days when you updated applications with CDs or floppy disks? My god, for a while there it just wasn’t feasible to update installable applications over the internet. The end result? Software development firms spent a lot of time and money on QA. Same goes for game development companies.

My point is: if you know that one of your restraints is updating can be slow or impossible, you spend more time testing the application.

The App Store is slow

It’s true the App Store is slow when it comes to delivering updates. To me, this is just a known variable. Wouldn’t it be awesome if they had 24 hour turnaround? Sure would be. But it’s one of those tradeoffs you get with a closed system. If you want to trade it for an open system — build a web application. It’s not that hard.

I know it sucks testing your application. I know as a lone developer you don’t have the money to hire testers.

But think of the rewards. The App Store is something of a gold rush right now. A small group of people have made obnoxious profits off very little effort. There’s almost no overhead ($100 application fee? psh) — and anyone can submit apps. It’s a shitty closed ecosystem controlled by Apple. But it’s a shitty closed ecosystem of chocolate-filled pools lined with gold and supermodels dressed in nothing but $100 bills if you strike it rich.


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress