Hourglass: Transparent Timekeeping

How a simple conversation with a client about time-keeping led to some late nights, reflection on project tracking & a simple progressive web app…

Good morning/afternoon/evening (delete as appropriate)!

My name is Bryce Wilson; Lead UI developer for the UK Design Team based in Edinburgh. I currently work across multiple projects and platforms and it can be hard to track what I work on and for whom. For the client, it can be frustrating when they can’t get a fixed timeline on my availability.

Around the same time I was coming to the end of ‘yet-another-notepad’ scribble of loose time keeping, I had a chat with one of the project managers for a fantastic client I work with.

He was concerned that he wasn’t able to have a visible overview of all the contractors and consultants in his team. This is primarily down to the flexibility the project offers to the team; early starts, late finishes, working from home on occasions etc.

This screamed out an opportunity to fill a few needs with one deed:

  • Upskill myself on a few new technologies I’ve been itching to try
  • Get rid of my legion of notepads with illegible cave drawings and scribbles
  • Supply a very cool and awesome client with a solution that will enable them to continue providing us with a flexible working environment
  • Demonstrate to the wider community a landslide of user-centered design approaches being developed daily within the UK Design Team (headed up by Luke Jeavons) such as:
    • User Journeys – A visual representation of a path a user may take to reach their goal when using a particular product or service.
    • Usability Testing – To validate the effectiveness of the design and the way the user interacts with the system. This can highlight potential inconsistencies and issues with the product or service.
    • Wireframes – A visual guide that represents the page structure, as well as its hierarchy and key elements.
    • Interactive Prototypes – To show how interactive elements will work. Enables the product or service to be visualised, tested and validated before further development.
    • + much more

After speaking with some fellow upstanding colleagues, I took it upon myself to define an MVP backlog of simple requirements:

  • Allow access to a ‘clock-in’ system via any device and bypass any requirements for an installation
  • Login with work email
  • Allow manual entries of working hours
  • Allow a clock in/out feature
  • Keep it simple, avoid that (points in horror at existing time reporting tools in the market)

Given this was a pet project I didn’t want to overreach and take focus away from day-to-day within the Compass project and the Design Team so I gathered my weapons of choice and began.

Frameworks & Services

In order to maximize the time and effort spent getting this from farm to fork:

  • Contentful – an AMAZING headless CMS that has insane API control and access. I have utilized this to store and retrieve data in a fully secure environment
  • Vue.js – The MacDaddy of JS frameworks. I work with Angular, React, Node, etc and Vue.js slays them all dead. End of.
  • Element.io – A clean and simple Vue.js orientated components library for all the basic needs
  • Azure – The Sopra Steria single sign-on application front
  • Heroku – Free and simple app hosting with CD/CI Pipelines
  • Custom Node.js API Service – I have developed a customised API service to enable continuity of other applications I have created (regardless of framework) to knit together user and information

It started with a few hours in the evenings while my expectant wife lay on the couch binge watching Forensic Files (If I suddenly disappear, you know who to point the finger at!) I melted into my coding chair and got to work.

A few nights in and it begins to take shape; implementing simple features such as project and team control which is operated in the Contentful Dashboard. This allows me to add additional projects as they come up.

The first release of the app to my inner circle highlighted some interesting results:

  • Observation: One user found it difficult to navigate their way back to the current week & also found it time consuming to try to get to December for example, to input time
  • Suggestion:
    • Implement a ‘jump-to’ week selector where it displays the week information; allowing the user to easily jump forward or backwards in time
    • Always have ‘current week’ at the top of list to highlight the current week
  • Observation: Initial version did not allow for non-project codes such as holidays, training or meetings to be logged
  • Suggestion:
    • Allow time to be logged to ‘non-project’ codes through the same interface
    • Allow team leaders to see these days on the team leader view. This allows the project leader to see upcoming days where we might not be utilized. It’s no fun for the client sifting emails and syncing calendars to see why ‘Dave’ hasn’t shown up today!

Reaping the Hard Miles

A few seasons into Forensic Files (my wife at this point now knows how to dispose of a body in 50 different ways, just saying) and we start to have something testable!

As the app is cloud based I fired out a link to a few trusted amigo’s and it seemed we were pretty close to the mark!

With the intended users now having something tangible in their hands, the next goal was to give the client the keys to the kingdom – an external (or internal) team leader view.

A non Sopra Steria user can be set up within the system to retrieve all entries which are assigned to their project, including holidays, sickness etc.

Given that a lot of our teams are also internal, a Sopra Steria employee can also have a team control panel if they are assigned a team leader role.

The Verdict

After picking a handful of users to test the app, we took a period of 1 week to collect initial feedback and log any issues.

Each user was asked to carry out specific tasks and report back, for example:

  • Successful and unsuccessful clock-in/clock-out experiences
  • Test on different devices and networks (firewall etc)
  • Log upcoming holidays

The feedback from actual ‘live’ usage resulted as:

  • Request ability to add ‘half-day’ non-project events
  • Improve performance for older Android phones (now complete)
  • Return to same week that a logging was added to (now complete)

The client is very happy with the outcome so far and has adopted this very early MVP into the projects daily routine!

There is still A LOT to add to Hourglass but given its been about 40 hours of development from a single developer and some fantastic sound advice and guidance from the UK Design Team – I reckon it’s not half bad!

If you would like to ask any questions, please get in touch :


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.