Sometimes we’re just too busy and that follow-up email will tell them that we’d love to work with them but we can’t start a new project until [insert timeframe in the future here]. They may get back to us and tell us that’s fine, otherwise we will try to refer them to someone else. (If you’re a professional web developer in the Massachusetts area with a decent portfolio, let us know because we don’t have a good selection of firms to refer to.)

Turning a potential client into an actual client

The first thing we do with a potential client when we’re ready to start a new project is to set up a face-to-face meeting. If the client isn’t local or they’re just “too busy” we’ll do this on the phone, but that’s not our preference. The goal is to learn the client’s needs to the extent that we need to in order to write up a project proposal. (See the section on “Discover - First Round” in the process post to read about the four key questions we ask.) This meeting is usually very informative for the potential client and we enjoy meeting new people, so even if the project we’re discussing doesn’t get off the ground, it’s never wasted time. (Who knows when the potential client might be in the position to do another project or to refer someone else to us.) An important thing that happens at the “coffee meeting” (as we call it) is an exchange of business cards.

If we come away from the coffee meeting with a verbal agreement to continue, now it’s time to set up a project.

The steps in setting up a new project

The first thing we do is give the project a short name. If there is a business name or domain name already, we’ll use that. Otherwise we’ll use the name of the client (mariagreene, for instance). We use that project name to make:

• An email folder (or Label if we’re using gmail)
• A computer file folder
• A physical file folder
• A bookmarks Tag on del.icio.us, the social bookmarking service

Keeping track of email

When dealing with a small business or organization, we usually use straight-up email. As I already said, we always follow up phone or in-person communication with a summary email (that we try to keep brief and friendly) so that we have records. Everyone has their own method (drag and drop, filter actions…) to keep track of the messages associated with a project, but I use a combination of search and manually dragging things to folders on my Mac.

Just Magic Design is a team of two (or more if we’re using subcontractors). We always insist on having one contact with the client (with authority to sign off on deliverables) but there may be other stakeholders who want to be kept informed. If there are too many involved to just use CC and Reply All, we’ll set up a Google group or YahooGroup to manage the message list. This has the side benefit of keeping a log of all the messages in one place and giving us a password-secured place to share project files. We’ve considered using a more sophisticated solution like Basecamp but haven’t taken the plunge yet.

Setting up the computer file folders

Now that we have a way to communicate, we’ll set up a top-level project files folder on our computer(s). I like to keep mine all together under my home folder in a JMD Projects folder. For the JustMagicDesign.com website project, for instance, the directory structure looks like this:

/Users/mariagreene
   /projects
      /justmagicdesign
          /wordpress (or drupal, or...)
          /assets
          /documents
          /backup

The actual website files go in the www folder.

The assets folder has original artwork like Photoshop page mock-up(s), logos or other branding elements in their native format (usually from Illustrator), client-supplied or stock photos in their original resolution, and so on.

The documents folder contains the following (copied initially from a folder called “JMD Projects/01 Blank Project”):

• ClientInfo.doc
• ProjectProposal.ppt
• Schedule.xls
• Invoice.xls
• Contract.doc

I’ll talk more about these files in later posts.

The backup folder will eventually contain the most recent backup(s) of the site’s database.

When the project is finished, this whole directory structure (from the project directory on down) gets copied onto a CD and given to the client.

The physical file folder

The physical file folder will start off containing the client’s business card, but eventually will have the signed contract and any material provided by the client in the content gathering or competitive analysis phase. (It might also contain the odd menu or other printed item, swatch of fabric, or anything else with some design element that inspired us during the design phase!)

When we’re setting up a new project I use my handy-dandy label maker to print a neat label to go on a manila folder. That folder usually goes to in-person meetings with me (and the printed label makes me look like I’m a paid professional.) In my file cabinet, I have a section of hanging folders for active projects where the folder lives. When the project’s finished, some of the content gets sent back to the client (originals or copies) and the folder gets moved to the archives drawer which I actually bother to keep in alphabetical order.

Del.icio.us bookmarks

We use del.icio.us to share bookmarks of project-related sites on the web using the Network feature. We use the project short name as the Tag. If you haven’t started using del.icio.us you should investigate it since it makes your bookmarks portable to any browser and is fantastic for sharing links and notes about them.

