Hi, my name is Ludwig – Team Lead for mobile native applications and iOS software developer at TimeTac.
TimeTac is a leading time and attendance software as a service provider, which empowers everyone to focus on their most valuable resource: time.
In this TechTalk I will show you how we've converted a design proposal into a working piece of software. I will also talk about the challenges that we faced and how we finally added a fresh and new look to our dashboard, while maintaining all of the already developed codebase.
Ever since we released our mobile native clients, they've been successfully used by thousands of employees across many different industries. Over this period of time, we've not only implemented new features, but we also made sure that we focus on optimizing visual aspects as well. Both design experts and UX experts at TimeTac put in a lot of effort to research new trends and develop ideas on how those could be adapted by our applications. As software engineers, we're then challenged to turn those drafts into working products. The dashboard is one of the most viewed screens in our mobile native clients. It's also the first screen presented to our users when they log in to their accounts. As it contains a lot of important information, we wanted to make sure that users are not overwhelmed by the sheer amount of data presented. Hence simplicity is very important.
One of our main challenges was to reduce overall complexity, by allowing our users to show or hide certain information and freely arrange the order of individual items as they prefer. Due to their portability, mobile devices face certain limitations such as available screen space or hardware. We therefore paid a lot of attention to details when it comes to optimizing design and performance – especially on the dashboard it needs to be super easy to differentiate between different kinds of information, while giving the user a smooth scrolling experience to quickly navigate around. As you can see, content in our dashboard is grouped into different sections. Depending on the visualized data, each section can be divided into three key items: header, content and footer.
A header defines the context of visualized data, the footer offers an option to navigate to even more subject related data. The items inbetween represent context related core information, allow direct interaction – such as starting or stopping a task for example – and at the same time, they add the necessary visual spacing to balance the layout. Speaking of layout, we have gone the extra mile and we developed a specific one for iPads as well. It introduces a multi-column approach to make use of the significantly larger screenspace.
Comparing our already existing design with the new one, we had to carry out three tasks: we wanted to increase the padding around the content cells, we wanted to add rounded edges to the top and bottom of each cell and we wanted to add a subtle drop shadow. Consequently we were facing four main challenges. We wanted to adapt the drafts provided by our design apartment, reuse all of the already existing codebase, assure compatibility with our iPad layout and make sure that performance doesn't suffer. Since every section of our dashboard is divided into those already mentioned three key items, applying the required visual changes didn't work out, as shadows and rounded corners would bleed into each other and produce undesired results.
Our solution: a template cell. We created a single cell, wrapping all of our already existing code we had developed for the dashboard into its very own collection view. This way reduced complexity from three different items per section into just one. And this template cell reuses the already existing codebase and does the heavylifting for us. In order to resolve issues for necessary content height calculations, we implemented a specific method. It accepts an identifier in order to find out what we're going to visualize on a section base, a datasource with a list of items that we want to show and – last but not least – a sender parameter to learn a bit more about the calling method. When rendering a section for the dashboard, this method now handles any necessary content height calculations, depending on the items displayed.
As an example, we're going to take a look at the following piece of code. First, default height for header and footer are added. Then we have some logic, in case there are no recent tasks to display. Finally, we do the actual content height calculations – if there are recent tasks to display. And then there is some product related special configuration that has to do with the TimeTac back end.
As a result, introducing the proposed changes from our design apartment became rather simple. Because the drop shadow and the rounded edges could just be applied to our template cell. With this approach, we could use tools solely provided by Apple and we didn't have to use any third-party libraries or any complex custom code. Overall, this adds great value with regards to performance and future maintainability of our implementation.
The new layout on both iPad and iPhone can be seen here and it shows the visual changes – we have the drop shadow, the rounded edges on the top and bottom of each cell and the nicely added padding to the left and right.
With every new version of our mobile native clients, our goal is to build an even better product. We achieve this by challenging ourselves with new ideas and technologies – but most importantly we work together as a team and listen to feedback of our valued customers. As a team lead and a software engineer I'm very proud of having the privilege to be working with teams of amazingly talented people at TimeTac, which make all of this possible – and even more!
To conclude with a quote by Steve Jobs: "Great things in business are never done by single person. They are done by team of people."