My Entire Front End Development Process From Start To Finish
I’m a productivity fiend, and constantly hone my process to suit my needs. To that end, increasingly, I have become more of a keyboard jockey and tools that allow me to continue using the keyboard rather than reaching for the mouse allow me to stay in the flow and keep my thought pattern uninterrupted.
A while back my good friend (and excellent designer) Paul Bamford introduced me to Alfred. It has become a cornerstone of my work flow. Alfred allows you to set-up a shortcut key and just type the name of the “thing” you want to do and hit enter. It’s effortless and amazing.
Need to launch an application?
Hit the short-cut
type the name, hit enter done. The mental processing this saves while working is worth the price alone. There is nothing worse than stopping mid-flow to spend 10 minutes hunting for that file you can’t remember where you put.
On the topic of being productive, I keep my thoughts ordered and on top of the TODO list with my trusty Moleskin and the Bullet Journal System. When it comes to an organised system of getting things done an analogue approach has always fit best with my work-flow. Digital systems have always fallen down for me because when I am at a computer there are so many other things competing for my attention and using the system is nearly always dependent upon the internet. Both point of failure that can and will happen when simply trying to take some quick notes. I also feel (personally) if you sit at a laptop in a meeting with a client or colleague and take notes on it, it gives the impression you are not paying attention. On the other hand clients welcome you taking notes in your moleskin and are pleased that you are paying attention and taking notes. I suppose because a notebook is very open and obvious to all what you are doing but a laptop isn’t always so clear, you only need to be sat opposite a client with your laptop and you have created a physical barrier between yourself and the client along with writing words the client can’t see, you could in theory be writing anything which puts them on edge.
Inspiration and Resource Gathering
When it comes to resource gathering I use a combination of mobile and desktop tools. For iPhone, Feedly is my RSS reader of choice, which I combine with Prismatic to discover new and interesting content, interesting feeds are then rolled back in to my Feedly stream. It’s a good cyclical process that keeps my reading content board, and yet focused, and avoids the creative tunnel vision that can happen, when you just rely on one source of information. Anything that piques my interest in particular is sent to my Pinboard account, where I store blog posts, resources, information and anything that interest me. I augment this when on my laptop / desktop with Shiori, which is a fantastic frontend interface to Pinboard and works in much the same way as Alfred.
In terms of visual inspiration, in the past I have tried Zootool, Iceber.gs and many other visual bookmarking services. All the web based solutions ended up suffering from the same problem, as your library starts to get quite large the service would become slower and slower. I can add quite a few images each day to my stream, so web based services were not ideal for my needs. Eventually I settled on Ember. Its combination of screen capture, RSS feed reader (Where I store all my visual RSS feeds) and image catalogue are ideal.
Preferring to spend down time when travelling doing something productive, (on a crowded train, sometimes it’s not practical to get the laptop out and start blogging) I like to use writing software that is not device dependent and can always access my content. Given that I use Jekyll for the blog, the ability to write & save the text in Markdown is a big plus. To that end IA Writer is usually my tool of choice. In actual fact, I do the initial write-up and first pass to every blog post in IA Writer. Once it is complete, I move the post in to Sublime Text, switch to Full Screen Distraction Mode
and add the YAML data before doing my final pass and edit.
When it comes to designing sites I have been refining my process over quite a few years. My aim is always to answer the brief given, its important to me not to
re-invent the wheel, you only have a finite resource to spend on most projects so the key is to use your time in the most efficient approach. Iterating over various solutions quickly using pencil and paper yields results quickly. I try to lock myself away somewhere (so I can’t be disturbed). Turn off the iPhone, set 1 hour on my stopwatch and begin. It may seem a little odd, but over the years I have learnt that I perform well under pressure, it helps my brain focus in on what really matters. The other ‘fun’ but ultimately timely endeavours that may have distracted me in the past gets purposely relegated to when I have time left over in the project and don’t cause the project delivery to suffer. This also permits the initial delivery to really focus in on the core of the idea. Remember a project is usually a moving target and subject to change, ultimately ideas will always evolve in the clients mind (and once it’s been delivered to the public) taking you further from the agreed deliverables, so it is best not to try and dazzle them with other possibilities at this stage.
I create a mood-board in Ember and collect my thoughts. I then usually write some basic Use Cases to help satisfy the brief. Once the Use Cases are done I move on to wire frame sketching. I find a pencil and paper the most helpful here. It allows me to iterate very quickly over and over until it feels like an idea is coming together.
Once the wire frames and site-map are complete. I use Keynote to quickly create them. Keynote is such an unbelievably intelligent piece of software to create mock-ups and prototypes in. It also affords a large amount of control over fidelity. Certain clients will not be happy with a Balsamiq hand drawn approach. Others will want to see a stripped back minimal pass for fear of spending money on going to far the wrong way. Keynote allows you to add a layer styling rapidly using the copy & paste styling meaning you can go from boxes on a page to full fidelity wire frame minutes.
With the wire frames and site-map agreed I move on to creating the designs. My tool of choice is still Photoshop. I have tried many other tools in the hope of replacing it someday and it’s never felt the perfect tool to design sites. The closest alternative is Pixelmator which is closing in on Photoshop’s feature set fast. In recent times, it’s clear Adobe has realised they may no longer be the only software choice and have begun upping their game adding quite a few features to keep web designers happy, in particular the server and asset generation tools.
I am a big fan of Slicy and it slots in to my work flow perfectly, however more recently instead of using Slicy I have been using Photoshop asset generation tools. The tools are pretty similar to Slicy, in that they do automatic image exporting based on layer naming. Slicy can still come in handy however when you want to use its image mapping feature, so it still gets used pretty regularly.
My process to create a site has been honed over some time until I have boiled it down in to a flexible yet robust approach.
Always Start With The Typography
99% of the time your site is primarily textual content, it is the cornerstone of your site, so choosing the right typeface can make or break your site. If the project does not have an existing brand I start by listing out the emotional responses the site should make. Once I am satisfied with the list I begin selecting typefaces that match those emotional responses. This stage is the most undefined, deliberately, because over time you begin to understand which typefaces work under what conditions, eventually you will gravitate to 3 or 4 that work under most circumstances (this can take years of working with multiple faces) and fit in with your design sensibilities. I mix and match the typefaces I have chosen until I am happy with the combinations, at the same time I will begin looking at suitable text sizing for body copy, headings and sub-headings. Once I have decided upon those factors the rest slots in to place quite neatly.
Choose A Scale
Now we have a rough idea on typefaces and sizing, I pick a scale to unify the design. It’s important to maintain as closely as possible to the sizes within the scale so elements don’t look out-of-place or proportion. Usually during this period the original sizes selected will change, that’s OK. Good design feels out the problem and discovers the true solution, rather than applying a fixed pattern to all. For creating a proportional scale, this can be any 2 numbers related by a ratio. You could select the size of the body copy and width of the site for instance, then use the golden ratio 1.618 to tie them together. If you’re new to creating proportional scaling I recommend using Tim Brown’s excellent Modular Scale as a resource. Once you become proficient at this, you might even start creating your own, based on the width of the spacing around the company logo, or the size of a corporate asset that has to be in place on each page. Anything to unify the design styling and typography will make the design feel connected and “just right”.
Define A Colour Scheme
The type and scale in place defining a colour Scheme can also be a tricky thing to get right. Again I follow a similar process to select my type. I refer back to my list of emotional responses and begin creating swatches that I feel match those responses in to two categories:
- Primary: The most critical responses.
- Secondary: The warm fuzzy feelings that accompany them.
It is then a case of mixing and matching the primary and secondary selections until I have a contrast and mix that feel right. Again this is about feeling your way. If you don’t have an existing colour Scheme to work from you need to iterate reasonably quickly to a solution but also discover the proper path rather than arbitrary picking your favourite hue, pairing it with a contrasting colour and moving on. You want your work to reflect the content and avoid falling in to the trap of designing sites that all look the same. Respond to your subject matter and content, not your own wants.
Create The Style Tiles
Once the colour Scheme and text have been chosen and the wire-frames done. I create Style Tiles to iterate very quickly over my chosen selections. This step allows me to try out some of the choices I may have not wholly decided upon during the last few stages of the process. It’s a great way to quickly test that all my selections work as a cohesive whole and to try adding or subtracting some of my possible other selections and sanity check my decisions have been correct.
At this point, I usually make 3 selections that I prefer and show them to the client. This is a great way to get feedback and correct anything in the process where my opinion and the clients have differed. It’s important to remember that as a designer you have been on a huge path of discovery up to this point, rejecting inferior ideas for superior ones. Your client on the other hand has not been on the same journey. Before you travel too far down the path on your own you need to ensure you are both on the same page. Using style tiles is a good approach because its still throwaway if you have got it wrong or your opinions differ to much but it is far less effort than mocking up individual pages to perfection and iterating endlessly upon those, which is often where the most time is lost on a project.
As with most web professionals, I use GitHub to store and manage my code with the GitHub client for OSX. I don’t mind using the terminal, but I’m not a masochist, I’d rather click the sync button than spend a few minutes remembering and typing in terminal commands if I don’t have to.
Absolutely the fastest and most consistent way to build a site is to take apart all the constituent components and create a “ウィジェット” page. This page usually consists of all the elements your site will be made up of, removing the grid, which can be added at the end.
Building all the components on a single page yields a huge number of positive results:
- It enforces consistency in the visual design.
- It helps you to easily spot repeating patterns in the code.
- It encourages re-usable code.
- Reduces errors in the code or clashing naming.
- Once the project is complete it provides all the documentation a new developer on the project needs.
- Adding new components later quickly reveal bugs and errors.
I work using a strict separation of development and live environments. The live environment and repository only contain the compiled production ready code, the development repository and environment contains all my debugging tools and un-compiled code.
In the developer environment I use Philip Walton’s HTML Inspector which is a marvellous tool to catch HTML errors and more. Where it really comes in to its own is using the custom rules to create your own validation patterns. When you are working in a team, it’s a great way to establish a coding pattern and validate against it. While I dislike BEM there are many people who enjoy using it, and if your that way inclined, it also comes with some rules pre-built for BEM notation, including Harry Roberts Inuit which is all the rage with the kids these days.
To complement HTML Inspector, I also use the excellent Holmes CSS Inspector. Holmes looks for errors in the CSS and highlights them using visual cues, its pretty comprehensive and really helps to enforce good practices.
On a side note, its also worth mentioning that occasionally I have to pick up a lengthy CSS file(s) from another team or developer and if it is quite complicated or heavily compressed with no uncompressed alternative I turn to ProCSSor. It’s the best tool I have found to quickly format a CSS file in to a readable format and have had no issues with it mangling code. If things are really mangled, before running the code through ProCSSor, I utilize the CSS Comb plugin for Sublime to bring some order to the chaos.
A caveat on pre-processors, while they are great and do save you time. Learn CSS first before jumping in to pre-processors, they can encourage bad practices in the compiled code and if you don’t understand 100% what the pre-processor is generating you shouldn’t be writing it. Learn to walk before you run and you’ll be better for it.
When writing your HTML it is important to remember that before adding the CSS the relevance of the mark-up should imply what you are trying to create. To keep myself always thinking of the structure I regularly use Microformats and more recently, have also begun integrating Structured Data. Following these formats helps you to constantly question if the mark-up is correctly reflecting the content. A further bonus is that it helps search engines parse the content more clearly and increase your search ranking.
Once widgets are complete I create my typographic grid. To speed up the grid mathematics, I use the excellent Soulver which is fantastic for web based mathematics creations.
Much has already been written on creating grids so I won’t go in to the mechanics of creating the actual HTML & CSS for the grid. When creating my grid, I always create my own preferring not to rely on other people’s solutions. The reasoning behind this is that just like everything else in the creation I want it to be tied to the scale I am working from, getting the grid right is the final piece to getting things looking balanced to the eye. That said, there is a rather dogmatic approach prevalent in web design at the moment over sticking to the grid without deviation, this is not recommended advice to follow in my opinion. Breaking from your grid can create tension, excitement and interest. The trick is learning when to do this and not to do it constantly without good reason or you risk losing the harmony in the design.
There Is No Spoon
A question I am asked quite frequently is:
What framework do you use, and what would you recommend?
My answer is something most developers aren’t ready to hear:
Why would you use a framework for a one-off site?
The reply from the developer then follows the format of:
I don’t just use it for one site, I use it for all my sites!
To which I would always respond:
How can you make decisions on the approach before understanding the project?
At this point, the developer usually thinks I am being awkward and wonders off, which is certainly not the case, more often than not they missed the point I have been making.
Frameworks are something I have been working on for around 8 years, where I would be working on a combination of small and extremely large projects every week. Around 5 years ago during this period I had an epiphany.
Day-to-day most developers work on multiple projects of varying size. The solution to remove the mundane and repetitive tasks is to create a framework. As time goes on this framework evolves to incorporate other features, we wax lyrical about how this is such a DRY approach, and saves us time, however what is actually happening is you are revising the same design or variations on that design over and over homogenising your approach, rounding off the corners to the point of perfection. A classic example of this is the common criticism levelled at Bootstrap:
It all looks the same
Bootstrap supporters will tell you that it’s perfectly feasible to make it look radically different and to a point they are right, but in essence you are carrying a lot of baggage to do that. When you use a framework, you are always tied to the ideas and decisions made in past projects by other individuals which can hamper creativity and new ideas.
That is not to say frameworks are without merit or not worth pursuing. Frameworks are perfect when working on a large scale site or application and form a key part of maintaining your code base as a cohesive whole. You need to consider your personal requirements, do you spend your time working as a freelancer or in an agency? Chances are you jump between multiple projects that need to be creative and different. Under these circumstances, it’s arguable that a framework is not actually helpful to your process and is forcing you down pre-defined choices before beginning a project, hardly ideal. On the other hand, if you work on a large site or application like Facebook or Twitter then a framework is the perfect choice.
So what do I use? When setting out on a large scale site or application project I usually create my own framework with the other developers based on someone else’s existing work, or we start from scratch, depending upon the requirements. However, for day-to-day smaller projects I don’t use a framework at all. I use a tool kit.
Fit For Purpose
My mantra for the last few years has been not to outwardly dismiss ideas, techniques and approaches but to carefully consider each when presented and try to understand if it is fit for my purpose. If it is not correct I look for another way. While in this mindset it became evident that over time when starting out each new project’s design process phase that I would be thinking ahead about how it would integrate with my existing code framework rather than focussing on being creative and solving the problem completely. I was slowly twisting decisions I had been taking based on previous projects outcomes, which in hindsight was pretty daft.
To correct this I adopted a different direction, I took the components that re-occur in every project, the clearfix CSS, the Sass grid equations etc. and created a tool kit of flexible stubs. The key here is not to go too far, you want to provide launching pads to begin coding and not a complete solution that’s ready to go, you want to provide as much flexibility as possible without making any design decisions.
Once the code is complete, I run it through the W3C Validators as a final sanity check and amend anything that may not be correct.
If you enjoyed this post and found it helpful, you should follow me on Twitter where I am happy to chat further, also check the blog again soon where I will be sharing my cross platform mobile application design process.
Update: I should point out that all my development is done on a Mac
Misc Productivity & Planning Tools
- GitHub client for OSX
- Sublime Text. Also see my Sublime set-up
- HTML Inspector
- W3C Validators