A web development workflow for designers

Preprocessing, versioning, and the use of libraries
A web development workflow for designers

If you spend a significant part of your time in editing HTML and CSS, it's almost certain that you have wondered at some point how you could become more productive, and perhaps how you could add a little more security to your work.

This has been my own situation from the very beginning, back to the times when preprocessing was not even a possibility.

Every particular productivity need turns into hours of googling and testing. The result is the following workflow scheme, which I recommend specifically for front-end developers and designers who would prefer to keep command-line as close to zero as possible.

Before we start, just a quick note on WYSIWYG editors. I have tried many, but always have ended coding on text editors. There's two big reasons for this: dry code, and preview bugs. I don't like automatic coding because I feel like I lose control, and you can always preview on the browser, which is what you'll have to do anyway before going online.

So this is how you build your web developer workflow:

  1. Choose a good editor. I'm working on Windows, and used Notepad++ until I discovered Brackets. Both are free and offer syntax highlighting for most languages needed. In Brackets, support for LESS or SCSS is native, and you can easily add more via plug-in. In Notepad++ you need a custom language for LESS or SCSS, but you can do the same job. One of the neat things about Brackets, though, is you can quick edit the associated css style within the HTML document. It opens an inline editor showing all the styling in other files grouped for easy editing, which is a productivity plus.

  2. Use preprocessors. There's a lot of literature right now on this, and also multiple alternatives. Basically, a preprocessor language lets you write code at a higher level, with variables, repetitions, loops, etc. The little drawback is you need to process the code to obtain your HTML, CSS or JS, and this means you need a compiler. But the good news is you can get a good, transparent compiler for less than $50. I'm specially happy with Prepros, available for Windows 7+, OS X 10.9+, and Ubuntu.

    • The essential preprocessor is one for CSS, because that's where you find more repetitive tasks, like element colors, margin dimensions, etc. The most commonly used are SASS and LESS, but you can also use STYLUS. Most of the times I use LESS if I start from scratch (i.e. gradually converting my css), but you'll find projects where SASS is the official option.
    • You can also use an HTML preprocessor, more commonly known as template languages, like HAML, SLIM or JADE. The two first were designed to complete a Ruby on Rails workflow, since they use Ruby for compilation. Jade relies on node.js. People usually use either HAML and SASS because they both use Ruby, or STYLUS and JADE, because they are based on node.
    • If you code Javascript, there's also a preprocessor language for that, called CoffeScript.
    • In case you use PHP (such as in Drupal, Wordpress...), the equivalent tools are called template engines. Smarty is perhaps the most popular, although a bit aged. There are many new modern alternatives like Twig (adopted in Drupal 8) or Mustache (leading the logic-less trend, and compilable to many languages).
  3. Version control is a must. You can't expose yourself to the risk of breaking the code and not being able to undo a couple steps, and this is specially true with teamwork. If you're a small team working always online, I recommend Subversion. You can use an online repository like Assembla, and a SVN client like TortoiseSVN. That's all you need. What you'll basically do is send (commit) a code update every time you reach a stable stage. You will be able to go back to any of those stages if things go wrong. It's like saving duplicate folders of your entire project. If your team is big and/or some of you need to work offline, GIT is a better option, since the repository is distributed.

  4. Last, but not least, stick to a framework or a group of them. In the old fashion editing, you would pick JS scripts or code snippets form elsewhere depending on your UI needs. Say a rollover effect, a form validation script, or just a simple slideshow. Now we don't understand our web editing without libraries. jQuery is the most extended JS library for web design, and on top of it we've learned to use what we call a CSS framework (like Bootstrap, Foundation, Skeleton...). These are in charge of most of the UI, by adding some basic structure like a responsive grid system, and styling a number of UI elements like buttons, tables, forms, wells, etc. We also use libraries for font and icon management, browser consistency, printout, etc. The reason for sticking to a particular framework is there's a little learning curve here, since you should be quite familiar with the basic structure and naming conventions.

Once you get familiarized with every chosen component, you'll feel the breeze of creativity and the power of managing your time again. Templating and designing will be a new, pleasurable challenge, and you'll become the productive beast you used to be.

The short story is that, after a long search-and-try, my own initial workflow basically included these languages: LESS or SCSS, and SLIM, these tools: Brackets, Prepros, and TortoiseSVN, plus I used to stick to Bootstrap 3. For the long story, you may ask and I will happily share my reasons.

On the second article of this series, I'll be looking towards improved flexibility and increased productivity.

PS. You should get a second monitor. You won't go back to one.