Modern Front-end Development Workflow

Over the past couple of decades, the internet as evolved beyond just a tool for search information on desktop computers at work, colleges and universities to a tool that is now integral to our everyday life. At its birth, the possibility of having the internet on mobile devices and watches would have been viewed as science fiction; this is now reality and the future is even more exciting.

At the centre of the continual growth of the internet are ever evolving protocols, standards and technologies. HTML, CSS and JavaScript in all their flavours are still core to the delivery of the internet, working together to present a familiar interface to the user. To a typical non-technical user, a website page is the internet so developing modern practices are essential to the growth of the internet.

Modern front-end development workflow covers the practices being utilised by developers today. It allows the developer to build User Interface (UI) based on the industry standards, with reduce time for delivery, high performance, reusable and easy to maintain code.

A typical front-end developer stack consists of HTML, CSS and JavaScript. Modern front-end development workflow enforces best practises, automation and consistency between build applications.

The workflow for application development can be categorised into six phases

  1. Scaffold is the setup of a web project – the files structure, download libraries and dependencies
  2. Develop is the phase where the application is actually coded. Code review among developers is good practice at this phase
  3. Test is where the developed code is tested. This phase will help identify bugs and fixes. It is common to bounce between the Test and Develop phases until all bugs are identified and fixed
  4. Integrate – at this phase the unit code is integrated with the rest of the application
  5. Optimise – at this phase, the code is debugged, integrated and ready for deployment to the production environment, additional tests are carried out to ensure the application performance is optimised, for example page load timing and object caching
  6. Deploy is where the code is pushed onto the production environment so it is available to be viewed by the users of the application

Each of these phases can be automated to improve consistency and efficiency. Suggestions on tools and practises to help automate these phases are described below –

  1. Automating Scaffold – There are a number of tools available to accomplish this. Dependency managers like NPM and Bower offer features that will help automate scaffolding. The main difference between both is that NPM is used for installing NodeJS modules but Bower is used for managing front-end components like HTML, CSS, JS etc
  2. Automating Development – Tools like Grunt and Gulp will help achieve automation in this phase. There is a command line dependency when using this tool
  3. Automating Testing –3 types of testing can be automated:
    – Code format tests. The code formatting is checked to see if they follow industry best practices.  We can use tools like JShint or SCSSLint
    – Unit tests. The code is checked against tests to make sure it works correctly and that new code doesn’t break the functionality of other parts of the site. These tests are usually JavaScript-oriented. Tools like Jasmine can be used. (Jasmine is a behaviour-driven development (BDD) framework for testing JavaScript.)
     – CSS Regression testing. The output of the browser is checked to see whether it breaks part of the page that was previously coded. It allows us to make visual comparisons between the correct (baseline) versions of our site, versions in development or just about to be deployed (new). Tools like PhantomCSS can help with this type of test
  4. Automating Integration – A version control tool like Git can help accomplish integration automation. It allows developers to push, pull and merge code from different sources into a single repository (repo). It is also possible to enforce standard before a code merge to ensure that the merged code conforms to set standards. To do this, continuous integration (CI) can be setup to automate testing after codebase integration
  5. Automating Optimization – The automation here is about getting the code ready for the production environment and ensuring the code is optimised for best performance. This may involve processes like minifying and concatenating CSS and JavaScript, optimizing images and SVGs. Build tools like Grunt or Gulp can be used in to automate the optimize phase
  6. Automating Deployment – The final phase is pushing the optimised code into the production environment to be viewed by the public. To achieve this, a post-receive hook may be created. This will make the server automatically pull new changes whenever there is an update.

In summary, modern front-end development workflows can be a very effective tools in the successful development of web applications if implemented and utilised properly in the development lifecycle. The tools described above are not the only ones available on the market to accomplish automation. Different companies and individual developers will have their preferences to suit the way they work. To fully take advantage of the benefits of modern front-end development workflows, it is essential that organisations invest in training their developers. If the developer’s skill set is kept up to date, the organisation will see a direct improvement in its productivity and the quality of the code.

What are your experiences in this area? Contact me by email or leave a reply below.

New Year, New UI Toolkit

