Evan Payne

My Development Process

Today I'm going to share an overview of my development process, so I can get something else onto my newly cleaned out site.  I think this will expand into a series of tutorials, but for now, just an overview.

So, imaginary scenario:  I'm given a brief and for a new website.  The client has brought in a designer and they've supplied me with a photoshop/sketch comp of the site, and even taken the time to make a version for mobile.  And so, we begin.  I generally follow this pattern:

  1. Absorb
  2. Scaffold
  3. Craft
  4. Test
  5. Enhance
  6. Deliver

So lets dig in:

Absorb

Whenever I start a new project, I take the time to stare at the wall for a few hours.  My fellow developers might understand how necessary this phase is.  While staring, what I'm actually doing is building the site in my head, one piece at a time. I look for similarities in the content, so I know if there are four types of body text, or only one; if I need Bootstrap to speed things up, or if I can get away with just Bourbon; if the element from the mobile design match up to the desktop design, or if I'll have to do some fancy media queries to get out of a corner.

Basically, this stage is all about trying to see the project from every angle and write out what needs to be solved.  For me, building websites is interesting because there are always unique problems to solve during the process.  One site might require an animated svg icon as their logo (tutorial forthcoming), another several touch sliders on each page.  Its important to remember that the problems aren't solved at this stage, just written down.

Also during this stage, I break the site down from pages into components and elements.  I'm a big fan of Atomic Design, and I think the best way to keep your website responsive and fresh is to build the smaller bits first, then put them all together later.  That way, if you want to change the way your buttons look or function, there's only one place to do it.  So, I break each part of the page down into its smallest bits, and try and find relationships and similarities between the bits.

If I had a printer, I'd be so much better off.  I would simply print out the designs, cut them apart, and sort them into piles.  I love that.  As it is, I just do it in my head, and with a list in Workflowy.  When I'm done, I'll have a layout of components to build, and a pretty good idea of the workload ahead.  Then comes my favorite task:

Scaffold

It used to take a long time to get started on a project.  There were so many things to setup first, to download and install, to wrangle into place.  In my old life, I used MAMP to code locally, which was nice, but I had no concept of build scripts, I wasn't using git, wasn't using Sass.  My process was a mess, and worse, it made going back to clean up those older projects a tedious exercise instead of a breeze.

But not so anymore!  Now I use a custom build process of my own to make sure I'm following best practice and working efficiently.  In future posts, I'll share more of how to do it yourself, but here's what my process looks like for an average Wordpress website:

  1. Setup a config file for the site in my Ansible-driven development box.
  2. Reload the Vagrant box to add the dev site's url to my hosts file and link the domain to the dev-box.
  3. Run my ansible-playbook to setup the new site.  This sets up private repos at bitbucket for the project, its theme, and its main custom plugin.  Then it automatically sets up wordpress, adds my favorite plugins, and sets up the defaults I normally have to change, all with the power of WP-CLI. Lastly, it sets up a site-specific theme  based on Thyme, my streamlined fork of Sage. It customises the theme with the site name, makes sure a git repo is started, and then runs npm, bower and gulp to setup the first iteration.  I get really excited now because I've gone from a config file to a ready-to-develop-on site with a single command.
  4. Add the three git repos to Sourcetree and setup Git Flow for development, feature and hot-fix branches.
  5. Setup the Scss partials for this particular site.  I prefer a version of ITCSS, but I structure it a bit differently. (another post in the making)
  6. Start in on the html.

At this point, I start to do the real work.  I treat the setup of the partials (in both the scss and the html/php) as scaffolding, but really, I've blended into the next task, my other favorite:

Craft

The theme I use allows me to develop very actively.  I fire gulp watch, and I get a non-logged in version of the site in the browser that automatically reloads when I make a change to any template file, or injects any css changes in without a refresh.  I develop in Chrome.  I'm opinionated about it.

So, first up is to build the base of the theme, decide what needs a container, what's full width, what lives on every page in the form of headers, footers and so on, and what needs its own unique content (which usually means the loop in wordpress).  I'm careful to remove what I don't need from the theme at this stage.  If a sidebar isn't part of the design, I get rid of the file that created it.

Then, I build out the first page I'm working on.  I like to write out long strings in Sublime Text that convert to full html with a tab, using Emmet.  Something like .container>.main>.article.insert-wp-tags-here>h1{Title}+.article-content>p.intro{Intro Text}+p^.article-meta which expands to

<div class="container">
  <div class="main">
    <div class="article insert-wp-tags-here">
      <h1>Title</h1>
      <div class="article-content">
        <p class="intro">Intro Text</p>
        <p></p>
      </div>
      <div class="article-meta"></div>
    </div>
  </div>
