Parallax what?

Even if you’re not familiar with the term “parallax scrolling” you will certainly be familiar with the technique. Parallax scrolling is a 2d animation process that creates an illusion of depth by animating foreground layers faster than background layers. When you observe the landscape from a moving car, objects closer to the car appear to pass you faster than scenery further away. Parallax scrolling uses the same principle to trick the viewer into thinking they are observing a 3d scene.

Demo and Download

My demo web page shows one approach to building a vertical parallax scrolling interface:

View demo
Download source

You can scroll in the usual fashion, use the navigation menu at the right-hand side of the page, or the next/prev buttons that appear underneath each article. As you scroll, the page’s four content layers are animated independently of one another to create an illusion of depth.

The scrolling looks smoothest in Safari (at least that’s the case on my PC), but my demo should work in any modern browser.

Disclaimer 1: Because this is just an experiment I’ve not spent any time optimising the demo to work on mobile devices. I wanted to keep the demo lean ‘n’ mean, and not clutter it by sniffing mobile browsers and forking my code. On a production site you’d want to ensure that the site degrades gracefully on mobile devices, where scroll events and fixed positioning might work in unexpected ways.

Disclaimer 2: The navigation menu in my demo is inspired by the menu on the Nike Better World website. If you plan on implementing a similar menu on a production site, please be aware of its origin.

How it works

The articles and background layers are given a fixed positioned with CSS, and assigned a z-index so that the foreground layers appear above the background layers. The four layers are: small clouds, large clouds, balloon/landscape images, articles.

/* foreground (ballons/landscape) */
#parallax-bg3 {
    z-index: 3;
    position: fixed;
    left: 50%; /* align left edge with center of viewport */
    top: 0;
    width: 940px;
    margin-left: -470px; /* move left by half element's width */
}

Within each layer individual content elements are absolutely positioned. This was the most fiddly part of the process, since the elements need to positioned in such a way that they align in a pleasing manner when the user scrolls to any of the four articles. In this case it was really just a process of trial and error.

#bg3-1 {
    position: absolute;
    top: -111px;
    left: 355px;
}
#bg3-2 {
    position: absolute;
    top: 812px;
    left: 321px;
}
/* etc... */

A few lines of jQuery control the parallax effect, triggered by a scroll event. I was surprised how easy this was to achieve, it is literally just a handful of lines of code.

$(window).bind('scroll',function(e){
    parallaxScroll();
});
 
function parallaxScroll(){
    var scrolled = $(window).scrollTop();
    $('#parallax-bg1').css('top',(0-(scrolled*.25))+'px');
    $('#parallax-bg2').css('top',(0-(scrolled*.5))+'px');
    $('#parallax-bg3').css('top',(0-(scrolled*.75))+'px');
}

As you can see the CSS top property is used to move each layer as the user scrolls. The foreground layer is always aligned to the top of the document, while the movement of other layers is adjusted according to their depth. The lower a layer sits in the stack, the less distance it is moved.

The rest of the jQuery is concerned with controlling the navigation menus. When the user clicks a navigation button the page scrolls to the top of the associated article. In the event that the user has JavaScript disabled, regular HTML anchor links still allow the page to be navigated, but without any fancy pants animations.

Next steps

I’m sure there are plenty of other approaches to parallax scrolling, and hopefully my experiment provides a starting point for your own explorations of the technique.

Update

I have updated the demo so that each parallax layer is given a fixed, rather than absolute, position. This approach gives a smoother scrolling effect.

Robert Hoekman, Jr is a user experience designer and consultant who is best known for his books about interface design, Designing the Obvious and Designing the Moment. His self-published book Big Deal: On Being Famous to Almost No One tackles a far more personal subject. In Big Deal Hoekman, Jr recounts his rise to the top of the web design field, and describes how his craving for professional notoriety eventually devastated his personal friendships, marriage, and sense of self worth.

The form of celebrity Hoekman Jr discusses in Big Deal has been dubbed “micro-fame”:

My name is Robert Hoekman, Jr, and in certain rooms, under certain circumstances, at certain moments, surrounded by certain people, and when all these very certain things come together, I am a big fucking deal.

In other words, Hoekman, Jr might be unknown to the general public, but within the web design industry he is a bona fide rock star.

From the unique perspective that this notoriety affords, he takes the reader on a whirlwind tour of the conference rooms, hotel bars, book signings, photo opportunities and corporate retreats that consumed his attention as he rose the ranks of his profession. Along the way we rub shoulders with a veritable who’s who of the web industry: Matt Mullenweg, Jeff Veen, Jeffrey Zeldman, Caterina Fake, Luke Wroblewski, to name but a few.

Ultimately Hoekman, Jr’s craving for recognition and approval forces a crisis in his professional and personal life, and he has to face up to the root causes of his obsession with fame, and deal with the fallout.

This makes for fascinating reading, especially for a web design nerd such as myself, but I was left with the nagging feeling that Hoekman, Jr has – perhaps unwittingly – used his book about the pitfalls of fame as a platform to reinforce his cool kid credentials.

The nonstop cataloging of his professional achievements came across at times like bragging, and I wish he had dialed the self promotion back a notch. Even in the book’s later chapters, where he describes a dawning awareness that his obsession with fame is destroying his marriage, the laundry list of book signings and speaking engagements barely slows down. It is as if he wants to remind the reader that even though he no longer cares about being famous, he still is famous.

It is said that that pride comes before a fall, and in Big Deal Hoekman, Jr talks candidly about the flipside of his micro-fame: spiraling self doubt, professional rejection by Apple and Yahoo, isolation from friends, and the collapse of his marriage. It takes guts for a writer to expose their weaknesses so openly, but it feels a little like sitting in on someone else’s therapy session (in a psychotherapy cliché he lays much of the blame for his low self esteem at the feet of his mother). I imagine the process of writing Big Deal was extremely cathartic, but I question whether the experience of reading the book is equally enlightening.

The problem is that Big Deal is all about Hoekman, Jr, and frankly I’m not sure that his personal experiences provide enough material to do the book’s topic justice. If more of Big Deal had been devoted to examining the impact of micro-fame in a broader context – the cult of celebrity engendered by social networking services like Twitter, say – the book might be better rounded, and have a broader appeal.

Despite the reservations I have outlined above, I still found Big Deal very enjoyable. There is no doubt that Hoekman, Jr is a talented writer, and has penned a book that can accurately be described as a page turner. I finished the book in one day, and certainly wasn’t left unsatisfied. Hoekman, Jr paints a very human picture of his life as a web industry A-Lister, and in a field where technical manuals are the norm Big Deal is quite unlike any other web design book I have read.

Big Deal: On Being Famous to Almost No One will be released as an ebook through Amazon and iBooks later this year. Learn more about the book on Robert Hoekman, Jr’s website.

If you created a website that had “Works best with Netscape Navigator” you may be a #design_og
@_j12

If you remember Adobe PageMill, you may be a web design OG. #design_og
@meyerweb

If you’ve ever said that your “site looks better in Netscape Navigator” you may just be a web design OG! #design_og
@hudsonperalta

If you remember cleaning up bad Word-to-HTML markup by hand in a text editor, you might be a web design OG #design_og
@DataG

If u ever designed an interactive CD-ROM you’re a #design_og
@daveixd

If you remember having to make sure that your hex colour codes were “web safe” you might be web design OG #design_og
@stevecomrie

If you used .midi files for audio on your webpage, maybe you are a #design_og
@blueocto

If you’ve ever optimized a website for 14.4, 28.8 and/or 33.6 baud rate modems, you might be a web design OG #design_og
@digitaljhelms

If you still have some old business cards laying around where ur title was Webmistress, you’re a web #design_og (or OL as case may be)
@flynine

If you used 1×1 spacer gifs you may be a web design OG #design_og
@trafnar

If you ever thought while reading @alistapart article, “That’s great, but I’m still supporting IE3,” you might be a #design_og.
@dylanw

And here are my contributions:

If you ever designed a website that was hosted on Geocities, you may be a web design OG #design_og
@f6design

If you ever designed a website for 640×480 resolution, you may be a web design OG #design_og
@f6design

There are still plenty of goodies pouring in, so keep an eye on the meme…

Conditional comments have provided a great stopgap measure while we wait for obsolete versions of IE to fall into disuse, but as the market share of IE6 and IE7 has dwindled I’ve found myself relying on them less and less. In fact, I can’t remember the last time I resorted to a separate stylesheet to make an old browser behave.

Last week Microsoft announced that support for conditional comments will be dropped from version 10 of Internet Explorer. Like other modern browsers IE10 will treat conditional comments just like regular HTML comments, and ignore them. This is a very encouraging sign, since it means that Microsoft are confidant that IE’s support for web standards has reached a level where a standards compliant website ought to “just work” across all modern web browsers, without having to make special allowances for legacy rendering engines.

Of course, conditional comments will continue to be recognised by older versions of IE, but with IE6 and IE7 ready to disappear off the radar the time is clearly right for conditional comments to be put out to pasture. Goodbye conditional comments.

The Carrot Dangler

The Carrot Dangler will tempt you with promises of lucrative work in the future if you agree to take on their first project at a generous discount. Like the carrot that coaxes a donkey to pull its cart, this client hopes that the lure of more work will secure your loyalty, and make you receptive to the idea of lowering your fee.

It goes without saying that the dangling carrot will always remain just out of your reach, as elusive as the proverbial pot of gold at the end of a rainbow. If you do have an opportunity to work with this client in the future they will almost certainly plead poverty again, then dangle another carrot in front of you.

When confronted with a Carrot Dangler remind yourself that if they don’t have the money to pay you fairly now, they probably won’t in the future either. Don’t let the carrot tempt you into putting yourself at a financial disadvantage.

The Aspiring Designer

This type of client wishes they had gone to art school instead of business school, and sees the redesign of their website as a perfect opportunity to live out their fantasy of being a graphic designer.

The Aspiring Designer has little respect for your professional expertise, and secretly wishes they didn’t need to hire you at all. In this relationship they see themselves as the brain, and you as the brawn, little more than a Mac Monkey with the technical skills required to realize their grand vision.

You can spot an Aspiring Designer because at your initial meeting they will tell you they “have a few ideas for the site design”, and proceed to whip out a huge stack of ultra-detailed mockups that leave no room for you to do any real design work.

Think very carefully before taking on an Aspiring Designer as a client. The power they wield over you isn’t financial, it’s creative, and working for them can be a miserable, soul sapping experience.

If you do choose to work with the Aspiring Designer, make sure they understand that their role in your relationship is to define the business problem, and it is your job to propose a design solution. Make it clear that the appropriate solution may differ significantly from their preliminary mockups.

The Broke Startup

In the web industry the word “startup” has glamorous connotations, conjuring up images of overnight wealth, fame, and a jet-setting lifestyle.

When a prospective client describes their new Internet company as a startup you might imagine that they have come up with an idea for the next Facebook, YouTube or Twitter, and that untold riches await anyone who gets on board at the ground floor. The tradeoff? You have to build their website on the cheap, in return for equity in the company.

That probably sounds like an opportunity too good to pass up, but when you stop to think about it “startup” is just another word for “new business”, and the reality is that most new businesses never get off the ground. By offering you equity, your client is asking you to gamble your money on their business idea. In the likely event that your client’s idea fizzles, you’re left with a big handful of nothing.

Don’t let the allure of the word “startup” cloud your senses. You’re not operating a charity, and the fact that your client is a cash strapped entrepreneur doesn’t entitle them to special treatment. You should only enter into this type of business arrangement if you’re 110% committed to the startup, and are OK with the fact that your equity share will probably never amount to anything.

Yay or nay?

If you are approached by a client who fits one of the profiles outlined above, should you automatically put them in the “too hard” basket? Not necessarily. If you nip the problem in the bud it needn’t affect your relationship with the client. The trick is to spot the troublesome client coming, so that you can deal with them before any damage is done.

