We all make mistakes. Whether in our design and development work or just in life in general, we all do it. Thankfully, even the biggest mistakes carry valuable lessons.

As a contrast to the many Web design articles that focus on successes and what we can learn from those triumphs, this article looks to the other end of the spectrum to explore what failures teach us.

Along the way, I will share stories of some of the missteps I have made in the course of my career and the lessons I’ve learned in the process — being ever mindful of composer John Powel’s words:

“The only real mistake is the one from which we learn nothing.”

Mistake #1: Putting Process Over Projects (And People)

Anyone who has been designing and developing websites for any amount of time has come up with a process for working. Having a process is good, but be careful that it does not overshadow the project itself or the people involved.

I was reminded of this a few years ago in a project that was going badly. The simple reality was that I was not getting along with the project manager who was appointed by the client. Our personalities clashed almost from the start, as I found her feedback and requests to be misguided and her personality abrasive. At the same time, I am sure she found me unhelpful and combative because I was unwilling to honor all of her requests.

As frustration grew, I tried to fall back on our process as a way of adding structure to the relationship and trying to get it back on track. If she made a request that took us outside of our normal process, I explained how we could not do it without setting the project back in both time and budget. The worse the project got, the more I deferred to our process, until the client, exasperated to the limit, told me that I seemed to care more about our process than the project.

My plan had backfired. I had tried to lean on our process in order to fix the problems, instead of having a difficult confrontation and dealing with the real issue — the fact that personality clashes were becoming strained to the point that nothing was being accomplished.

Eventually, we reset the project by calling for a meeting to clear the air and address the problems honestly so that we could move forward. While I continued as the project lead on our side, I brought in another team member, someone who did not have a rocky history with the client’s project manager, to handle the day-to-day communications. Even though she acted as little more than an interpreter for me in many cases, the fresh voice and personality from our side did wonders for the relationship, and the project manager responded to our new team member much better than she had to me.

Additionally, we looked at the client’s requests a little more deeply and, rather than dismissing them outright because they deviated from our normal process, tried to identify the reasoning behind each request so that we could honor them in the spirit in which they were made (which we normally do anyway). We realized that those requests didn’t really affect our normal process in a big way. Any deviation was minor, and the relationship and the project were much better off with the flexibility in our process.

People are more important than the project, which is more important than the process.

Of course, you need to strike a balance. A process exists for a reason, and if you abandon it whenever anyone shows resistance, then there is little point in having a process at all. That being said, any good process has some flexibility to accommodate the different needs of clients and projects.

Lesson learned: Followed blindly, no process will save you from having to deal with difficult personalities or bumps in the road. A process is meant to help a project along, not to be hidden behind when the going gets tough. For additional reading on client communications, see my previous articles, “Keys to Better Communication With Clients” and “How to Deliver Exceptional Client Service.”

Mistake #2: Telling Instead Of Showing

I frequently speak with clients about their website needs. I listen to their concerns and the issues they’re having with their current website, and I tell them how we can meet their needs. Note that I said I “tell” them how we can help, when I should usually be showing what we can do for them.

This might not seem like a big difference, but it could mean the difference between winning a new project or losing it to someone else — which is exactly what happened to me recently.

A few weeks ago, I was informed by a prospective client that they had decided to work with another provider. Whenever this happens, I am gracious and thank the client for considering us in the first place. I also ask them what the deciding factor was. In this case, they loved our proposal and solutions, but another company had given a detailed demonstration of their preferred CMS and showed how they would use it to keep the website up to date. That company showed them instead of told them.

I’d be lying if I said I didn’t kick myself upon hearing this feedback. I would have been happy to give this client a CMS demonstration, but they didn’t ask, so I didn’t offer. Instead, I answered their questions — all the while thinking I was giving them what they wanted.

Certain things are more effective when shown instead of told. (Image: Joe Penniston)

The other provider’s CMS is not necessarily easier to use than the one I was offering, but I never even made that case because I told the client how easy our solution was to use, instead of showing them.

Lesson learned: Talk is cheap. Regardless of whether the client specifically asks for a demonstration in your proposal, showing them goes a long way by backing up your words.

Mistake #3: Not Informing Clients Of Staffing Changes

