For over 10 years I’ve worked as a web developer, for most of that time my company has worked as the subcontracted development team, working alongside web designers on websites and applications. In addition, we have developed our own small CMS product, Perch, which is used by many web designers to provide simple content management for their sites. In the course of supporting Perch I get to see how people work, and the concepts that they struggle with.

A designer who freelances or runs their own agency, may find that they need to confidently explain technical concepts to clients. The end client is often unaware of the various specialisms behind launching a new site and relies on their web designer to guide them through the process. Therefore even if you tend to outsource development work, having an understanding of development can pay dividends in allowing you to discuss the technical parts of the job with your clients. In addition, when working with developers your knowledge will help to speed up communication and prevent misunderstandings.

This article contains some small tips and links to further reading, on subjects that I’ve found myself explaining when working with web designers on projects and when supporting Perch.

1. Write user-centric functional specifications

Functional specifications or briefs for development work are part of agency life. They get a bit of a bad press as they can be used to beat the client over the head with, and to prevent changes being made that will improve the site for the better. However, if you need to quote time and costs, you need something to base that estimate on, and if you are subcontracting development work, you need to make sure the developers are clear as to what they need to build.

Development specifications should clearly describe your application focusing on what the user can do. Concentrate on the tasks that users – both visitors and administrators – need to achieve, and you will go a long way to creating a specification that can be quoted against reliably and that will help prevent feature creep.

2. Consider programming constructs when planning

When developers are thinking through a set of requirements, we tend to think in terms of programming constructs. An understanding of these constructs can really help when developing specs and designing interfaces.

Conditional logic – if … then … else …

An example of conditional logic might be the following requirement. If a user is logged in, then show them a link to ‘My Account’, else show the links for login and account creation. It’s easy to forget the else when designing a flow, always consider what happens if your condition is not met.

Loops

A lot of development consists of repeating chunks of information. Perhaps you have products stored in a database and want to display them as a list, repeating the same block of mark-up over and over until you reach the end.

What happens if you have too many items to display nicely on one page? You will need some kind of paging – previous and next – or another way to show only part of the data. Can people sort this data in any way? Are there any special cases that need displaying in a different way? These rules need to be explained in the specification as any filtering is likely to require additional information being stored against the product in the database.

This article from dev.opera explains the basics of programming in simple terms for the non-programmer.

3. When designing – don’t forget the error states

When thinking about developing a brief for development, or creating your initial designs, don’t forget the error states and validation for forms. If you leave these things up to your developers, you will end up with error messages designed by programmers.

Protect your design from programmers! Especially if you are in the situation where you are handing designs over to a developer to build the site, and may not have much input after that point. Think through the various places where users need to complete forms or otherwise interact with the site. Protect your design by providing clear instructions to the developers as to how the messages will display and what the user experience should be.

4. Learn the basics of database design and how data is stored

Unless you have a completely static site – in which case your data is stored as HTML – you are storing data somehow. Having an understanding of how data is stored will make your life easier as a web designer. It will help you to understand the decisions a developer needs to make in order to store data well for use on the site and why seemingly small changes to the design can make a lot of work.

5. Learn to love Version Control

Source or version control may seem unnecessary to the lone designer in particular, but version control can help prevent data loss by providing a backup of your work. Using a remotely hosted version control system can also make it easier to work in different locations. I check my work into our system every evening and then if I need to work from home for some reason the next day, I can check out my progress and pick up exactly where I left off.

 

There are a number of excellent hosted version control providers these days – for example, GitHub  and Beanstalk. Beanstalk also have a brilliant guide to version control for those who are using it for the first time.

6. Create a professional development environment

Supporting Perch has given us a fantastic insight into the ways that people work. Some of the scary things we see people doing include the following:

Developing directly on the live site

I am always amazed at the number of people I see making changes directly to files on a live website. This is a terrible way to work and not just because you are likely to break something on the live site. If you are developing directly on files on a server, it is quite possible that this is the only copy of the up-to-date files available. If there is any problem with the server, you may find your entire site is lost.

Developing in a subfolder of the live site

The other thing we see people doing is developing on the live site but doing so in a subfolder. While this means you are not directly making changes to the live site, you still have the problem of your only copy of the site existing in a subfolder on the live server.

