I’m not exactly sure how far back OS X support goes for these downloads, but I was able to get them set up on Snow Leopard with no problem.

GitHub also has a free level of service for public repositories, but Bitbucket gives you free private repos as well.

Just follow these easy steps:

1. Get a bit bucket account – https://bitbucket.org/
2. Download and install Mercurial – http://mercurial.selenic.com/
3. Download and install Source Tree – http://www.sourcetreeapp.com/
4. Generate SSH Key – https://help.github.com/articles/generating-ssh-keys (ignore the github specific stuff)
5. Add SSH Key to your bitbucket account Manage Account ► SSH keys ► Add key
6. Clone and enjoy!

Sometimes, but sometimes they simply require more information before they can decide for themselves if they are interested in being a lead. Asking for twelve form fields worth of personal detail may put off more casual inquirers and prevent them from ever becoming a prospect to begin with.

Consider this quote from a recent article from Web Designer Depot, How puppy training is the key to creating better forms:

While companies, and thus web designers, have a vested interested in gathering as much user information data as possible, doing so too early in the process will alienate users and reduce ROI. If, however, a company requests only the minimal amount of data necessary and then builds a user’s trust, gathering more detailed information later in the process will be much easier.

The minimum needed for a conact request is an email address. Other helpful information is a name and a message field, but these shouldn’t be required fileds as these details (and anything else you want to know) can be requested when you actually reach out to contact the user. All you really need to know up front is that someone wants to communicate with you.

Web forms are a case where less is more, but if you are in doubt, perform some usere testing to determine actual conversion rates of longer and shorter request forms.

1. Users should be able to easily find the products they want, need or not aware that they want and need.
2. Users should be able to easily purchase these products.

The design and functionality of an e-commerce site should never contradict these principles.

Recently, I went through my time logs to see what I had done during the last six months that could be added to my portfolio. It turns out, that of all of the decent size projects, there were nine that were discrete enough to add to a portfolio. Of these, seven were either not public facing or had not yet launched. The two remaining projects happened to be the least impressive of the nine and not the best show pieces for a portfolio.

For the last six months of working full time I have nothing substantial to show for it. I worked full-time during that period, and I feel like I met a great many challenges and solved some unique problems in that time. So why not present some of these in a more abstract fashion?

Using a tool like CodePen, you can create a working example and present your solution to these problems by removing the proprietary or non public facing parts and focusing on the problem and how you solved it in generic terms.

For example, last month one of our clients needed a way to show their advertisers how running commercials during the Super Bowl affected consumer traffic on their site to the benefit these advertisers. This required showing traffic statistics from before, during and after the game. They wanted to display charts and graphs that looked highly polished but were flexible enough to quickly output data for a range of advertisers.

The solution was to create dynamically generated charts and graphs using raphael.js to draw and animate while allowing the client to easily manage the data with a customized WordPress backend. Our implementation of this worked out very well (if I do say so myself), but since the live site is only accessible to the advertisers involved, there’s not really anything that I can show for my effort.

That doesn’t mean I can’t make something out of this to show what I’ve done. I can create a generic version of the working charts on CodePen and create a blog post explaining in detail the thinking that went into our solution without exposing any of the client’s proprietary data.

In the next several weeks I plan on doing exactly this with several of the projects I have worked on lately. That way, I will have something to show for my self.

So, if you find yourself with an empty portfolio even though you’ve been working hard, maybe it’s time to make some posts about the problems and challenges you have solved and not to worry about not being able to show the actual client project live in the world. At least it’s something, and you never know, it may help someone else with a similar problem, too.

I’m always intrigued to discuss WordPress with our PHP developers and I frequently joke that it is going to be their replacement. For their part, they are a bit contemptuous of WordPress’s use, and while I’m pretty sure that they don’t really feel threatened by it, they definitely seem to feel that it’s beneath them.

I’m sure that many back-end developers who work on their own custom platforms feel this way about WordPress, but the simple truth is that WordPress is a well-made, robust platform that is far beyond what most individual developers and small teams can produce alone.

WordPress is the result of almost a decade of collaborative development and evolution. It is an extensible platform with strong theming and plugin capabilities with a huge community of users and contributors. While custom web app development can focus on specific problems and tasks with more focus, WordPress offers a way to rapidly create data centric applications appropriate to a wide range of situations.

Personally, I believe that both bespoke apps and WordPress driven sites have their uses, and it comes down to using the best tool for the job. There is an overlap in functionality to be sure, and I believe this is where php developers negative view of WordPress creeps in.

WordPress’s approach to programming may differ significantly from that of the individual developer or small team simply because it must cover a wider range of solutions for its users. WordPress has to maintain an architecture for all types of plugins and themes, and necessitates a different structure than more specialized web apps.

In the end, neither approach is superior, but as far as I’m concerned WordPress definitely has earned its place in the web development toolbox.

I have also made an Automator application for executing this script. I’ll release that too after I’ve packaged it up a bit better.

Whatever you do, don’t let the client think that you are charging extra for doing the same work as another professional. Not only will that look bad, but it’s also inaccurate.

Unless you are running the bargain basement web shop, there will always be someone out there who will undercut you on price. Charge fairly for the work you do or both you and the client will suffer.

While I do believe that eventually he will be right, I don’t think we are at the point where this is justified. There are, after all, very few devices out there that even have high-dpi displays, so the market share can’t be that large.

