As we move ever nearer to a public beta release of FatigueReporting.com on the 26th of October we’ve been busy polishing and fettling all those rough edges that come with such a fast moving project. As you might expect, once we started showing the software to the outside world we ended up changing our priorities for features to include or not include in the first public release.
One of these features that we had fairly low down our list of priorities was an analysis tool. There were a couple of reasons behind the decision to hold back the development of an analysis tool. First off, we didn’t (and still don’t) have a clear idea of what kind of analytics people need to do with a Fatigue Risk Management System.
There isn’t anything that we have found that is particularly prescriptive in terms what needs to be analysed or reported in terms of trends or causal factors. Our thoughts were that we’d get the event reporting system fully working, and then show it to some potential customers. At that point we would get their feedback on how they would need to use the system as an analysis and reporting tool. We also thought we’d have some time before we needed to think about that, because after all, you can’t do any analysis of fatigue events until you have built up some data first.
However, that viewpoint turned out to be pretty naïve. Almost anyone who knew anything about Fatigue Risk Management System told us categorically that we needed to have an analysis system from day one. We ignored that advice for a couple of weeks, but on Wednesday (2 days ago) we decided we’d reshuffle the project to-do list and move the analysis feature to the very top of the priorities.
Working to a spec which was one level better than the back of a cigarette packet, we got to work on designing and developing an analysis system. First thing first was to choose a method for all this. We’ve used a whole load of business intelligence and reporting development tools in the past and the one thing that we decided from the outset was that the application needed to work on any browser without the need to plug in or install third party software. So this ruled out anything running on Flash, Silverlight or any of those fancy animated tools that we know and love… That is because anything that is Flash or Shockwave based won’t work on an iPhone or iPad and any of the latest Microsoft stuff like Silverlight or Seadragon would need additional software to be installed on specific browsers, which could be a pain in the neck for larger corporate customers. HTML5 was going to be a pain to do in the figurative 5 minutes of time we had left – so we ruled out that option pretty quickly. The following conversation went something like this:
“What does Google Analytics work on? That’s pretty cool”
“Type that into Google and see what it says”
“Oooh… Google Charts API beta…. What’s that?”
“wow this looks workable”
Within minutes we’d fired up the chart wizard and were generating code that was making charts look like the scribbling on our notepad. 24 hours later, this is what it looks like so far.
This isn’t a million miles from the original wire frame I did when we first dreamed up the concept.
We’ve still got loads to learn about the Google Charts API, but it is well defined, flexible and feature rich. It certainly looks like it’s going to be able to do most of what we need – at least for version 1.
We’ve got some fairly grand plans for how we want to move things forward. All we need now is some ideas on the kind of reports and charts we need to present.
Please get in touch if you want to know more about FatigueReporting.com, or if you know what kind of reports are required to run a comprehensive Fatigue Risk Management System. Only ten days to go until launch!!
Author: Paul Saunders