Staffing changes are a reality in this industry. Team members move onto other positions and opportunities, but business must go on. Projects need to be finished, and websites and clients need to be supported. As one team member departs and another joins, you will establish a plan for existing projects and clients, assigning responsibilities and tasks as needed. Still, however solid and measured your plans may be, don’t neglect to inform your clients of these staffing changes.

I learned this lesson when a longtime colleague recently left for another position. We had a plan in place for the transition, a plan that involved him working with us part time to continue handling certain clients and services. The impact on our clients would be minimal, and I decided that we didn’t need to inform them of the changes because the services we provided would not suffer and the change in our staff would likely go unfelt. I was wrong.

It didn’t take long for one of our clients to reach out to my departing colleague. My colleague’s work emails were now being forwarded to me, so I received the client’s request. We made the changes requested, and when I emailed the client to notify them that the work was done, I also explained the change in staffing to account for why the response was coming from me. As you can probably guess, they were surprised by this news, and what should have been a non-issue suddenly became an issue, simply because the client hadn’t learned of this sooner and was taken by surprise.

While some staffing changes are certainly not appropriate to discuss with clients, others really do affect clients in a pretty big way. A person may be the client of a company as a whole, but if their day-to-day interaction is with a particular team member, then that team member “becomes” the company in their eyes. If that team member ever decides to leave, the client could feel as though they are switching providers, even though the company is still more or less the same.

So, be proactive in informing clients of staffing changes. By explaining your plan for the transition of responsibilities with their account and reassuring them of your continued support of their company, you show them that, despite the change in staffing, you are still thinking about them and their needs.

Mistake #4: Focusing On Money At A Time Of Transition

Speaking of transitions, another reality in this industry is that clients sometimes decide to move onto another provider. When this happens, there is a period of transition away from your services, and you will likely need to be involved in that transition. This can be a strange and uncomfortable time, in part because you’re concerned about money.

Ongoing clients have an incentive to pay their invoices because they want to continue working with you. Clients who switch providers are worrying because of the possibility that they won’t honor any outstanding invoices — including time spent helping them transition away from your services.

This situation is delicate and needs to be handled case by case. Their reason for leaving, their overall payment history, how much they currently owe you (if anything), and how involved you will need to be during the transition are all factors that will determine how you handle the situation. The big lesson I have learned, however, is that dwelling on exactly when you will get paid during this time of transition, which is often a time of uncertainty and even fear for the client, is rarely wise.

When I’ve focused on payment and gotten aggressive in making sure the client understands their financial obligation to us, those clients have actually turned out to be less likely to settle their accounts in good time than clients whom I approach more softly.

Providing outstanding service to a client during a time of transition is the best way to end a relationship. If the relationship ends on a positive note, then the client will be more likely to pay what they owe and to say nice things about your company, because the last impression you’ve left them with was helpful and positive.

Again, how you handle such situations will vary. If the breakup is messy, or you are owed a substantial amount of money or lawyers have to get involved, then you would handle that transition differently than if you had a good client who was leaving simply because you were no longer a good fit.

For more tips on handling client payment issues, see “Dealing With Clients Who Refuse to Pay.”

Mistake #5: Looking To The Past, Instead Of The Future

When we make decisions on a project, we often look for relevant data to justify our decisions. Referring to website analytics and usage data can help us make informed decisions, but remember that all of this data refers to the past, not the future.

The Web industry is constantly moving forward, and if we make our decisions based solely on data gleaned from past usage, then the solutions we develop will be perfectly suited to those past situations, not necessarily future ones. This happened to me about a year ago when we were working with a client to come up with a mobile strategy for their website. While we absolutely wanted to make the website responsive, the scope of the project and the budget simply did not allow it. Plans were made and a budget allocated to redesign the website the following year, and a fully responsive design would certainly be part of that project, but for now, a separate mobile-only website would be our short-term solution.

As with many mobile websites, our plan was to include only a small, targeted subset of the enormous content archive found on the current website. Looking back now, it was a mistake. Unfortunately, content parity wasn’t an option, so to determine what content to include, we looked to the analytics to see which pages mobile users were accessing. Office locations and directions, leadership team biographies, and contact details were the most popular pages being requested by mobile users, so that was what we included on the mobile website. There was, however, a problem with this logic of including only currently popular content on the mobile website: It did not account for future needs.

