Behind the curtain at Radiopaedia.org

I recently wrote an email to our editorial board about upcoming changes to the site, most of which are behind the scenes. A number of them thought that this would be of general interest; a glimpse into some of the issues we face maintaining and improving the site. So, here is the email, only slightly edited. 

Hi everyone, 

Just wanted to let you know that the long and arduous journey to getting Radiopaedia running on Ruby on Rails 4, the coding environment that Radiopaedia is written in is hopefully nearly over. Rails 3 is no longer being supported and thus the upgrade is mandated. This new version is now passing all tests reliably and running on our staging servers and will be deployed to production next week (barring any surprises). 

This is an example of the sort of maintenance work that a site like Radiopaedia needs to undertake, just to keep going. How big a job is this? Well,  just this 'update' required 4195 individual additions to our code base, 3984 deletions, 190 commits, 786 files changes. It has taken us 3 months of work by various members of the team at Trikeapps and has naturally cost a great deal (think of 3 months of the salary of a full-time professional developer, and you start getting a feel for it).

And for all that effort, what will you see? Hopefully nothing. Nothing at all. Not a sausage. Except, almost certainly a few bugs which despite our best efforts won't have been noticed pre-release. *sigh*

What's worse is that Rails 5 was released in August and so, in the near future, we will embark upon the same process yet again. 

As far as our upcoming multiple choice question (MCQ) feature is concerned, that is another rabbit-hole of back-end change. To be able to write MCQs is all well and good (that work is pretty much finished, and will be released soon to the editors) but that is not very useful unless we keep track of who has answered what and how. So, what will be first released is just the tip of the MCQ-feature-iceberg. 

We want to be able to be clever about showing users the correct MCQs for their level of training. We want to be able to identify bad questions, and track a user's progress etc.. We want to keep stats on every question and work out which are questions suitable for medical students, and which are for fellows or consultants, and we want to do this all mechanically. Down the track, we want users to be able to ask our app questions like "how well am I going compared to other users at a similar place in their training?" and "show me questions that users of my level tend to get correct". We want to use spaced repetition to make sure users are learning from the questions, not just testing their knowledge. We want to be able to cluster questions intelligently by difficulty and topic. 

To achieve this is non-trivial. The very first thing that needs to be known and tracked is the 'who', and it turns out that unfortunately, both the 'country' and 'position' parts of our user profile are not up to the task, both because of how the data was collected, and because there has been no reason for anyone to update it. As a result, almost every registrar/resident who created a profile in 2010 is now a consultant, but almost none have updated their profile to reflect this. And so, with a heavy tangential heart, we have embarked upon rewriting that part of the database, and it gets more complicated because in the United States they call trainees residents, and in Australia, we call them registrars, and the number of years of training are different etc... In the process of doing this, we then also realized that there are a bunch of other changes we need to make to the user profile. We need to work out how to prompt users to periodically update / confirm their profile setting, and naturally need to keep track of when that 'time to update' is for each user. We also need to work on the design and user interface of that process etc... You get the picture. For every feature that reaches production, there is a large body of supporting work that is essentially invisible, but nonetheless crucial. 

So it may not be a surprise that we are going to have a 'become a supporter' campaign for the month of December; you will see a banner under the header. We have only done this once before, a few years back, but now aim to do this every year. This is merely a way of making folk aware that the possibility of supporting Radiopaedia exists, and to give them an opportunity to help financially if they so choose. It also helps us predict our income and reduce our reliance on advertising. 

For those of you who are already supporters, thank you very much. Every bit helps. For those of you that aren't, please don't feel pressure to become one. As a member of the editorial team, you are already contributing a great deal to the site, and I also realize that not all currencies or incomes are created equal. 

Anyway, I thought I would share this with you, A) to give you a small peek at what is required behind the curtain B) explain why we sometimes go months without releasing any significant user-facing new features/improvement C) make you aware of the changes, so that if there are bugs you can let me know and D) get you excited about MCQs which I think will be a tremendous addition to the site. 

Frank

Associate Professor Frank Gaillard is the Founder and Editor in Chief of Radiopaedia.org. He is also an academic neuroradiologist and Director of Research in the Radiology Department of the Royal Melbourne Hospital/University of Melbourne in Melbourne, Australia.