The Reasons for MyLabBook Moving from Drupal to WordPress
The major reasons for moving from the Drupal CMS to the WordPress CMS can be summarized in the following points.
Significantly larger market share of WordPress – The market share of WordPress is about 20X of Drupal as of 2023. The large market share better suits the Sustainability criteria of being a SAFE ELN Research Platform.
The robust ecosystem of premium plugins for WordPress – Unlike WordPress and Joomla, Drupal has very few if any extensions (modules) that require payment. The disadvantage to Drupal’s approach is that individual developers or development teams are less incentivized to support a module beyond what it might contribute to their consulting practice or unless it is a key component of their support (e.g., for Open Social).
The Drupal code base is much more complex to work with – Drupal’s approach to custom content types from a site builder perspective is elegant and powerful. However, it has added to the complexity and made modules and extensions more difficult to build and to use.
BuddyBoss – The turning point came when we found that BuddyBoss was much easier to use and integrate with than Drupal’s Open Social. We see this as a consequence of the availability of premium extensions mentioned above.
We have enjoyed the development with Drupal for the last decade or so, but the experience with WordPress has given us greater flexibility and sustainability. Those qualities have made WordPress the obvious choice for the future of the MyLabBook approach for building ELNs and research platforms .
An Installable MyLabBook Demo with Simple Examples Built Upon a Robust Foundation
We have implemented an initial demo version of a Drupal based Electronic Lab Notebook (ELN) which shows some of the unique capabilities of this approach.
The Flexibility of a Drupal Approach
The overall approach is based on the use of custom content types, which allow us to attach fields as needed to the standard Drupal content type of a node. In this case, we only need two custom content types – the Experiment and the Protocol Step. The Experiment stores the information pertaining to a given experiment as a whole. The Experiment then usually references one or more Protocol Steps. Each Protocol Step then contains the appropriate sets of data fields where the researcher can store the data for the procedure that they are performing. The sets of data fields are then displayed using separate tabs for the given Protocol Step.
By using appropriate Drupal modules, we are able to accommodate numerous different types of data fields, including the following.
Task List – Customizable list of tasks to be done in any Protocol Step
Rich Text Fields – Using HTML formatting tags for variations in styled text
Data Tables – Configurable HTML tables to store and display data
Geolocation Data – Can be shown on a Google map or other maps with appropriate freely available keys. This can be used in conjunction with the Address fields for automatic lookup of coordinates
Image and File Uploads – You can designate what file extensions are allowable for upload (e.g., xlsx, docx, pdf, png, jpg)
URLs – you can record one URL or a list of URLs with website names that may be relevant to the protocol step
Tables of Specific Value Types – If you wish to capture a group of a given data type, then there are tabs that contain given types of data along with an associated label for each data item. The types of data that are available using this approach include integers, decimal values, floating point values, plain text values and date values.
Videos – Videos can either be uploaded to your server and displayed or they can be displayed from YouTube.
Easy Installation from a Repository
This is the first demo version of this approach where we have released the full source code on our GitHub repository. This repository is set up to allow you to easily install your own version of a Drupal based ELN. This uses an approach that is similar to the approach that many Drupal theme developers use to deliver an installable version of Drupal that uses their theme along with demo content. The installation steps are shown on the home README.md file of the GitHub repository.
It is our hope that this initial version can be useful for many situations where someone may want to use this freely available ELN approach for their research. With the flexibility of having access to multiple different data types, a fairly easy installation and thousands of additional freely available Drupal modules, there are a great many possibilities for customizing this ELN to a researcher’s needs without too much time or effort involved. With continued input and feedback and the resulting continued refinements, perhaps this approach can result in lower costs and improved functionality for researchers as they continue to bring about appropriate scientific and other research advancements.
Open Source Alternatives for an Electronic Lab Notebook
According to some recent articles in the science technology press, ELNs are a growing market. For example, a 2006-2007 article at Scientific Computing estimated that the market was about 50 million USD in 2005 and was growing at 20% to 30% per year. This makes a great deal of sense when we take into account the growing complexity of science and the massive amount of data that is collected and needs to be analyzed. This is true especially in the life sciences, and several of the commercial ELN offerings are targeted primarily at that market (e.g., CERF by Rescentris, Inc.).
What does this mean for non-commercial ELNs, however? And what does it mean for academic institutions who desire to prepare their students for a future where ELNs will be more and more common place? Of course, it is obvious from this website where we think at least one good solution to these questions lie. But let’s take a step back and see why we have chosen the particular solution that is presented on this website. What are the alternatives? What are the criteria to use in developing an ELN appropriate for an academic setting?
Let’s tackle the last question first and then see what kind of alternatives can satisfy our criteria. Some of the main criteria are as follows.
Cheap or preferably free – because most academic institutions are constrained by budgets and would have difficulty justifying spending much money on an ELN for students
Able to be customized for different scientific or technical contexts – the nature of scientific experiments is that although there are some commonalities, it would be advantageous for an ELN to be adaptable enough to provide differences for, say, physics experiments versus biology experiments versus mathematical simulations
Open source and supported by a viable community – this is a variation on the first point, but if the ELN is open source, then it is usually free. This makes it also much easier to justify with a funding agency because of the minimal cost and the likelihood that research funds will result in a contribution back to the community. Ideally, a viable community is also present, which will imply continuity regardless of whether one person contributes or not in the future.
Social networking capabilities would be nice – with today’s students becoming more and more in tune with social networking sites like Facebook and mySpace, it would be advantageous to utilize these capabilities in an ELN as well.
Fairly easy to set up, maintain and extend – while not strictly necessary, the easier it is to set up (everything else being equivalent), then the more widespread that we can expect the adoption of such a platform.
So using these criteria, we can narrow our choices. Criteria 3 suggests that the choice should be a popular open source platform. Criteria 4 suggests that it should run primarily on the web versus on the desktop. And criteria 2 suggests that it be fairly mature or robust so that people will have developed add-on components that can be re-purposed for scientific purposes. Criteria 5 suggests the use of a scripting language versus the use of Java, C or C++, at least for the mainstream of web developers.
Django – web framework based on the Python scripting language
Plone – web content management system (CMS) based on the Python scripting language
Joomla – web CMS based on the PHP scripting language
Drupal – web CMS based on the PHP scripting language
Django has the advantage of being written in Python, which is also a relatively elegant scripting language with an even larger support community than has Ruby. It also shows itself to run at about twice the speed of Ruby or PHP and can be run simply on the desktop as well as the web in a straightforward manner. There are also numerous Python modules written for scientific purposes on the desktop that can be repurposed for the web as needed. However, Django itself is a web framework instead of a CMS. And for the CMS platforms built upon Django, then there do not seem to yet be a mature set of modules available “out of the box” for many capabilities.
Plone is probably the most mature of the CMS platforms built with Python, and is relatively easy to set up as long as one has full access to server configurations. However, like Django, it is not as widely supported by internet service providers and thus becomes less available in many cases.
Joomla is a popular web framework also, and has thousands of add-on modules and some very nice looking templates available.
Ruby on Rails has the advantage of being written in Ruby, which is a relatively elegant scripting language and growing in its use. The framework itself lends to great productivity as well because of its standardized approaches. The myExperiment project has taken this approach.
In the end, though, we chose Drupal because of the following reasons.
The elegance of Drupal’s architecture – while the PHP scripting language is not very elegant as compared to Python or Ruby, the Drupal architecture is very elegant and flexible. The structure is very well thought out and lends itself to tremendous flexibility.
Incorporation of the Semantic Web technologies – Drupal has been the first of the popular web platforms to incorporate Semantic Web technologies on a wide scale. These technologies are being incorporated into the core in the upcoming version 7 of Drupal, and have been available as modules for version 6 for some time. This approach holds tremendous potential for scientific communication and research. We believe that someday in the future, perhaps the not too distant future, that Semantic Web capabilities will be expected for an ELN. With Drupal, we will be getting this “out of the box”, so to speak, before anyone else.
Breadth of available modules – as is documented in other areas on this site, the number of possible Drupal modules for an ELN is outstanding, ranging from plotting to spreadsheets to Google maps and many, many more. While Joomla may have some more mature modules in certain areas, they are often commercial as well, unlike Drupal. And Drupal seems to have a wider overall breadth of modules available.
Practical reasons – then we have the very practical reasons that the primary developer of this ELN is familiar with the PHP scripting language and with the Drupal platform. So that minimizes the learning curve for this approach and helps us to roll things out more quickly and easily. This is not a definitive reason, but given the other advantages, it gives us cause enough not to look further.
So that is some of the reasoning that went into the choice of the Drupal platform for our ELN. We continue to be happy with the choice, but also are interested in any feedback, pro or con.