As an experiment we built a set of lightweight apps that made it easier to work with a typical company spreadsheet, usually an unwieldy shared document that everybody has to work with.

They often start out as low-tech solutions to a problem in the organisation but, as they grow, they become difficult to use and end up with poor quality data.

In the space of a few days we created a set of apps on Livestax to allow employees to submit leave requests, while still using Google Spreadsheets to store the information behind-the-scenes. Using the new apps, it’s easier to submit a request than directly adding a row into the spreadsheet. Each row is validated before submission, to spot any mistakes a user might have made and to make sure each cell is in the correct format.

Once a row has been submitted, a user can then see a list of all their submitted leave requests, and whether or not they’ve been approved yet. A separate app allows managers to see all outstanding requests, and to make a decision to approve or reject them.

The apps are built in Ruby, using the Sinatra web framework. Each app deals with a single task, but they all share common components like fetching data and building forms. Livestax sends some contextual data with each app request, such as the currently signed in user and their permission level. This meant that I didn’t have to build my own authentication system from scratch. Livestax also has a built-in authentication API for handling the sign in process with third-party services like Google Drive.

One of the nice consequences of Livestax apps being small and simple is that the whole project has been decoupled into a collection of separate workflows, each focussed on a specific user-need. It also means that the leave request apps work on mobile devices without any extra changes, as they’ve been effectively built mobile-first.

It took just a few days to get the apps up and running using the Livestax framework. The code is open-source on GitHub.

With some more time it would have been easy to extend the apps to support more places to store data and to try meeting other sets of user needs.

It would also be interesting to try extracting out some of the components into a more generic toolset – one where non-technical users with an existing source of data could easily build small task-oriented apps to interact with it.