</div>

Its very exciting.  Once that's all in place, then I fill in some dummy content, sometimes manually, something with wordpress content already.  I use ACF Pro to build custom content (outside the editor), and allow for maximum client editability.  The reason I call this stage Craft is that at a certain stage, due to the structure, I find myself working on only the details, not the big picture.

The structure holds the bigger details in place and out of mind, and I focus instead on the elements, the modules, the sections, whatever you want to call them, building them to be pretty and useful and responsive.

During this stage, I also start to build the functionality the site needs.  Pulling in custom info from files or services, building tentative animations or transitions.  There's lots to be done with javascript, and now's the time I start in on that.

This article is already much longer than I expected, but I'd be remiss if I didn't mention how integral Bower was to my process.  There are so many brilliant "plugins" in the javascript world.  Things that used to be such a hassle to bring in and use in wordpress.  Now that my theme is bower-ified, its often as easy as typing bower install 'this-component' --save, and adding a line in my manifest file.  The gulp file I use will then read the components' own bower file and use its declared "main" files to inject the css into my main stylesheet, and the javascript into my main js file.  Then, I can just use it. Very easy and rewarding.

There's several articles worth in here, and this is the stage where nearly all the magic happens.  But once it starts to wrap up (and its never truly done), then I start to move into the next phase:

Test

Ok, I'll admit it.  I hate this part.

One of the hardest parts of being a developer is the sheer number of devices and browsers that exist, and the nagging worry that your work might look awful in one of them.  So, there are a number of tests I do at this point to soothe that worry.  First up is a latest-version run in the big 5: chrome, firefox, safari, Opera and IE.  I load up the site in each of them on my machine, using VirtualBox to get IE working on my Mac.

After I've fixed any bugs in those browsers, I start loading up old versions of IE.  I also make sure I'm testing Android devices, and using Simulator from Xcode to test the latest iOS devices when I don't have them handy.

Its a mess, and its hard, and there's a lot of bugs, but tools like Modernizr help alot, and I generally don't promise support for IE9 or less if I can avoid it. There's just too many amazing things that can be done when you aren't handcuffed to the beast that is Internet Explorer.

I also run some php tests, but I admit that I need a better understanding of this part of things.

After the biggest bugs are squashed, I feel comfortable to move on to:

Enhance

This is the experimental part, where I get to grow my skillset a bit and try out new techniques and perfect old ones.  It usually entails adding CSS3 transitions to objects on the page to make them live and breathe a bit.  This could be simple scale effect on images on hover, or adding some animation to the svg icons that I prefer to use.

Speaking of images, this is the time when I make sure we're as responsive as can be.  The issue isn't settled, but I try and deliver only the assets needed for the screen size and resolution viewing them, and I use media queries and javascript to help determine that.  Again, this could be a series of posts in itself, but there are some great people working on a fully-fledged solution, so it may get easier to do in the near future.

I also work more in the wordpress dashboard at this stage, setting up tracking/analytics, filling in the actual content, making some how-to videos using Quickcast.  The how-to videos are so important, and they only take a moment to setup.  I record them because I'm filling in the content anyway, and it helps clients to see it being done, rather than having to explain it over the phone, or to charge for a lesson.

Before I move on, I'll go through another round of tests on the new parts.  I enhance after a first round of tests because I treat it as progressive enhancement.  The site should work without anything fancy, in all browsers and devices, and then the fancy bits should add a life to the design.  Generally these final tests go faster too, or at any rate are easier to troubleshoot.

If all is well at this stage, then I'm ready for the final part of the process:

Deliver

Nearing the end of a site build, I bring in a few friends to test things out and kick the tires.  Then, I'll upload the site to my test server, and give the client access.  This part is where my command line scripts come in very handy.  I have an ansible-playbook for deploying, and a configuration file for both my staging and production server.  Again, with a single command, the server is setup for the new site, and the content is transfered by sftp and using migrate db pro.  Once the site is setup, I generally only have to sync the plugins and theme manually, as the content and settings and media are handled by the migrate db plugins.

So, once the client feedback is addressed, we're basically...

Done

Building a site is sometimes a long process.  Just writing all this out in overview form took around two thousand words!  But I love it, and I love tweaking the process, finding new ways to do things, new plugins to use, new methods to speed things up.  It took me a long time, but I've settled into a craft that I really enjoy, and that still leaves me time for family life.  Its incredibly rewarding.

So, I hope you enjoyed some of that article.  I hope to flesh out parts of it in further posts.  If you have any questions, please comment below! And tell me, what is your process like?