All pages are not created equal

A page is not a one-size-fits-all unit of measurement. There are many factors to take into consideration: the needs of the site’s audience, the complexity of the desired feature set, the quality of the design, the time required to perform testing, the level and complexity of database interaction, and so on.

Would you measure the effort required to develop a website like Facebook or Twitter in ‘pages’? Of course not, and I don’t think any website can be quantified simply on the basis of how many pages it includes.

Assigning a fixed price to a page, or assuming that one page is much the same as another, greatly increases the chance of underestimating the effort required to build a site. If you neglect to properly consider all aspects of a project’s scope then you cannot accurately quote on the job. Even if you meet your cost estimate it may be necessary to omit functionality or skimp on testing in order to stay on budget.

Selling yourself short

Selling page-based website packages isn’t just an inaccurate way to gauge project scope, it is a questionable way to turn a profit.

By treating a web page as a quantifiable unit with a measurable value, you position yourself as a service vendor rather than a web professional (for more on this distinction see Design Professionalism by Andy Rutledge). You risk being lumped together with every web monkey offering bargain basement website packages, and your client will view their relationship with their you as akin to shopping at a department store or supermarket, where every retailer offers an identical range of products.

Marketing your services on the basis of quantity also leaves you no option but to compete on price. If one web developer sells a ‘page’ for $200, and another for $100, why would a client choose the more expensive option? There is always going to be someone who can undercut you, and for a freelancer or small studio competing on price isn’t a sustainable business strategy.

Forget about pages

In the Web’s early years the concept of pages made more sense. Most websites were built using static HTML, their content comprised entirely of text and images. There was a certain equivalency between pages. Today’s average website is far more sophisticated, and may include dynamically generated content, AJAX interactions, a content management system, embedded video, integration with third party APIs and advanced social features. The myriad possible approaches to the task of building a website render the idea of a ‘page’ virtually meaningless.

A website’s architecture is an essential component of its specification, and understanding the way a site’s content is organised is key to establishing the project scope. But that understanding needs to be informed by more than just the number of pages the site will comprise. You need a firm grasp of the project requirements before you can think about quoting the job, and using page quantity as the sole gauge of effort will inevitably leave you under prepared.

This morning I visited a website that caused me to wonder if we’ve come so far after all. I was looking forward to experiencing the site’s typography, which I’d been informed was exemplary, and was surprised when my browser served up fallback system fonts rather than the embedded web fonts I was expecting. A warning message in the masthead informed me that if the fonts looked “kind of weird” I should switch to Chrome or Safari.

My guess is that the site’s designer had chosen a typeface that wasn’t properly optimised for on-screen display, and as a consequence the site’s typography didn’t fare well on certain browser and operating system combinations. Rather than adapt their design to suit a wider audience the designer decided to try and change their user’s behavior by instructing them to switch to a different web browser. As a web professional I was surprised to be admonished for choosing to use Firefox 4 – the latest version of a modern web browser – and I can only imagine what a less technically inclined visitor would make of the warning message.

Thankfully browser sniffing is still a rarity, but all too often I see evidence of designers who are ignorant of, or choose to ignore the fact that many embedded web fonts render in a sub optimal fashion on the Windows platform. For these designers the fact that the website looks nice on their own (presumably Apple branded) computer seems to be enough. Never mind the fact that 85% of the average website’s audience use the Windows platform, and will experience the site’s typography in a very different fashion.

Jeffrey Zeldman called the disparity between various browser and OS font rendering engines the “elephant in the room” – everyone knows the problem is there, but none of us wants to mention it for fear of spoiling the web font party. Sadly his warning seems to have gone unheeded by some. Too many web designers continue to make poor font selections, ignore the majority of their users, and jeopardize their website’s usability in the process.