Everyone knows January is the ultimate time to undertake new challenges to better yourself, so why not apply the same get-up-and-go to the projects and challenges you face in your career path?

The Problem

One of the biggest issues facing UI (User Interface) development in the public/private sector today is that once you drill down past the surface it lacks consistency and understanding. It is easy to see why this is the case given that, in an environment such as a client side project, the UI development task is often assigned to someone with ‘a bit of experience’ with HTML or CSS. In this scenario, the developer would do what they normally do and get the results they normally get.

That is in no shape or form a criticism to said developer, they have merely been tasked with something outside their field through ignorance of better fundamentals.

To highlight the lack of consistency and understanding, I will summarize the widely absorbed and in-practice approach to general front-end development adopted in the majority of client side projects:

The project is developed not as two separate entities but as whole unit, the front-end becomes part of the machine that develops roots that only grow deeper as development continues. To add to this, it is usually always developed in such a way that it contains no best practices or full understanding of the tech stack and the alternative options available.

When a project is allowed to continue like this it becomes unmanageable and unmaintainable so when it comes to pass that issues with the UI and development have been ‘discovered’ it’s too late to do anything of any substance that will turn it around and instead you are left with your only available option – bring in a ‘UI developer’ to sit and painstakingly churn through code which is not native to them and fix bugs until the end of history comes about.

This HAS to change. This NEEDS to change.

The very definition of UI Design and Development has changed drastically over the past few years. No longer is it acceptable to bring in a ‘UI Guy’ in the final stages of the project to ‘Make it pop‘ or ‘Make it usable‘. To attain the results the project so desperately needs in the end-game, foundations need to be laid right from the get-go of the project.

That means letting the UI Developer use their knowledge and expertise to guide the experience set out by UX Designers, letting them use their own tools for the job and, above all, recognising that the front-end needs to be its own entity and not just an afterthought.

The Solution

You guessed it… the UI Toolkit! Well, that AND the whole part about recognising the issue and addressing it.

Over the past few months, our collective thoughts, ideas and woes in the UX Department have been brought to life in the shape of the UI Toolkit. What is this UI Toolkit and why is it so special, I hear you ask? Well, I’ll tell you…

What if I told you that in the weeks prior to any back-end technical work beginning on a new project, you could have a fully-working, production-ready application in your hands, for which you could gain critical feedback months ahead of schedule? That you could code to such a high standard automatically that when it comes to integrating with the actual back-end and databases, it does so at the flick of a switch? That it will take days, not weeks or months, to convey the UX designs from wireframe to production-ready screens?

I could be here all day asking you these kind of questions but I am here to give the answers to these and questions you wouldn’t even think needed asking.

Our UI Toolkit comprises separate modules designed to work flawlessly together. Quick, effective and progressive in nature – it pulls the latest components together and self updates on a by-build basis ensuring that you are always developing to the standards set out and defined by collective minds.

These components are a centralised resource that will be fed out to multiple projects ensuring that all developers are using the same standards, same tools and progression with the same overall vision set out. These same developers can also contribute back into the Toolkit by submitting suggestions and changes which are peer-reviewed and, if applicable, fed back into the master components – allowing other developers on other projects to update and receive the exact same improvements merged just moments earlier. Blinding, I know.

UI developers will be able to move from project to project in good faith, they will hit the ground running on familiar territory and be effective and productive from the get go instead of having to spend four weeks learning how to decipher three generations of a codebase passed from developer to developer.

There is nothing more soul destroying to a developer than entering a project and seeing no documentation, no bread trail or no clue as to what does why and what for. It may have started with the best of intentions but you can almost always pinpoint the exact point in which the developer gave up when you come across a function called something like “doSomething();”.

Every component will also have a ‘Styleguide’ – a master reference point for the developer to refer to when working on the project. These Styleguides will adhere to the best practices set out and allow the developer to copy and paste snippets of example code to use in their project. The Styleguides are also use the same components used to build the application so all the styling and code is 100% accurate to the project you are working.

The Build Tools

We have created automated build tasks designed to continually integrate changes that are made, whilst taking into account the developer’s working environment.

We use Gulp to automate every-day and unique project tasks that save serious amounts of debugging time, waiting time and time spent on development!