The project is set up — now get it done already!

That’s how we go about setting up a new project. The next step is recording the client contact information in the ClientInfo document, followed by filling in the blank ProjectProposal. It may seem like we’ve done a lot of work before the deal is officially made (the contract is signed and deposit paid) but these steps actually only take about 20 minutes to perform and set us up for rapid progress once we officially kick off the project.

I often push back on my clients who want to go live with a website that still has “coming soon” text on some pages or other otherwise isn’t finished. It’s not as bad as the ’90s when you saw those “under construction” animated gif monstrosities all over the web. (Heck, you *still* see some of those pages that have been like that *since* the ’90s.) “Coming soon” text is still unprofessional even if it’s not as ugly.

But I maintain that this is different. This site is as finished as it needs to be based on where we are in the website development process.

In our experience, the best process is:

(Rinse and repeat)

Developing a website is a lot like growing a tree - it starts out small and undeveloped then builds out in layers or rings, each cycle bringing it closer to full grown. We’ve found that going through the full cycle (all the way to deploy) as soon as possible is the most efficient process because everyone is dealing with something real. Specifications are abstractions. The only specifications we produce are the initial project proposal and the hand-off documentation.

Here are some details about what goes on in each of these four phases during the different rounds of the cycle. Note that there are specific deliverables (from us) and requirements (from the client) at certain points. The requirements represent places where progress may be stalled until we have something from the client.

First round

Discover - First Round

Everything starts with the project brief. We like to do this over coffee. While we do work with some remote clients for whom we rely on email and the phone, we prefer to have at least one meeting in person. (This helps them to get to know us better and vice versa.)

In order to get an idea of the requirements of the project we ask four key questions:

1. Who are you and what makes you unique?
2. Who are your visitors and what are they like?
3. What do you want them to do on your website?
4. What are your constraints in terms of time, budget, existing website or branding?

We’ll ask follow-up questions as needed, but mostly what we do at this point is listen. We might mention some ideas for the website but the focus is on getting to know the needs of the client.

One important thing we’ll discuss is who will maintain and update the site in the long term? (This could be us, the client or someone else.) How often will it need to be updated and what is the technical skill level of the person who will do that? This will heavily influence the implementation of the website. We specialize in websites that are easy for a moderately computer-savvy person to maintain (or trivial for a very computer-savvy person) because this is the most cost-effective and fast way to do it for the client.

Deliverable: Project proposal

The project proposal will summarize what we learned about the client during the brief and will scope a website that will meet those needs. It will have a guestimate of pages and functionality, list the measurable goals of the site, list the things we will need from the client (especially regarding content), include a rough schedule and a price. (We usually have a queue of waiting projects so the schedule will be in the form of an approximate start date and an estimated duration.)

The proposal will also include brief sections on platform recommendation, hosting recommendation, maintenance and promotion assumptions. This way the client knows about all the recurring costs and effort that will be associated with the website beyond the initial development.

Requirements: Signed contract, deposit

After refining the proposal with the client, we’ll ask for a signed contract. When we’re ready to begin work on the project (which may not be immediately based on our other client work) we’ll ask for a deposit of 25% of the total payment.

Content gathering

Now that the project is officially started, the next part of the Discover phase is collecting anything we can from the client. If it’s a website redesign, this means a thorough audit of the existing site’s content and a discussion of what is working for the client and what needs to be changed. We also gather business cards, white papers, price sheets, flyers, advertising, images, articles or anything else that describes what the client does.

Competitive analysis

We’ll do our own research into competitors but we’ll also ask the client for references, especially to competitors (or allies/heroes) they’d like to emulate. We’ll ask a lot of questions about what the client likes and doesn’t like about the competitors’ websites.

Design - First Round

At this point in the early design we’ll focus on four key aspects of the design:

• Branding
• Navigation
• Layout
• Typography

The branding work may not be required if the client already has a name, logo, colors and possibly other elements that they want to continue using unmodified. Everything has to build on brand, though, so we always address it before other aspects of the visual design. We enjoy designing logos and the other parts of branding, but this is one thing we may recommend outsourcing to a specialist if the client can afford it since it is so critical to all aspects of business, not just the website. (If we do the branding work ourselves we will always deliver source files in vector formats suitable other purposes, such as print.) A key aspect of branding is naming and important requirement of that is getting the matching domain name, so we’ll usually register the client’s domain name at this point if that’s not already done.