Thankfully typeface designers are beginning to acknowledge the problem, and hinting their fonts for improved performance on the Windows platform. Recently the Skolar typeface, which used to look very shabby in Windows, was skillfully re-hinted by Ross Mills and now renders superbly. But the responsibility doesn’t rest solely with type designers – web designers and font vendors need to do their share too. Mills wrote an article for Typographica called The State of Webfont Quality from a Type Designer’s View in which he urges all parties involved in the production and distribution of web fonts to carefully consider the quality of the fonts being released. From my perspective that means web designers too: if we don’t choose our web fonts appropriately then can we really claim to be doing our jobs properly?

The case can be made that Apple’s approach to font rendering is superior to Microsoft’s, but that doesn’t give web designers an excuse for subjecting Windows users to a substandard typographic experience. Web design has always been about compromise and working within technical limitations. Trying to modify user’s behaviour by convincing them to switch operating system or browser won’t work, and designing for a single platform is simply irresponsible.

Instead, why not restrict our typeface choices to those fonts that have been optimised to render well on both the Macintosh and Windows platforms? There are plenty of well hinted fonts out there, and as the web font marketplace matures the number of choices will continue to grow. Yes, it requires patience and restraint, but restraint should be something we’re all used to by now – for years we’ve had to make do with the handful of fonts that come pre-installed on both Windows and Mac OS. Surely it won’t kill us to continue using a little of that self-control and limit ourselves to web fonts that render well for all our users, instead of designing for a minority.

Working with a local web server

Except for the very simplest sites, my web projects require PHP and therefore must run on a webserver with PHP installed. For testing purposes I have an Apache webserver installed on my local computer – I use XAMPP, which is a free Apache/MySQL/PHP distribution for Linux, Windows, Mac OS X and Solaris.

For each project I create an Apache virtual host, which allows the website to have its own domain root. This is configured in Apache’s httpd-vhosts.conf file:

<VirtualHost *:80>
    DocumentRoot "D:/jobs/my_project/dev/_svn_working_copy/www"
    ServerName myproject.local
    ServerAlias www.myproject.local
    ErrorLog "logs/error.log"
    CustomLog "logs/access.log" combined
    <Directory "D:/jobs/my_project/dev/_svn_working_copy/www">
	Options Indexes FollowSymLinks Includes ExecCGI
	AllowOverride All
	Order allow,deny
	Allow from all
    </Directory>
</VirtualHost>

The important thing to note here is that the DocumentRoot points at the www directory of my Subversion working copy, not at a sub-directory of my XAMPP installation, as would usually be the case. This allows me to keep the development version of the site in the same location as all my other project files, in this case: D:/jobs/my_project.

The job folder also contains Photoshop mockups, wireframes, image assets and any other files related to the project. Keeping these files all in the one spot makes it easy to backup the project – I simply burn the entire job folder to disc or an external hard drive.

Version control is not backup

While we are on the topic of backup, I think it is important to point out that your should never rely on Subversion alone as a backup solution.

It is tempting to think of a Subversion repository as an alternative to conventional backup strategies, since in many respects a repository seems like the perfect backup: it is stored off site, it is well commented, and it has a history of every change ever made to your project. But by relying on the repository for backup you are putting all of your eggs in one basket. If the repository is ever corrupted you will lose your entire development history! Sure, you still have your local working copy of the site, but the ability to roll back to a previous website state or refer to old code is lost forever.

To guard against this possibility it is important to perform regular exports of your working copy, and archive these copies using your regular backup method. Subversion has an export command for this purpose.

Deploying to a live server

When it comes time to deploy your website to a production webserver, the simplest approach is to simply upload your working copy via FTP or SFTP. This method should require no major changes from your existing workflow, and has the advantage of working with any webserver. If your site resides on a shared hosting account then this is probably your only option.

There is just one gotcha: Subversion creates a bunch of .svn folders inside the working copy, which it requires to work. They contain sensitive information such as your repository URL, which you probably don’t want to broadcast to the whole world, so it is important to make sure that these files are omitted from the upload process. Any decent FTP client can be configured to filter out particular files or folders, so make sure to create a filter that ignores .svn directories. I use Filezilla, which does the job nicely.

If Subversion is already installed on your production web server (or you are able to install it yourself) and have shell access to the server, then you have another option available to you.