You save a javascript file: The file knows it has been changed, checks it for errors, runs unit tests where applicable and merges then minifies it, then reloads the browser you are working in to show the change.

You save a CSS/SASS file: Again it knows it has been changed, checks for errors, compiles then minifies it and reloads the browser.

You add new images to the image folder: It takes the images, compresses them and, if desired, creates a spritesheet automatically.

You need a cup of coffee: It detects this then… well, this bit doesn’t actually happen… yet.

These are just some small examples of what goes on under the hood of the build tools. If you can think of a task or issue that faces the front-end, there will be a 99.9999993% chance of being able to run an automated task to fulfill it saving development time once more.

The ‘White Label’

The ‘White Label’ refers to the starter project readily available for UI Developers to grab and get their project of the ground in one simple command. One command and you have 10 available example pages that follow best practices and guidelines. Examples would be:

  • Login/Register screens
  • Search page
  • Search results
  • Search item
  • News feed
  • News item
  • Notifications

All of these types of pages work against a dummy API to allow access to flesh out the UI according to wireframes provided by the UX process. The dummy API can also simply be switched out for the real thing once the backend comes into focus with no change to the structure of the application at all.

Effectively, what this means is that the whole application can be created against the same data structure that the back-end will provide, using the same ajax requests but against a set of development files instead. This benefits EVERYONE for obvious reasons. Feedback, understanding of data presentation, highlighting missing or incorrect data are just some examples.

As the UI Toolkit progresses, more variations of the ‘White Label’ will come to exist and when each one does, it will be on the best practices and guidelines available ensuring we always produce a consistent, clean and effective UI.


As you will have established – the UI Toolkit is all about automation. Consistency. Structure. Evolving. The current UI Toolkit is very much still in its youth but as it grows it will lead the way in UI Development. It will save huge amounts of development time, resource and become a recognised standard in which all projects should adhere to in order to fulfill its true potential.

We welcome any feedback or concerns as we strive to ensure the UI Toolkit is as robust and versatile as can possibly be and welcomed with open arms and not resentment and hostility. Leave a reply below or contact me by email.


Demystifying UX: it’s just like riding a bike

What is UX design?

Ever since the term “UX” (User Experience) design started being used a number of years ago there has been a bit of confusion, especially with clients, as to what UX design actually means. We can explain the methods and processes that we use, but it has always been a bit of a vague description.

The main confusion tends to be that people think that UX design is just a fancy name for (UI) User Interface design. It’s very easy to see how this could seem the case. A lot of the deliverables that a UX designer produces can be very similar to that of a UI designer, but there is also a lot more work going on behind the scenes that is done to produce results that are not as easy to see.

How can we clear this up?

There is always a difficulty in creating a mental model of a digital product. Even with digital products that we use every day, such as email. We tend to default to the visual cues of the product, the email or the inbox, when describing its processes, even though there is a huge amount going on in the background.

One of the reasons for this is that digital products are intangible. We can’t easily lift open the lid and see how all the gears fit together, so this makes it difficult to describe how they work and what they do.

It is a lot easier to explain what a physical product does, because it’s a lot easier to show how it does it. It’s more straight forward to open the back of a clock and see how the bits fit together than to show someone code and explain how it fits together.

A better way to describe what UX design is, would then be to relate it to a physical object that everyone can relate to, and explain how the design of the product is changed to create an experience for the user.

The product

Let’s take a bicycle. It’s a simple product that has been produced for many years and that everyone can relate to. When someone mentions the word “bicycle” or “bike” there is instant recognition as the shape of the product forms in the mind. No more information is provided at this stage, but with what limited information is available, a model is constructed.

The products components

As with any product there are different components that come together on a bike to create the whole. Some of these components the user interacts with directly, while others are there to allow the bike to perform its function. The user interacts with the handlebars, which  turn the front wheel, which steers the bike. While the user does not interact directly with the wheel, the effect they supply at the handlebars directly influences the wheel, which causes a change of direction.

Using this analogy, the cyclist’s interfaces with a bike are all the areas with which they actually interact to perform the task of cycling. These include the handlebars, the seat, the brake levers and the pedals. The other areas of the bike are what could be described as the “back-end system”. These are the components that control how the bike actually works, and the tasks that it performs. Examples of these are the wheels and bearings, the forks, the gears and the chain or the brake cables and pads.