Before we jump into a full visual design (in other words, before we fire up Photoshop) we’ll address the other three things: navigation, layout and typography. We’ll work mostly with pencil and paper at the beginning, sketching sitemap diagrams (and other forms of Information Architecture) and making thumbnail sketches of possible layouts. We’ll use various tools to play with different fonts, sizes, weights and use of whitespace.

Develop - First Round

Platform selection and install

Unless we’re developing an extremely small, static site, we’ll usually go with a platform like WordPress, Drupal or Ruby on Rails. (You can read a previous blog post that discusses this choice.) That will take some initial set-up.

Hosting selection

The platform will influence the hosting needs and we’ll discuss the options with the client, helping them find a good balance between cost and performance/support.

Site prototype based on initial design and content

Now is the time to actually start writing HTML and CSS. We like to hand-craft our markup and styles (rather than use Wysiwyg tools) but we start with best practice libraries of HTML templates and CSS frameworks to speed development and ensure good findability (SEO) and accessibility.

Deploy

The initial deployment is to a staging server, usually hosted by us (e.g., clientname.justmagicdesign.com). We make sure the site is password protected and not accessible to search engine spiders like Googlebot. Having a real, live website to show the client helps a lot in getting feedback because there are things you just can’t do on a static mock-up: resize the window, for instance, or interact with a drop-down menu.

Second round

Discover - Second Round

Now that we’re on the second round we want to discover if the prototype site is on the right track. It’s sometimes hard for the client to concentrate just on the menus, the layout and the flow of the site and not get sidetracked by the lack of graphics. “Yes, it’s not pretty yet,” we’ll ask, “but does it work for you?”

Requirement: signoff on the sitemap/navigation as presented by the prototype.

After the client is happy with the “ugly” version of the site, next we get input on design and mood — what are their favorite colors (if they’re not dictated by existing branding), what tone/personality do they want for the website, what are websites they admire for their appearance (even if they’re in a different space), and so on.

Design - Second Round

Finally! The part everyone loves and many developers and clients jump into way too soon.

At this point we’ll often need to gather imagery from or for the client. The photographs and other images that we incorporate into a design need to be meaningful to the client’s business or organization. We’ll try to work with existing imagery and supplement it with stock imagery from on-line sources or imagery we create ourselves. At this point we may recommend the services of a professional photographer so that we are starting with the best imagery possible.

Mock-ups

This is where the magic happens: the “real design”. Adobe Photoshop is our weapon of choice for producing a design. We have the wireframe in the form of screenshots of our prototype site that we can use like a uncolored coloring book. We don’t necessarily color within the lines though because the design influences the layout just as the content does (and because asymmetry and blurred boundaries may be appropriate for the goals of the site).

We may produce multiple designs for the client to choose from or we may (perhaps because of budget) focus on one that we refine together.

Deliverable: One or more mock-ups as static images on the web.

Requirements: Selection/sign-off on the design. The second 25% of the project fee.

Develop - Second Round

During the second stage of development, we convert the design into sliced images and CSS. (In other words, more magic happens!)

We’ll also pay more attention to the content at this point. We prefer to be copy editors and to take content written by the client (the domain expert) and use our experience with writing prose for the web to make it as effective as possible in that context. This is another area where we may recommend outsourcing to a specialist if the client can afford it and doesn’t feel he/she can write well enough. (Re-read the second sentence of this paragraph to see why we sometimes recommend outsourcing copy writing.)

We also work on things like e-commerce integration, contact forms and other interactive parts of the website at this stage.

Deploy - Second Round

Now the staging server should look pretty close to the final product, even if some of the pages still have “Lorem ipsum” level content or the forms don’t actually do anything.

Subsequent rounds

A simple project will just have one last round of testing and refinement before it is deployed live (launched). A complex project (like a web application) will have many.

We do two types of testing: validation and usability testing. Validation is automated and ensures that our markup and styles follow standards (as much as pragmatically possible), that all our links are valid, and so on. During usability testing we get feedback (ideally from people like our target visitors), refine, and repeat until the visual impression, usability and readability meet our goals.