Instead of uploading files to the server from your working copy, you can checkout a working copy of your repository trunk to the production server. When you are ready to publish to the live site you just need to update the server’s working copy and any modified files and folders will be deleted/renamed/downloaded automatically.

The advantage of this approach is that it is largely free from human error – there is no chance you might forget to upload a modified file, or that one developer will accidentally upload an old file over a newer one.

Explaining how to work with Subversion on your production server is beyond the scope of this article (plus, I’ve never done it before!), but if you dig a little you will find tutorials online.

Update 11 March 2010: A couple of readers have pointed out that the alternative deployment approach mentioned above requires additional steps to hide the .svn directories on your production server. Please read the comments below for further information.

Making friends with Subversion

As I mentioned at the outset of this series, it took a couple of goes before I had an “aha!” moment and realised how Subversion could improve my workflow, but once everything clicked into place I didn’t look back. Hopefully this article has given you some pointers about integrating version control into your own web development process.

There is plenty of technical detail I haven’t covered, and for that I recommend checking out the free Version Control with Subversion book, and the excellent TortoiseSVN documentation. If you have any questions about my approach, or suggestions based on your own experiences with Subversion, please leave a comment below.

Icons in this article are courtesy of Visual Pharm.

Structuring your repository

Before you import any data to your Subversion repository you will need some top-level directories to help organise your project. There are no set rules dictating how you approach this, but the recommended repository layout is to create trunk, branches and tags directories:

/trunk
/branches
/tags

Trunk: This is where you store the “main line” of development. It is a snapshot of the current state of the project.

Branches: A “branch” is a copy of the project, and allows you to carry out a separate line of development without breaking the trunk. Once you are happy with your changes they can be merged back into the main code base.

Tags: A “tag” is an archival snapshot of the project at a given point in time.

Whether or not you create branches and tags entirely depends on your own approach to version control.

Tags are commonly used in software development to capture a snapshot of a stable release of an application, but are not necessarily applicable to websites, where changes tend to be pushed live as soon as they are made.

Branching is useful when multiple developers are working on the project, but may be a redundant concept for a solo developer. Two scenarios where I can see branching would be useful are during a website redesign, or when adding a major new feature to a site. Development of the live site continues in the trunk whilst the upgrades are carried out in a branch.

Even if you don’t plan on creating branches or tags I still recommend sticking with this conventional directory naming structure. If another developer ever needs to access your repository the trunk/branches/tags structure will probably be one they are already familiar with, and it also gives you the flexibility to create branches and tags should the need ever arise.

What files to keep under version control

The only files I keep under version control are those that are required to compile and deploy the site: the source files, any files that are required on the live web server, and a copy of the site’s database.

For a typical website I create two additional folders inside the trunk:

/trunk
    /db
    /www
/branches
/tags

The www directory represents a web server’s public http directory. This is where most of the project files and folders live. The db directory is where I store a dump of the site’s MySQL database (more on this in part 3 of this series).

If I was working on a Flash project then I would have additional directories for my Actionscript and FLA source files:

/trunk
    /db
    /www
    /src
    /lib
/branches
/tags

None of these folder names are set in stone, and you should choose a structure that suits your work methodology.

Creating a working copy

To begin working with your repository you need to checkout a working copy. To do this, create a folder somewhere on your local computer, and give it a name that makes its purpose obvious. I call mine _svn_working_copy, and create it inside the job folder for the particular project it relates to. For instance, my folder might reside at D:/jobs/my_project/dev/_svn_working_copy.

Right-click on the directory you created, and choose SVN Checkout from TortoiseSVN’s context menu. In the Checkout dialog that appears, enter the URL of your repository trunk.

Once the checkout is complete your working copy should now contain the db, www, and any other directories you created in the trunk.

(You might notice that each directory in your project contains a folder named .svn. TortoiseSVN requires these folders to do its job so make sure not to delete or edit them!)

Now you can start to add files to your project, and edit them as you would usually. Remember that the www directory represents the site’s root level, so your index file should be stored here, along with any other files and folders required for the site to function.

