Streamline your website development process
Since the beginning of this year, I’m now running a company with my friend Axel Bouaziz. I’ve had the chance to work on great projects and learn a lot of things. As we are only two people in this company, we do everything in-house. By everything, I mean everything. Axel is doing the design, and I’m doing both front-end (HTML, CSS) and back-end (PHP with Zend Framework 2) development.
Today, I’d like to share with you some thoughts about what mistakes I’ve made, and how I plan to streamline my working process.
For most websites, front-end development often means transforming my colleague’s PSD files to HTML and CSS. Of course, I’m not talking about heavy front-end developments (like EmberJS or AngularJS): this is yet another story.
When to do it?
One thing I’ve learnt is that you should start to transform PSD into HTML/CSS files once your designer have done the whole design. Of course, it’s often hard to do if your client is in a hurry and can’t wait for the extra time, but I’ve found a lot of benefits of doing this.
By analyzing the design as a whole, you can more simply see what is reused accross all pages, and write better, faster and cleaner CSS.
Where to do it?
This is a more interesting question. For my first client’s project, what I did is writing HTML and CSS at the same time I was writing my PHP views. While it allows to save time, this is a bad idea.
Some weeks ago, a client of mine seems to have done the same mistake. They needed us to design only one page for their website and writing both HTML and CSS (no back-end code). However, what they gave us were HAML files (urgggh, please people write plain HTML, HAML is ugly as hell!) already filled with their back-end code (in this case, RoR code). This was a shame, because I simply couldn’t reuse this file: they just didn’t have plain HTML files. So what I needed to do was going to their live website and copying the whole source code. I also needed to change all the paths to CSS, JS… I lost a lot of time on this!
Another story about that: some days ago I needed to create a blog for a client’s website I did earlier this year. We decided to make a static website using Jekyll, while the main website was done with Zend Framework 2. Once again, I had a problem: my HTML file was filled with PHP directives, so I lost a lot of time to duplicate the HTML file for the static website.
The answer, and the best way I’ve found so far, is to completely dissociate front-end and back-end. You should always transform the PSD in a separate project, made of plain HTML and CSS (or SASS, LESS…) files. No back-end code. Once you’re done, just integrate this HTML markup into your back-end code. Of course, for this to work you should sync both files. If your designer makes a change, first update your plain HTML files, and if it works, port it to your views.
Of course, working with plain HTML files is a bit less convenient, because of its lack of includes and that kind of things. Hopefully, we have a lot of solutions. The one I will use for our next project is the “kit” language, bundled with the awesome CodeKit app. This is only for Mac (well… just use a Mac !). Kit language is a very simple language that is compiled to plain HTML files and support includes. No more changing your 42 pages when your designer decide to add a fucking stupid gradient to the header ;-)!
In fact, there are a lot of chances that, if you are working with a team, this is already your workflow.
In overall, I’ve found my workflow with back-end development to be pretty efficient. Here are a few advices:
- Write a very detailed specifications for your website. Really. Write it. If you work with a client, force him/her to write it. Or write it with them (and bill them for that). Writing a very detailed specifications allows you to work nearly independently without going calling your client everyday. It also allows you to estimate more precisely how much time you will have to work on it.
- Some parts will be influenced by your designer. I mean, he/she may want to display some specific informations you didn’t think about, or in a unusual way. The designer may also decide to include some informations in a given page that require you to make some changes to your architecture. This is less true for a REST application, though. However, there are a lot of parts that you can write without any design. Like services, repositories, tests…
- The new trend today is to write heavier client-side applications. The server code is becoming simpler (as it does not deal with rendering anymore, and mostly is a REST API). On the other hand, with the help of JS MVC framework (like EmberJS) you have another application. The trick is to consider those two things as two different projects. The first reason is that a JS and PHP projects likely have different deployment and build process. Furthermore, a typical ZF2 application already have a lot of files. Do not complicate your project even more by adding a JS app. Therefore, in your GitHub/Bitbucket/whatever account, you should have a “my-project-server” and “my-project-client” repo. Keep them separated and the world will be better.
I’d love to hear more about how you handle your website projects, especially if you’re doing all the parts like I am!