All of the applications for the sleep lab are dynamic, secure, and perform transactions with a back end database in real time. The apps are securely redundant in their data handling to ensure that the only thing that would cause data loss would be someone throwing a device against a wall. Critical because if the lab loses any data it can ruin their scientific study.

Sleepy Scales is a brilliant app that captures survey data and coordinates to a server to store the data. The app questions are dynamically loaded based on the study the subject is taking part in.

BedTime is an application with the survey questions displayed based on a profile setup on the server. The dynamics of this application are a little different than Sleepy Scales, but it was still a fun app to build!

This is a fixed question set app that provides different types of interaction, including drop down lists, pickers, and radio buttons. Everything in this app is a custom built component, end look and feel decisions provided by the customer. It’s probably the most different of the applications in how it functions (excepting Melatonin) with all of the different radio buttons, secondary choices based on previous interaction and custom pickers.

There are some applications that look really complex, but in the end are not complex  to build, then there are applications like Melatonin - which is the exact opposite!  How complex can a two screen application be? Well, the answer turns out to be “pretty darn so”!

Melatonin’s complexity specifically comes from the time interaction in the center of the “cap” screen. Because the lab staff that uses the application is taught to notate time as (a) 24 hour clock and (b) without a colon between the numbers (so 1310 instead of 13:10) we were asked to create a 24 hour picker that facilitated their input.  Apple standard time pickers don’t allow for 24 hours (they’re am/pm) and certainly don’t allow for no colon between the numbers, so we built this 24 hour picker from the ground up. The pickers labels that are displayed all have values (in seconds) associated with them. Once they are selected, there is a conversion based on the known date, then an adjustment based on the time zone. All of that has to be done in the instant, because we’re checking to make sure the user (in this case the lab tech) isn’t putting their finish time before the start. Of course, to make the task even more fun, we did have to allow for a case where a user could have a finish time that *looked* like it was before a start time because they might do a trial that ran across the midnight time frame.  What do the users see? A simple to use application that they never even have to think about. And that’s the way it should be - even as the data gets stored to the server (and converted yet again) all the way out to the export, which formats the date and time one last time so that it can be imported correctly to their SPSS database for analysis.