As we were working on the mobile website, the client began to focus on their blog. They formed a team of authors among the subject matter experts in their organization and began publishing a lot of quality content — content that quickly became popular with their audience. This new blog content was often promoted and shared via social media, and many visitors accessed those links via mobile devices.

You can probably see where this is heading. Because we had no data to show that the blog would be popular on mobile devices, we left the blog off of the mobile website. When the blog picked up steam and attracted interest from users on social networks and mobile devices, the website we had developed became a major problem. The experience would be as follows:

1. A mobile user would see a comment about or link to an article in social media and, being curious about the article, click the link.
2. The mobile device would navigate to the blog article on the full website, but then quickly redirect to the mobile website’s home page.
3. Because the blog was not accessible from the mobile website’s menu, the visitor had to tap the “View full website” link and, on their small phone, try to find the blog on the full website. If that’s not frustrating, what is?

Obviously, this experience was exceedingly poor, and very few visitors went through the entire process just to read the article. Most just left when presented with the mobile home page, instead of the article they were hoping to see. Even though we knew from the start that this mobile-only website was temporary, had we more effectively planned ahead and not based our decisions solely on analytics from the past, we may have been able to avoid this problem and develop a better solution.

In this case, the answer was to kick off the responsive redesign project sooner and do away with this separate mobile-only website and its subset of content. The lesson we learned is that we have to look to both the past and the future when making decisions on a project.

Making new mistakes helps you learn new lessons. (Image: Elyce Feliz)

This is why clients hire us in the first place — not only for our execution, but for our expertise. This expertise includes knowing where the industry is headed, what principles have to become an integral part of the experience (content parity) and what new technologies or approaches we can bring to a website today to ensure that it works well tomorrow.

The Value Of Mistakes

All of the blunders covered in this article are ones I’ve made that either took a project off track or strained a relationship or made a product far less successful than it could have been. As soon as I realized each mistake, I wished I could jump back in time and have a do-over.

Well, I’ve yet to find that elusive time machine, but I do get do-overs of sorts. Every time I encounter a similar situation, I am able to make a better decision as a result of having learned the lesson from the previous mistake. That is my do-over, and that is the value of learning from one’s mistakes.

We all make mistakes. (Image: opensource.com)

What about you?

What mistakes have you made, and what lessons have you learned from them? Not many folks like to talk about their mistakes, disappointments and things that just didn’t work out, but quite often they’re just as useful as all those amazing success stories you can read about in hundreds of books and articles. What tools worked for you and which didn’t, and why? Please share your stories and your thoughts with us by using the hashtag #smworkflow!

(al)

© Jeremy Girard for Smashing Magazine, 2013.

An unexpected player has entered the fray with a tool that makes HTML5 mobile development easy while also directly addressing some of the shortcomings of Web technologies in mobile apps. See a demonstration of how quickly you can begin creating your own apps using HTML5.

Alpha Software has releases the all new Alpha Anywhere bringing a single environment for the rapid development and deployment of high end business apps for all devices and any OS.

Squeeze pages are easier than ever to create with the cutting edge SalesPress Pro 2.0 Wordpress Theme template generator, RickPorter.org has posted an in-depth new demonstration video.

A giant case shows Russian hacker gangs remain a potent force, and provides fuel to arguments for mandatory sharing of computer attack information between industry and government.

Deployment is moving a website from a local environment to live servers. What seems like a simple thing can actually be quite complex. There are absolutely loads of ways to go about it. They range from user friendly software and services, to more complex command line tools, to full blown systems with lots of moving parts.

I'm not an expert in all this, but I've set up a few different deployment systems in my day as well as worked with a number of different ones. I thought we could try and round up and break down as much as we can here.

Going Commando

If you edit files right on your server directly, you essentially have no deployment step at all. You might accomplish this by using an FTP enabled editor like Coda or Adobe Dreamweaver. Enough people do this that popular hosts like Media Temple even have documentation on setting it up.

You might even using something like WebDAV to mount your remote server like a hard drive on you local computer, and use whatever local editor you like. Transmit has a "Disks" feature to makes this very easy.

The appeal here is strong because you get results live so quickly. However it is generally frowned upon. Because:

• It's dangerous, people see mistakes immediately
• There is no testing
• There is no record of changes - what/who/when
• You can't revert changes
• You can overwrite other people's work in teams
• You can't work on large, long term projects without additional setup

Using FTP Manually

One very home-grown deployment technique is to simply work locally and when you are ready, move the files to the live server with FTP software (like Transmit).

While this works, it can be tedious. Which files did I change? Oh, forget it, I'll just move everything. Man this is slow.

This still has many of the same shortfalls as above. You still risk overwriting someone else's work, you still can't revert easily, etc.

Using FTP this way doesn't automatically mean you aren't using version control, but it's likely. If you were, you'd be managing that totally independently and it would feel extra tedious. And still, nothing to prevent you from making a mistake (e.g. sending files up to FTP before you pulled from the repo). If you are using version control, you're likely already seeking a way to tie that into deployment.

The Version Control Piece

Version control is important, and will play a role in every other deployment thing we talk about. But in itself, version control doesn't automatically handle deployment for you. Without going into too much detail, projects are kept in repositories (or "repos"). They can have multiple contributors. Files are kept in sync. It is the contributors job to make sure they have the latest code and their new code fits. There is a record of all changes.

Git is probably the most common version control tool, but be aware that Subversion ("SVN") and Mercurial are similar and fill the same role.

Install Version Control on the Server, Pull From There

Version control software is just that, software. It likely doesn't come standard on servers that you buy (even the "fully loaded" servers that often come with stuff like PHP automatically). But it is also likely that you can install it on those servers.

Then, just like you can git push and git pull from your local machine, you'll be able to SSH into the server and git pull from there, which will bring down the latest files from that repo onto the live server.

That's simple deployment right there.

Jeremy Harris has an article that expands on this a bit, showing you how to push from you local machine and keep the .git directory out of the web root. Joe Maller has an article on using a "Hub" area on the server.

Cron Job

A Cron Job is a timed/automated task on a server. Run X every 2 minutes. I've seen folks run a Cron Job that git pulls every few minutes and that is their deployment strategy.

Post-Receive Hooks / Webhooks

GitHub has a feature they call Post-Receive Hooks in which they will POST to a URL of your choice when a repo has been pushed to. You could use that POST request to run a script which will run the commands you need for deployment, for instance git pull.

NetTuts has an article "The Perfect Workflow" that explains how this could be set up. They use a PHP file that runs the SSH command though, which in my experience, many hosts lock down without even an option to allow.

Bitbucket, another version control host, also has POST Service Management.

Third Party Deployment Web Services

There are some web apps out there that have made their business helping with deployment.

Command Line Interface (CLI) Tools

A fancy way of saying: tools that work by typing commands into the terminal. They typically have configuration that you either pass in the commands themselves, uses a config file, or both.

Capistrano

Capistrano isn't strictly for deployment. It is for executing commands on servers. Deployment is a super common use for it though, and it was born from that origin:

Capistrano was originally designed to simplify and automate deployment of web applications to distributed environments, and originally came bundled with a set of tasks designed for deploying Rails applications.

It's in Ruby, but it can be used for anything.

As a website gets more complex, simply pulling code from a central repo probably isn't going to cut it. For instance, there might be multiple servers involved. Or pulling those files might take a little time and that in-between time could break your app. With Capistrano, you could configure it to prepare the server, pull the new files to new location, update the symlink to point to the latest, clean up permissions, restart services, and do it all on multiple servers. This image demonstrates that.

There was a Web UI for it, but it seems a bit out of date.

RailsCasts has a bunch of screencasts to learn about Capistrano.

rsync

rsync is exclusively about file transfer.

rsync is a file transfer program for Unix systems. rsync uses the "rsync algorithm" which provides a very fast method for bringing remote files into sync. It does this by sending just the differences in the files across the link, without requiring that both sets of files are present at one of the ends of the link beforehand.

rsync is a command, so it is often run by a task runner like Make, or more commonly Rake since it's also Ruby.

git-ftp

Perhaps you're sensing a running theme:

Instead of transfering the whole project, I thought, why not only transfer the files that changed since the last time, git can tell me those files.

git-ftp pushes files up to your server just like any FTP client would, but it knows exactly what files to send up because it uses Git, which knows.