We don’t test only on the final round — we do it at each stage of development. (The amount of formal usability testing we do varies a lot depending on the budget of the project.) Testing is particularly important during the final round, however, because we’re “done” when the client is satisfied enough that they want to open the website up to the public.

Requirements: sign-off from the client and the third 25% of the project fee.

Deliverable: the site deployed to the live server.

At this point, we party, or at least have a glass of champagne!

After launch

We’re not done, of course. We will do one last round of refinement, if necessary, based on real user feedback. For the few months following launch, we will make sure we set aside time to address any issues as quickly as possible.

But most importantly, we’ll set up and train the client on things like Google Analytics so that they can measure whether the site is actually working for them, and we’ll train someone on how to maintain the site. We’ll also discuss how to promote the site with company literature, advertising (such as Google AdWords), e-newsletters, use of social media, and so on.

Requirement: the last 25% of the project fee.

Deliverables:

• An Information sheet with all service providers (hosting, domain registration, SSL certificate, payment processors…) and all the passwords associated with the website.
• A CD containing the site files and all original artwork as source files (e.g., .psd, .eps).
• Any materials provided during the content gathering phase that the client wants back.
• A How-to document that covers:
  • Content updates (e.g., modifying pages, how to make blog posts, adding/updating products on an e-commerce site)
  • Upgrading the platform (such as WordPress)
  • Monitoring the site with Google Analytics and keeping an eye on server logs
  • Information about backups and restores
  • Site-specific features like user management if there is a community, forum management, etc.

So there you have it: our process for developing a website from start to finish. Next, of course, the new website brings in so much business that the company grows and expands. Now new features need to be added so they contact us again. That puts us right back at the beginning and we do it all again!

For further reading

The web has many, many sources of information on the web development process but I’m a book person. If you would like to read more about this topic two books I recommend are:

“Web ReDesign 2.0 | Workflow that Works” by Kelly Goto and Emily Cotler

and

“Getting Real - Discover the smarter, faster, easier way to build a successful web-based application” by 37 Signals.

If you’ve read both of these you might be surprised I put them both in the same list since they take two very different approaches to development. The first approach is “Think really hard, write down lots of stuff in a very structured way, then go implement until you’re done.” The second approach is “Think a little, do it, think some more about what worked and what didn’t, refactor, then repeat until done.” You’ll recognize our approach as a combination of the two.

An excellent book on usability is “Don’t Make Me Think“, by Steve Krug. This is a classic book on what makes a website a joy to use.

Note that these are the technical steps of setting up a development version of the site. We’ve already talked about what led to the decision to use WordPress. In the next blog post we’re going to backtrack and talk about the process steps we skipped because this is a relatively straight-foward site and the client (me) already knows what she wants.

This process will set up a development environment on your local computer and a live site on a remote host. I’m developing on a Mac and I have MAMP installed to provide an Apache2 web server and MySQL database. (Up until relatively recently I developed on a PC and used XAMPP, which is a very similar set-up as far as these steps go. You should be able to adapt them easily if that’s your platform.) I’m assuming the remote host is pretty standard Linux server that gives you access to phpMyAdmin for database administration.

So, on to the steps:

1. Choose a development directory and set up an Apache2 named virtual host.
2. Download WordPress to that location, set up the local database, edit wp-config.php and install WordPress.
3. Do basic WordPress configuration.
4. Set up the theme.
5. Set up source control.
6. Enable plugins and configure them.
7. Prepare the web hosting.
8. Copy the site from the development machine to the web.

1. Choose a development directory and set up an Apache2 named virtual host.

   1. Edit /etc/hosts
      Add dev.sitename.com to the line that starts with “127.0.0.1 localhost”
   2. Edit /Applications/MAMP/conf/apache/httpd.conf
      Add a new section like so at the bottom:
      
<VirtualHost *>
DocumentRoot "/Users/mariagreene/projects/sitename/wordpress"
ServerName dev.sitename.com
</VirtualHost>

   • Don’t forget to restart the server! You can do this from the MAMP dashboard widget on a Mac.
   • The /etc/hosts file is in a hidden directory so it’s a little hard to open from the Open dialog box of a text editor. On my Mac, I go to the Terminal app and type ‘mate /etc/hosts’ to open it with TextMate.