As with all web design and development, the requirements of any site or project must be guided by business goals and user needs. For the majority of sites, I don’t think their is a legitimate need to justify the expenses involved in designing for high-dpi. I think Marco’s suggestion is slightly premature skewed by two factors: his audience is more likely to view his sites on a high-dpi display and he uses high-dpi devices himself.

Here are a few things to consider when choosing to design with high-dpi in mind:

The Cost In Design and Development

Setting aside the cost of the equipment, there is an actual cost associated with creating high-dpi ready assets. Original designs will require time to create additional versions of all of the graphics, and redesigning existing sites may require recreating assets completely to take advantage of the high resolutions.

On the development side, testing these new assets will become necessary, and additional time will be needed to create responsive breakpoints for high-dpi. And while responsive design techniques are coming along fast, there still aren’t any standard ways to cleanly handle serving image and media assets based on display properties.

Depending on the scope of the project this may or may not add up to a large amount of time, and someone will have to pay for it. The cost may be passed on to the client or the the web developer may just end up eating it.

The Cost To The User

High-dpi assets will also cost the end user in terms of bandwidth. The file size for an image made for a high-dpi display may be as much as four times as large as its traditional 72-dpi counterpart, and this extra size can hit users bandwidth caps and load times for those on slower connections.

Currently, the most common devices with high-dpi displays are iPhones and iPads, and usage of both of these is likely to be on a 3G connection much of the time. This means that load times for high-dpi sites viewed on these devices could become excruciating as many sites already load slowly when serving up normal images. Also, 3G plans have fairly low data caps, so overage charges become a very real concern.

How Bad Is Really Bad, Anyway

Are standard sites really that bad on high-dpi display? I don’t have a Retina Macbook Pro, but I do have a Retina iPad and an iPhone 4S, and I admit there is a difference in image quality compared to standard devices. Standard resolution content does look worse on these screens, and there is an opportunity to make sites look more beautiful on high-dpi displays. The thing is, it doesn’t look that bad.

Images are a little fuzzy, but they’re not terrible. Often you have to look closely at edges to see the problems. Web fonts may even look better on high-dpi displays due to their vector nature, if they are well-made, professional fonts and the designer adheres to proper typographic conventions.

Regardless, I have yet to see a case where standard resolution assets on a high-dpi display render a website unusable or hinder accessibility. At the end of the day, that is what is most important, and not slight concerns about asthetics.

The Verdict

So if neither the gains in quality nor the market share of high-dpi displays are really that significant, and the costs to designers, developers and users are very real, does it make sense to spend the time and money to design and develop for high-dpi? Are we ready? I cannot stress enough that this decision needs to be made on a site by site basis, but in the vast majority of cases the answer is, probably not.

But someday we will be…

When I followed the link to NeilCarpenter.com from Chris Coyier’s tweet I was on my mobile phone. I was immediately presented with a pleasant looking, fully responsive site. The original tweet was pointing out the game-like slider on the about page, but I was struck more by the responsiveness of the layout.

In the mobile context, navigation is easily accessible at the top, jQuery interactions and loading animations are smooth and the content is well placed and easy to read. In all, the site seems to have been very thoughtfully planned out, and this is in evidence in his post about the design. It’s clear from this post and the site itself that he has read and fully understands Ethan Marcotte’s responsive design techniques.

Looking at the site on a desktop reveals another great looking view of the site and gives me more appreciation for what was done in the mobile version. I especially like the main navigation that follows you as you scroll. It’s much more understated than the top navigation bar, but the icons make it clear what each link does.

Nice job, Neil.

There are some who dismiss the contribution of front end developers and consider us just “html guys”, but there is so much more to what we are responsible and what we can do, when given the chance. Here are just some of the things front end developers are responsible for:

• Clean, semantic markup - We do write html code, and this is the foundation upon which we build our craft. Standards compliance, cross browser compatibility, accessibility, and the coding part of SEO all start here.
• JavaScript interaction - Front end developers are responsible for making sure that the site’s JavaScript works correctly, is usable, is fluid and has an acceptable fallback for less capable user agents and browsers.
• Ensuring usability - Usability starts with design, but it falls to us to make sure that the designer’s vision is carried out properly, preserving usability. We must also be aware of and help resolve any usability issues that may arise as the site is built.
• Accessibility - The way the user portion of a site is coded and the interaction is wired up is our responsibility. The largest opportunity to effect accessibility for good or bad lies with the front end developer. We must ensure that a site is accessible to those with disabilities or with alternative devices or other special consideration.
• Cross browser compatibility - The poor suckers who have to deal with old versions of Internet Explorer? Yeah, that’s us.
• SEO - Proper use of title attributes, page heading tags, alt tags, and proper meta tags are our responsibility. SEO has much more to do with having great, well thought out content, but there are coding concerns, and we deal with those.
• Dealing with legacy code - We must frequently deal with existing sites that are constructed from tables or worse. It turns our stomachs, but if we are not being mandated to completely revise a site’s code, we must know how to understand and work with this old code.
• Continue learning - We must stay constantly up to date with all of the latest technologies and best practices. HTML5, CSS3, JavaScript libraries, responsive layout techniques and many other items are constantly moving forward and evolving. We must evolve too, or we’ll end up creating today’s version of table based layouts and Flash splash screens.

This list is not exhaustive, as the extent of our job duties are constantly changing, but this does present the case that we perform an increasingly important role in web development. Our work has a direct effect on the experience of the end user, and good front end development can really help make a site successful.

More importantly, we deserve some respect for the work we do. So please, don’t call us HTML guys.