There is a second issue with developing in a subfolder – be that on the live site or on your local server – in that by doing so all your paths from root will be incorrect when you move the site up a level. Some scripts need to know the paths from root, so you may find that the change in environment causes you a problem when you go live. Drew McLellan explains why you should stop building sites in subfolders.

Developing locally without a web server

If you are not doing any serverside development, then you may just work locally, previewing files from the filesystem in the browser or using Dreamweaver or another editor to preview in the browser. Once again, by doing this you are not viewing your pages as part of the website, which can create problems with paths when you go live.

Developers know that you should always mirror your live environment as closely as possible, this prevents many of the problems you would otherwise have when moving a site live.

 

I’d like to suggest that everyone run their own local web server. If your sites are generally just HTML and CSS or you use PHP, then MAMP on the Mac, EasyPHP or XAMPP on Windows will do just fine. Create virtual hosts for each site so that the files can live in the root of the site.

7. Re-use code and other assets

Developers like to reuse code where possible rather than write things from scratch, reuse saves time but can also save you making the same mistakes over and over again.

Reusing code doesn’t necessarily mean using a CSS framework or the same boilerplate for every site. You may just maintain a library of useful snippets.

Many code editors allow you to store code as snippets or clips, there are also standalone tools and web applications designed for this purpose.

 

Reuse doesn’t only have to be about code, you can store common interface elements to drop into designs in Photoshop. One way I save myself time is to keep a folder of test upload files on my desktop. As a lot of what I do is develop and test content management systems I often have to test the upload of images and files. By keeping some test files I don’t end up uploading some important PDFs from the accounts into a client’s test server!

8. Know when shifting liability to a third party is a good idea

It’s tempting to want to do it all and keep everything on your own site. However, sometimes the most responsible thing to suggest to your client is to use a third-party for some functionality. Good examples of this are when dealing with taking payment and sending out email.

Payment pages

If your site needs to take payments online, many payment service providers will offer the option of full API integration or taking the payment on a secure page on their site. Unless you are very confident in security and understand how the PCI DSS requirements will then affect you, it is often a better decision to leave the collecting of card details to the PSP, then you and your client have no requirement to worry about the security of card details.

Sending email

 

Sending email is a tricky business. Getting email to work well across mail clients and get past spam filters can be difficult. You also need to manage unsubscribe requests and see how many of your messages are actually getting through. Third party services such as Campaign Monitor and MailChimp for sending to lists, and Postmark for sending mail from your application can shift liability for email to a third party who is an expert in dealing with it.

9. Realise that cheap hosting is expensive

If you are paying less for your hosting each month than you pay for your coffee each morning, then something is wrong. Poor quality hosting will cost you far more in time than you will save in money.

Hosts provide cheap hosting by offering very little in terms of support and by loading huge numbers of sites onto each physical server. The more sites that exist on a shared server the fewer resources each individual site has – and your site is likely to run slowly and, in the case of database driven websites, you may see connection errors with the database server as it has too much traffic to cope with.

If you want your site to load quickly and your host to help you if you have any problems, paying a little bit more for your hosting will pay off. More about choosing web hosting.

10. Get clued up on security

With a few basic precautions you can minimise your risk of having a site hacked or defaced. Most attacks are nothing personal, but are instead aimed at commonly installed software. The Stop Badware site explains some of the common things you might find on a hacked site.

Upgrades to third party software must be part of the spec

Leaving a client with third-party software installed on their server with no way to upgrade it is irresponsible. If you deploy a site for someone that uses any third-party code – be that blog software, a CMS, a forum or anything else – you must either have an agreement with the client that you will update the software when required, or pass on the information so they can do it themselves.

Be very suspicious about plugins

Assuming you have the core software you are using – such as WordPress – up to date, a hacker is far more likely to get access to the server via a plugin that either has poor security or is even a host for malware itself. Do your research before adding any code to your site, and check that people are not reporting problems after using it.

If your site is compromised, check if other people on your host are having the same problem

It may not be anything you have installed that has caused a security breach. If your site is hacked, check and see if other people on the same host also have the problem. The issue may stem from poor security at the hosting company, or a compromise based on their control panel software. If they are not taking this very seriously indeed, it is time to change hosts!

Whether you are involved in the web as a designer, developer, copywriter, project manager or any other role, I feel that the more you understand about the whole stack the better. We work together more effectively when we appreciate and can learn from each other’s roles – and there are often tips that can help us in our own work when we look at what other people are doing. You can add your own suggestions for tips in the comments.