It doesn’t matter much where you put your files. I like to keep mine in a project subdirectory under my home directory (i.e., ~/projects/justmagicdesign/wordpress). Another common place to put them is under the web server root directory (i.e., /Applications/MAMP/htdocs/justmagicdesign).

Setting up a named virtual host allows you to access the local site as (for example) http://dev.justmagicdesign.com. You want to do this rather than just putting the site under the server root (and accessing it as http://localhost/sitename) because then relative paths are the same for both the local development site and the deployed site. If you don’t you’re going to have to find and change all the src attributes of your local <img> elements and href attributes of your internal links and change them when you deploy.

There are two steps to setting up the named virtual host:

Notes

2. Download WordPress to that location, set up the local database, edit wp-config.php and install WordPress.

The details are here: Installing WordPress. No need to repeat them because they’re really easy.

3. Do basic WordPress configuration.

Set your admin user’s password first! Otherwise you’ll forget that gobbledygook one that’s generated for you. Then go in and set Settings > Permalinks to the way you prefer. While you’re there, browse around the other settings and set them up however you would like.

4. Set up the theme.

For the JustMagicDesign site I’m developing a Thematic child theme. (More about that in a later post.) Since all my new sites use this base theme, I downloaded it into a shared folder and whenever I start a new project I just link to the shared copy. So, from my Mac terminal command line this would be:

cd /Users/mariagreene/projects/justmagicdesign/wordpress/wp-content
rm -rf themes
ln -s /Users/mariagreene/projects/wp-share/themes themes


For example, to create a child theme called “justmagicdesign”, copy the sample out of Thematic:

cd /Users/mariagreene/projects/wp-share/themes
cp -r thematic/thematic-sample-child-theme justmagicdesign


Now, open the style.css file in the new child theme folder and edit the header comment to set the fields for the WordPress theme manager.

Finally, go to the Appearance panel in the WordPress admin screens and select your child theme.

5. Set up source control.

I have my ~/project/wp-share folder set up as a Subversion repository. I won’t go into the virtues of source control systems or svn in particular, but trust me, you want to do this. You’ll need to add your child theme folder to svn.

6. Enable plugins and configure them.

There are many plugins that I use across all WordPress projects. I’ve downloaded them all to /Users/mariagreene/projects/wp-share/plugins. At some point I’ll blog about what they are, but for the purposes of starting a new project, the trick is to make a symbolic link to the shared folder. Here are the Mac terminal commands:

cd /Users/mariagreene/projects/justmagicdesign/wp-content
rm -rf plugins
ln -s /Users/mariagreene/projects/wp-share/plugins plugins


Now go to the Plugins page of the WordPress admin panel and enable the ones you want. You’ll need to configure many of them as well.

7. Prepare the web hosting.

I like to “deploy early and deploy often” in order to share my work with clients and my business partner. I also like to find hosting issues early. This means I often set up web hosting as soon as I know what the requirements are going to be or I use a subdomain on my justmagicdesign.com domain as a staging site. Except in special circumstances (like when I’m showing the world the rough stages of the design and development of this site), I usually password protect the top directory so the world (and Googlebot) doesn’t see anything half baked.

A word to the wise — don’t try to host your WordPress site on Yahoo! small business webhosting. Run away, run away!

8. Copy the site from the development machine to the web.

   • Copy the files from the local to remote machine. I use ftp from the Mac Terminal app but you can use any FTP client, including FireFTP, a useful, free Firefox Add-on.
   • Export the database using phpMyAdmin on the local host. Save it as a text file on your desktop.
   • Open it in your text editor and change all instances of your local site address (e.g., dev.sitename.com) to the remote address (e.g., sitename.com).
   • Create a new database on the remote host (using phpMyAdmin, the MySQL option of the control panel or using the mysqladmin command line tool if you have access to that).
   • Use phpMyAdmin on the remote host to import the sql file.
   • Edit the /wp-conf.php file of the new site to point to the new database. (You may need to also change other database information in this file, like the username and password if they’re not the same across sites.)

Now you’re ready to rock and roll! At this point I usually consider the database on the remote server to be the “golden” copy because other people are likely to have edited content there. I consider the files on my local machine to be the “golden” ones because they’re under source control and because it’s easiest to develop locally (where I can edit a file and just refresh my browser to see the changes). I periodically pull the database down from the web and push the files up to keep the two in sync.

