image of toolkit incl hammer, pliers, etc

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.

Summary

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.

#becauseits2015

Published by

Bryce Wilson

Senior UI Developer @ SopraSteria - Paving the way in robust & automated front-end product development.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s