git ftp push -u <user> -p - ftp://host.example.com/public_html

Dandelion

Dandelion is similar to git-ftp, but it works from config files so you can be a bit more specific about what you want to happen and simply the command (dandelion deploy). It can also push to AWS.

Ansible

Ansible:

Ansible configures operating systems, deploys applications, runs parallel commands, and orchestrates IT processes like zero-downtime rolling updates. It uses SSH by default, so no special software has to be installed to start managing remote machines. Modules can be written in any language.

grunt-ftp-deploy

As far as build tools / task runners go, Grunt is slugging to be king. It is in Node.js which has a package manager (NPM) of it's own, similar to Ruby Gems.

One such pages is grunt-ftp-deploy which moves files from your local machine to a server over FTP. You configure the task then simply run it however you prefer to run Grunt tasks. It's a rather "dumb" task in that it doesn't even try to only move what has changed or reference version control. It just moves everything.

Static Sites

A "static" site is a site that requires no services or database or anything. Just a web server and a bunch of resources files (e.g. .html, .css, .js, images).

GitHub Pages

GitHub offers a service called GitHub Pages which will happily serve up static sites for you. You can even use your own domain name with them. You simply make a branch of a repo named gh-pages and it just kinda works. That way deployment is simply pushing to that branch of that repo.

There is a grunt task just for this.

Jekyll

Just because a site is static doesn't mean it's lame/simple/has poor architecture. There are build tools for static sites that allow you to smoosh together templates and content and spit out a website. Jekyll is one of those that is specifically built to work with GitHub Pages.

Octopress

Octopress sits on top of Jekyll, providing configuration, templates, and such so you can get started faster.

Neither Jekyll or Octopress help with deployment necessarily, they are just very related to GitHub Pages which is a form of deployment.

Amazon S3

Amazon has web services where you can actually run servers, but it also has S3 which is simply file storage. You can actually host a static website on S3 and even use your own domain.

There are even a set of command line tools called s3cmd which you can configure and run commands in which to deploy static sites (i.e. s3cmd sync).

Platform as a Service (PaaS)

Hopefully it's clear now that just deployment can be complicated. The entire web platform stack can be super complicated. It's no wonder that companies have stepped up and now offer services for simplifying it. These companies offer hosting and server management and databases and all that stuff. Easy deployment is typically part of the package.

There is tons of PaaS at the enterprise level. See SalesForce, RedHat, and IBM for the tip of the iceberg.

In another vein, Mixture.io does hosting/deployment right from their desktop development tool.

Continuous Integration Servers

From Wikipedia:

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day.

The idea is that individual developers don't have a branch checked out so long that it becomes very different from the main repo and merging the two becomes difficult.

Extending this concept to the server means running that code on actual servers to make sure everything is OK. Run the build - does it pass? Run your tests - do they pass? Doing this often means catching problems early and huge deep problems never develop.

This is related to deployment because people use them to automatically deploy code when all steps are passing. For instance:

1. Commit/push new code to repo
2. CI tool runs all builds/tests that you configure
3. If stuff passes, it gets deployed
4. If stuff doesn't pass, you are notified and no deployment happens

I actually barely understand all this, so please correct me in the comments if I have it all wrong. There are a number of different ones, so rather than try and explain something I can't do very well, I'll just list them:

• Travis CI (naturally works with GitHub)
• Jenkins CI (can be made to work with GitHub)
• CircleCI
• Codeship

CMS Specific

CMS's have such huge communities these days it's no surprise tools pop up that are specific to them and not just their parent language.

WordPress

• WP-Stack is a boilerplate for WordPress sites, assuming Git and Capistrano.
• WordPress-Starter is similar but includes S3 backups
• We didn't talk much about database deployment. I'm not sure there is much to say about it. I've always been surprised at how awkward it is moving databases around. WP Migrate DB Pro is a good tool specific to WordPress to keep them in sync.

Drupal

Drupal has a command line interface called Drush which has a deploy script called Drush Deploy.

Is That All?

Nope, probably not. I didn't even mention stuff like Puppet and Salt Stack, which I don't even really understand.

Feel free to chime in in the comments with any additional information, things I got wrong, things I missed, or how you go about deployment.

Website Deployment: Let Us Count The Ways! is a post from CSS-Tricks