On a bike it’s very easy to see how all these elements connect together to form a whole product, and how a user can interact with the product to create their end user experience – cycling.

How can the experience of “cycling” be designed?

It’s easy to understand what cycling is, but quite an abstract concept to explain. There are lots of elements incorporated into the experience of cycling that go beyond just the experience of interacting with the bike as a product.

The experience includes the feeling of speed, the wind rushing past, the feeling of leaning into the turn going around a corner, the muscle soreness from pedalling and the feeling of cruising along a smooth piece of road. This experience is the culmination of a number of factors including the product, the cyclist and external factors such as the gradient, the type of surface and the speed at which they are cycling.

This means that it doesn’t make sense to say that we are designing “the experience” as much as we’re designing with the experience in mind. We want the experience to be positive, but we can’t force it to be.

Designing without UX

A product like a bike can be designed without using UX design. It would involve being provided with a brief from the client and creating it with the information available.

A designer could have seen a bike before, or cycled a bike before, or even designed a bike before, so they would have in idea of what a bike should look like, and how it should work. They would pull on that experience and create a prototype that fulfils the requirements set down and with which the client is happy. It has handlebars, pedals, a seat, wheels, gears, chains and brakes: everything that the user needs for the bike to work and for them to be able to cycle on it. The client makes a few changes to the design, and the prototype is created into a product.

This method of design can create a usable product, and can create the experience of “cycling” for the user, but we don’t know if the experience is a good one. There are a number of factors that were not considered and, as such, might mean the user having an unpleasant cycling experience.

Designing with UX

Some of what is mentioned above also applies to designing with UX. Once provided with a brief from the client, the designer may have a rough idea of what a bike could look like based on their previous experience. This would not, however, be the design that the client sees. There are other steps that will influence the design before then.

The first step is to ask the client why they want to produce a bike? Who are they making it for? Who is the target audience? What are the goals for the business when producing a bike? All companies need to sell their products to make profit so that they can continue to operate, although some have very different reasons for doing so.

For this example, let’s say that the target market is 16 to 24-year old males, and the company wants to make a profit by selling enough of their bikes, but they also want the target market to associate their brand with well-designed, solid products that perform at a high level. This information can be used to create “personas”, which gives the designer a reference point for all the design decisions that they make throughout the project. It is to ensure that they are designing for the user, not for the client or themselves.

Now that we know who target market, and the business goals for the product, we can start to research what the target market want from the product, and how competitors that already have the desired brand image have achieved that goal.

User research with the target market will discover that a large number of 16 – 24-year old males are interested in mountain biking. This includes cross country, trail and downhill mountain biking that can be done all over the country, and also at specific specialised areas in forests and national parks.

The competitor analysis of other companies in the area shows that those who produce quality, high-performing products use strong, solid and light materials, and have put their products through rigorous tests to prove that they perform at the highest levels. Research into these products give the designer an idea of what designs have proved to work successfully, and can influence the product that they are creating.

Using this information, the designer can begin to create a prototype that is tailored to the target market and the task identified, is using the appropriate materials, and is using known effective design solutions. The designer will also pull on their own experiences from previous products that they have worked on and incorporate them where appropriate.

This prototype is then tested with users in the target user group and in the environment where it is most likely to be used. It is unlikely that the first design created will be the most optimal, so the feedback provided from this testing is fed back into the design followed by further cycles of testing and design iteration until the design is the best that it can possibly be. Only then will the design be put into production and the final product created for sale.

However, this isn’t the end of the product life cycle. The designer should take feedback from those who have bought and used the product extensively to see how it can be improved, and release regular updates to the product, creating versions 2, 3 and beyond, getting closer and closer to providing the best cycling experience for the cyclist.

Just like riding a bike

It’s clear that the bike produced using the non UX method will create a bicycle – it will have handlebars, a seat, wheels and all the other components that make up a bike, but if it was used in the same scenario as the one that was produced using the UX design method, then the experience for cyclist will be very different.

So, UX is just like riding a bike, but the experience can vary quite a lot depending on the bike.

What do you think? Leave a reply below or contact me by email with your thoughts.