You might be wondering “What if I need run my project in my local web server? Shouldn’t I check out the working copy to my Apache webroot?”. That’s what I initially thought too, until I realised that Apache could be configured to read files from any directory on my computer. I’ll explain how (and why) I do this in part 3 of this series.

Keeping a database under version control

If your site relies on a database then you need to keep that under version control too, otherwise you lose synchronisation if you ever need to roll back to a previous website state. But because the database is stored outside of a website’s public html directory it needs special consideration to ensure it is included with Subversion commits.

I mentioned earlier that my SVN trunk includes a directory named db. This is where I place a dump of the site’s MySQL database. In my case this is a manual process: I use PHPMyAdmin to export a .sql file which I copy into my trunk’s db directory, overwriting the previous version.

I suspect it is possible to automate the process of exporting the database from MySQL into the db folder, but for now I’m happy enough to do it manually. Like the other steps in the version control workflow it quickly becomes second nature.

Making commits

When you have finished editing the files in your working copy it is time to commit them to the repository. In TortoiseSVN this is accomplished by right-clicking the folder in which your working copy resides (or any sub-folder or individual file) and choosing SVN Commit from the context menu.

At this point you have the option to add any non-versioned files to the repository, after which any new or modified files are uploaded to your Subversion server and stored in the repository. The next time anyone browses or checks out the trunk they will be able to view your changes.

Commenting your commits

It is good practice to accompany each commit with a descriptive message explaining the changes you have made. In a team environment commit log messages are a vital means of communicating with the rest of the team, but they are just as important for the solo developer. Well documented commits help you recall every change you make to your project, when you made it, and why.

Trust me, you don’t want to be the dunce, who commits with blank messages, or with meaningless ones like “Fixes”. Your team will hate you. You will hate yourself after a month, when trying to discover what the hell this code does in your brilliant project.
–Petyo Ivanov, The importance of commit messages

Commit frequency

How often you choose to commit changes to the repository is a matter of personal preference. Once a day, twice a day, ten times a day – it’s entirely up to you.

I like to make my commits fairly frequently. This makes it easier to review the changes that I’ve made, and also keeps me focussed on the task at hand: the commit message acts as a goal for the coding session. Also, I get a small glow of satisfaction each time I make it commit, like ticking off an item on a to-do list!

In the final part in this series I will talk about working with a local Apache development server, and deploying a version controlled website to a live webserver.

Read part 3 »

For a long time I steered clear of version control, dismissing it as too complex, or something that was only useful for large development teams. I took Subversion for a test drive, but didn’t really “get it”, and decided version control wasn’t for me.

I changed my tune earlier this year when I was employed to work on a project that was already under version control. I had no choice but to get up to speed with Subversion, and once I got the hang of it I was excited to discover that version control streamlined my entire workflow. I now use Subversion for all of my web projects and consider it an integral part of my development process.

My approach to Subversion is geared towards solo web developers like myself, and is fairly easy to grasp. I won’t delve too deeply into the inner workings of Subversion and its commands – this will be more of a conceptual overview of setting up a version control workflow:

Part 1: Getting started with version control
Part 2: Working with Subversion repositories
Part 3: Servers and deployment

What is version control?

In a nutshell, version control allows you to track changes made to a file over time, and roll back to a previous state when you mess up. This might not sound too different to the traditional “save as…” technique offered by virtually every software application, but a Version Control System offers considerably more functionality than simply appending “_v01″ or “_v02″ to your file names. Some of the advantages of a Version Control System are:

• Roll back. Jump back in time and revert a file, folder, or even the whole project to a specific historic state. If you make a mistake in your code you can simply revert to the last good version of the file you are working on.
• Revision messaging. File revisions can be accompanied by messages explaining what changes were made, and why. This makes it possible to track the evolution of a project over time.
• Branching. If you need to test out new features in your project without disturbing the main line of development, you can “branch” your code and continue development in a separate sandbox. Later, you can merge changes back into the main code base.
• Work with a team. If several people are working on the same project, version control helps to synchronise changes so that one team member doesn’t accidentally overwrite another’s work.
• Work remotely. A version controlled project can be accessed from anywhere, any time. This is perfect for geographically remote team members or developers who work from multiple locations.