• flat files (no database) made with a Wysiwyg editor like Dreamweaver or a code editor like TextMate
• a blogging engine
• a CMS
• a MVC framework

There are lots of choices within each of those types, but my tools of choice are:

• WordPress
• Drupal
• Ruby on Rails

I’ve found it really helps to pick a tool from each category and get to know it really, really well. It also helps to realize that every site needs to be evaluated individually to decide which is the right tool for the job. It’s easy to limit your toolset to one and then “if all you have is a hammer, everything looks like a nail”.

It’s not very often I decide to make a new site in straight-up HTML and CSS. Most often I inherit these (sometimes from a past life before I discovered standards and used Wysiwyg tools to make websites). Just about every site will grow beyond the few pages for which this is really a maintainable solution or will eventually need to be maintained by someone who isn’t well versed in technology or doesn’t own my Wysiwyg tool. Most of my coding this way these days is for prototypes.

WordPress logo

The site you’re reading right now is based on WordPress, an open source blogging engine. Why? Part of the site is a blog and WordPress is, in my opinion, the best of breed for blogging engines. Partly it’s the best because of the huge developer base and variety of themes and plugins available for it. I don’t want to waste any time reinventing wheels and I don’t anticipate I’ll need to create any custom functionality for this site, so I won’t have to worry about getting a rash from too much PHP development. WordPress’ theme system is pretty easy to use and I’ve done it a dozen times before, so that fits. The site isn’t going to be only a blog but WordPress’ CMS features (hierarchical pages, alternate home page…) are sufficient to make it “not too bloggy”. Finally, I like WordPress’ admin interface, especially since 2.7 and the introduction of automatic upgrades.

Add to all that the fact that it’s easy to deploy even on shared hosting and you’ll understand why many of my small business websites are based on WordPress. (All of the work we do for non-profits is based on WordPress because it’s free and it’s easy for non-techie people to use to maintain the site themselves.)

Drupal Icon

When do I choose Drupal? When the site is more complicated but is still pretty “standard”. Drupal is also open source and has thousands of “modules” (optional functionality) you can choose from to implement blogging, forums, e-commerce, user-contributed content… The theme system is straight-forward and similar to WordPress’. Drupal’s Content Construction Kit, Views and Taxonomy modules make it an excellent choice if your site needs to have specialized content types with a simple CRUD interface. (And if that last sentence didn’t make a lot of sense, read up on Drupal and/or stick with WordPress.)

Ruby on Rails logo

When do I choose Rails? When I want to enjoy making the website. No, seriously. OK, to be more specific, I use Rails if the site is a web application that has unique needs. If I’m going to be coding business logic I want to be doing it in Ruby and with a great support system like Rails. We’ve just started our first web application in Rails and it isn’t deployed yet, but so far it has been a total pleasure.

That’s how we go about choosing an “engine” when we’re starting a new project. You’ll notice they’re all open source which is a philosophical decision. (Diane and I intend to “give back” to the community just as soon as we develop something worthy.) You may have different opinions and considerations for choosing your tool set. If so, share them with me in the comments.

Next up: What are the steps to set up a development environment for a new WordPress project?

It’s traditional (if blogging can be said to have any traditions yet) to start with a post about who you are, who your intended audience is and what you’re going to talk about. So, here goes…

I’m Maria, a web developer and wanna-be designer from Massachusetts. This is my professional blog, so I’m going to write mostly about how I do what I do and I expect my audience will be other web professionals and occasionally clients or potential clients. I’m also a mom and a geek, so I’m sure I’ll be posting about work-life balance, a bit about lifehacking, and about being a woman (and a middle-aged one at that) and the perspective that gives me on the Internet and the profession.

My business partner is Diane. She’s the artist/designer/creative half of the team and a great friend. Diane may pop in every now and then with a blog post of her own.

If you’re visiting this blog close to when I’m posting this, the first thing you’ll probably notice is the underwhelming visual design. Here’s a screenshot for those who are coming along later.

The first version of justmagicdesign.com

Ready? Next up, a discussion of why I’m using WordPress for this site and how I decide what platform/engine/CMS/framework to use for a new project.

Welcome!