Why use version control?

In my pre-Subversion days I relied on an ad-hoc backup system whereby I would periodically create a manual snapshot of the project I was currently working on by copying the entire project source to a new directory. I might make a backup once a day, or perhaps every two days. If the changes were small, I might not make a backup at all.

This approach worked well enough, but left me wide open to data loss. Reverting to a previous project state could be a tedious task, requiring that I backtrack further than was strictly necessary.

I also lacked comprehensive metadata about the changes I was making. I did keep brief notes with each backup, describing the changes I had made since the last snapshot, but these notes provided only “broad brush strokes” information about my edits, and lacked detail about which specific files had been modified.

A Version Control System helps to address these problems: snapshots are taken of revisions much more frequently, code changes are easier to document and track, and recovering from coding mistakes is much easier.

Version control for web development

When setting up a Version Control System my initial challenge was to find a workflow that worked for me as a solo web developer. Most of the explanations of version control I read were aimed at software programming teams, and it wasn’t immediately obvious to me how I fitted into the picture. To help me choose a version control approach that suited my own requirements, I began by listing the key components of my web development process:

• Most of the time I work alone on projects, not as part of a team
• I work on projects from the office and from home, using two different computers
• During the development phase of a project I work from an Apache web server, hosted on my local computer
• Most of my websites rely on a MySQL database
• My websites are hosted on a range of web servers, usually in a shared hosting environment, and in many cases I am not free to choose the hosting solution

With those considerations in mind, I needed an approach to version control that allowed for:

• Remote access to the Subversion repository
• A working copy of the repository that could be accessed by my local web server
• The website’s database to be under version control along with the source files
• A deployment process that would work in a typical shared hosting environment

Creating a Subversion repository

The first step in working with Subversion is to create a repository. A repository is a store of data, which holds all of your project files, much like a standard file-system. A repository does a lot more than that though:

What makes the Subversion repository special is that it remembers every change ever written to it: every change to every file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangement of files and directories.
–Version Control with Subversion

The simplest way to create a repository is on your local machine, a task that is made extremely easy by TortoiseSVN (a Subversion client). A local repository is perfect for cutting your teeth with Subversion, but has a major drawback: it can only be accessed from one computer. A remotely hosted repository is a far more powerful and flexible option.

To create a remote Subversion repository you are going to need a web server with Subversion installed. This is not as daunting as it may sound. Many web hosting companies offer Subversion with their plans (I use Dreamhost), or you can choose a Subversion hosting specialists such as Unfuddle, Springloops and Beanstalk.

It is important to note that your Subversion repository needn’t be on the same server as your website. In the development environment I describe in this article there is never any direct communication between the repository and the live web server.

Choosing a Subversion client

Once your Subversion repository is up and running, you need a way to access it. A Subversion client allows you to to read data from your repository (“check out”, in Subversion parlance), write data to the repository (“commit”), and perform other useful actions such as branching, tagging, and merging.

I work in a Windows environment, so TortoiseSVN was an obvious choice for my Subversion client. TortoiseSVN installs as a Windows shell extension, and all of its functionality is accessed via the Explorer context menu – in other words, by right-clicking on a file or folder. This approach is very unobtrusive, and soon becomes second nature.

I won’t go into detail about how to install and use TortoiseSVN. The program is very well documented and there are stacks of online tutorials if you get stuck.

In part 2 and part 3 of this series I will refer to TortoiseSVN when explaining some of my processes. For other Subversion clients the process will be slightly different from what I describe, but the basic principles remain the same. Apple users will find that there are plenty of Subversion clients for the Mac, though I haven’t used any of them and can’t make a personal recommendation – if you have a favourite you can leave a comment below.

In the second part of this series I will explain how I structure my subversion repository, how to create a working copy of your repository, and how to commit changes to the repository.

Read part 2 »