Saturday 4 October 2014

Looking for an ELISA plate reader, and why you shouldn't get a HumaReader HS

Before I start this post I would just like to state that the views expressed below are my own and not that of my employer.

For the last 18 months I've been trying to buy an ELISA plate reader, with no success.

Admittedly enzyme-linked immunosorbent assays (ELISA) are not new and have in fact been around for at least 30 years (I first heard about them during my first degree, and they were viewed as a replacement for the radio-immuno assay (RIA)). So, on the one hand you could be argued that the technology is old and well-established, or that it's a technology that is had its day. Either way you would expect the market to be mature and able to provide suitable equipment.

When I started looking for an ELISA plate reader I was struck by how old all the machines appeared to be (in a number of cases designed in the 1990s, and a few machines in the early to mid-2000s), the poor design of their user interface and how difficult it seemed to be to get data in and out of the machine (one company offered me a machine with an attached dot-matrix printer - I had no idea such printers were still made, can you even get the paper). What was really surprisingly was how few of the machines could be networked, and how old the input/output ports were on the machines.

What I was looking for was a modern machine that could easily export results either directly to a server, or to a USB data stick. You wouldn't think it would be that difficult to find such a machine? How wrong I was....

After two rounds of procurement (nothing suitable in the first round, so I dropped my requirements) I finally settled on the HumaReader HS as it appeared to be the best of a bad bunch. The machine, from what I could see in the literature, did have a rather clunky user interface but, and this was in my opinion it's big selling point, it did have two USB ports, a LAN port, and an SD card reader. From what I could gather from various promotional leaflets and the user manual, the machine was able to export data and methods to the USB ports, and it could be connected to a computer for direct export to Excel (see below). To me this seemed to be a good match as it meant we could easily collect and export data from 25 to 30 ELISA plates in an undergraduate practical and then redistribute the data to the students for analysis.

IMG 1276

The HumaReader HS ELISA plate reader - it can read plates, but you can't get the data out of it...

The machine was delivered to us after 8 to 10 weeks and installed. It was only at this point it became apparent that the export to the USB stick was in a proprietary format (Why didn't the engineers think to do a simple CSV export? I guess they were not very good engineers?) that could only be read by another HumaReader HS machine. I really cannot see a reason for wanting to do this? Maybe the methods when setting up a number of machines, but why the data?

IMG 1278

Ports on the back of the HumaReader HS ELISA plate reader - there may be data ports, but don't make the mistake I did and actually think you can export data

So, strike one, no USB export. So to my fallback plane... Export to Excel.

Unfortunately the HumaReader HS doesn't even seem to be able to export to Excel. When I raised this with the company (both the local supplier and the actual maker of the machine) I didn't receive a satisfactory response. In fact today I received the email below:

"Good day to you.
After several attempts, we managed to sort the data to excel format by using a customized Microsoft word Macros’ script.
The process is involved few steps as following:
1) Transfer the readings from ELISA reader to Laptop (LIS format).
2) Open the data which in LIS format to notepad, copy and paste the data to Microsoft word.
3) Sort the data by using a customized macros’ script and the data will be saved in excel format.
4) Open the excel format data and sort the data accordingly.
In Upon the sorting, the data is as following and for detail please refer to attach file."

Is the company serious? It would appear they are! To have to do this for 25 to 30 plates in an undergraduate practical would be an absolute nightmare. What century are we living in?


An extract from the HumaReader HS Reader promotional material...

How do other people cope? How do they get data out of the machine? Why would you design a machine from which you cannot export the data? Absolute madness.

Today I have told the company they can collect the HumaReader HS Reader from the lab, and refund the money.

So, I'm back in the market for an ELISA plate reader. As for the ELISA practical running in a few weeks? Guess I will have to be creative...

Declared conflict of interest: I am really interested and supportive of open data standards that allow the sharing of data between scientists and different labs. I heave worked on data standards in proteomics and was involved in establishing the 'Minimum information about a proteomics experiment (MIAPE) standard.

Sunday 10 August 2014

Is your teaching website mobile friendly?

Here is an interesting question... Have you tested your teaching website on a smartphone? If not, try it... I'll wait.

Many websites were produced before smartphones were really around (~2007), so they are not mobile-friendly. Your site may look great on a desktop machine...

But on a smartphone, which the majority of students now have, it may look awful.

It may look OK, but it is impossible to read, and almost impossible to use. In fact, the only way it can be used is by zooming in, which is fiddly and means that it is difficult to find your way around the site. Basically, students will get bored and not engage with the site, no matter how wonderful it is.

However, the site would look much better, and be more user-friendly, if is displayed correctly, and didn't require any zooming.

The solution to this problem is to rewrite the site so that it displays correctly (or is at least usable) on mobile and desktop devices, and this can be done using one of two methods:
  1. Responsive web design (RWD)
  2. Mobile redirect
Both these methods have their pros and cons, and I have used both approaches.

1. Responsive web design (RWD)

This, in my opinion, is the correct way to do things... However, there are some disadvantages to this approach.

A well-designed website should separate the content (the words and pictures) from the layout, and typically the layout of the page is controlled by 'code' in a file, that is separate from the content file, called a cascading style sheets (CSS) file, which is loaded by the 'content' page in the web browser. These CSS files control the way the page looks, that is, the size of the text, the fonts, the positioning of text and images etc., and they can control more that one page.

Designing a website that has content and layout style separated in this way means that if you suddenly decide that you want all your text displayed in white on a black background, instead of black on a white background, then if you have designed the site correctly you only have to change one file, the CSS file, and all pages on the site (and you may have one page, or you may have many 1000s) will display the text in that way. If a CSS wasn't used then changes would have to be made to each individual page, and for very large sites this could be a very time-consuming job.

This separation of content from layout means that if it is possible to determine the screen size of a device, i.e. it is a large desktop computer screen or a small handheld device, then different CSS files can be called so that the webpage is optimised for the device. And this is what happens, as the webpage loads the browser can run a test for device screen size and determines how to format the page.

The 'pro' of this approach is the content is displayed correctly for the device being used, and images and movies are shrunk to fit in the smaller screen. However, the 'con' is that even though the image or movie appear smaller their files are not reduced in size so pages may load slowly on mobile devices with low bandwidth.

I used this approach with my main website:

The browser detects the screen size and uses one CSS file for large (desktop and tablet) screens and a different CSS file for small screens.

2. Mobile redirect

With a mobile redirect, the browser still determines the screen size of a device, but in this case, if it detects a small screen it will redirect the page request to a webpage specifically written for mobile viewing.

The major disadvantage of this approach is that you have to maintain two sources of the information (text), that is, one source for the desktop, and one for the mobile. However, this problem can be resolved by holding the text in one file and loading this dynamically into the 'desktop' or 'mobile' webpages by using PHP or javascript. (As you can imagine this makes things even more complicated.) Another problem is the page may not be correctly crawled (indexed) by the search engines as they may not be directed to the mobile version of the material, and so no one may find it!

A significant advantage of this approach is that images and movies can be resized to better fit mobile devices and this means images and movies will be in smaller files, which will, therefore, load faster on mobile devices with low bandwidth. Again, this means that two versions of the image or movie file will have to be produced - one for the desktop, and one for the mobile.

Which is best for me?

This is a tough question. Both approaches have their pros and cons. Personally, I prefer solution 1, Responsive web design (RWD), however, for sites rich in images and movies solution 2, Mobile redirect, maybe a far better solution as pages will load faster and students will get a better experience.

Wednesday 11 June 2014

Say hello to the hairy tree rat.... The latest genetics model organism!

In a recent post - Designing a virtual fruit fly lab using HTML5 - I wrote about how I had replaced a fruit fly genetics 'wet' teaching lab session with an online session written using HTML5. However, one thing I didn't mention was that we invented a new 'model organism' for the assessment - The Hairy Tree Rat.

The reason we came up with the Hairy Tree Rat was that it had become apparent from the original practical that the assessment on fruit fly genetics was 'compromised' as all the answers were available online, which meant that students could 'google' a mark of 100%.

As it now says in the practical:

"You have been tasked with learning about a newly discovered mammal; the hairy tree rat. Found on a single island it seems to bear resemblance to the naked mole-rat but lives mostly in tree canopies and is hairy! The coat colouration is unusual; most of the rats are rusty coloured (like the tree bark) but some are brown and others are tan coloured. You need to work out the genetic relationships for colour; assume all rats are from true-breeding lines (unless the litter is specified)."

By doing this it means we can control the genetics, and we can change the parameters of the assessment, so we can now assess the students against the learning outcomes, and be fairly confident that the students haven't 'googled' the answers.

Sunday 1 June 2014

Designing a virtual fruit fly lab using HTML5

A few years back (20111 to be precise) we were faced with a 'crisis' in the delivery of a first-year fruit fly genetics lab. The students didn't seem to be getting as much from the lab as we would have hoped, and it was getting increasingly expensive and difficult to run the session with large groups (we had ~350 students in the year and we run the lab four times).

When the lab was first put together it was being offered to students studying the genetics degree. For them, it made a lot of sense as fruit fly genetics was at the core of the degree. However, when we introduced the practical to students studying other degrees in the school the session became problematic. Yes, it was needed as we felt that the students studying the life sciences needed the basic genetics training, but we felt the students were not really taking as much from the session as we would have liked.

Having thought long and hard about the problem we decided to make the lab virtual.

The problem

Having run a number of virtual labs over the years in bioinformatics and protein analysis I was aware of the problems involved in delivering such material and also how the static nature of a web page, and of websites in general, can be very boring and tedious for students. Click, click, click....

Therefore, it was decided that what we needed to do for the online fruit fly practical was to deliver something that was interactive and moved, and where possible reproduced some of the experiences the students gained in the traditional fruit fly practical. It was clear that there was a need for animation, and possibly some 'gamification'* (a word I don't like) to engage the students. It turned out that the solution to this was to use HTML5.

The solution

HTML5 is a new web standard for the language that describes how a webpage should look and feel in a web browser. HTML5 is not a finished standard (and judging by the speed that W3C is moving at it never will be a finished standard), and therefore it is in a state of flux and is liable to change. However, a number of the major web browsers such as Internet Explorer, Firefox, Safari and Chrome have already decided to adopt parts of the new HTML5 standard, and one part of the new standard that has been adopted, and was most useful for dealing with this lab, was animation.

Using the animation commands and tools that are available as part of HTML5 it was possible to produce a number of 'virtual' fly labs, and the final version of the practical had three such labs:
  1. Sexing fruit flies;
  2. Identifying fruit fly mutant;
  3. Determining the genetics behind the mutation.
All three 'labs' had the same underlying idea in that there was a small window with a number of fruit flies running around which the students were able to 'anaesthetise', so they stopped moving, and which they could then examine by clicking to get an enlarged image (see figure below). The students then answered questions associated with that particular section of the lab, such as what was the sex of the fruit fly, the type of mutation (if any), and determining the inheritance patterns for different crosses of fruit fly mutants.

Screen Shot 2012 02 23 at 07 24 02
Virtually sexing fruit flies

The above image is of the fruit fly 'sexing' lab - unfortunately I cannot show you the animated version of the lab as I am unable to add the necessary javascript to this page to get the flies to move.

Screen Shot 2012 02 23 at 07 22 46'Anaesthetised' flies

In the above image, the student has 'anaesthetised' the flies so they are no longer moving, and then clicked on a fly to get an enlarged view. The student can then answer the question as to the sex of the fly.

Two final problems - one mine, one HTML5

Coding up the lab was fairly straight forward and after some initial fiddling and debugging of the code everything was working. However, there were still two problems.

The first problem was that the virtual labs would only work in 2011 on the latest versions of the browsers for Internet Explorer, Safari and Chrome, and would not work at all in Firefox. For me, this was a real shock as I was expecting any problems to be associated with Internet Explorer. (It turned out that the reason the lab would not work in Firefox was that Firefox had not yet implemented one of the key animation calls that are used to control the animation.)

The other problem was purely down to my code, and I have still not got to the bottom of it. The virtually labs rely on a number of 'random' number generators and some trigonometry functions to control the movement of the flies. Somewhere in the code, I have something wrong because if I leave a lab running for an extended period of time all the flies end up wandering around the bottom right-hand corner of the screen. Although this does not detract from the experience of the lab, it is annoying!

Why do my flies end up in the bottom right-hand corner?


The lab was designed to run in a 3-hour slot with the students exploring the virtual fly labs for the first two hours, as well as completing a number of other tasks, including answering a number of formative questions, with the last hour used to start the online summative assessment. I was surprised to find that the students managed to work through the lab section in about 90 minutes, however, those that rushed the lab did find the summative assessment more difficult. I have now run the lab with over 1000 students in the past 3 years and this is a reoccurring theme, even when they are warned not to rush.

The lab seemed to work very well and there were no obvious problems or complaints on the day. The final marks for the online summative assessment were in line with other modules, and other work completed by the students, so overall I think the lab was a success and met the learning outcomes for the session. In the feedback, I have had from students taking the labs I have had no complaints.

One problem that I have encountered is the site does require significant maintenance as the code base needs changing every year as the HTML5 standard, and the support offered by the different browsers continues to evolve.

(* gamification is the use of game-like ideas and strategies to help students learn, that is, the students learn whilst they are having fun and playing a game. A sort of learning by stealth.)

Thursday 10 April 2014

The importance of cell referencing in Excel spreadsheets...

Using Excel correctly in the lab is an important skill to develop, and students sometimes get this wrong by failing to correctly use cell referencing and instead "hardcode" key numbers in to the formulas they are using. The consequence of doing this is that if the student later changes any of the numbers then these changes will not cascade through the spreadsheet, and this can lead to errors.

The video below demonstrates the importance of why cell referencing and why it should be used as opposed to "hardcoding"....

The key points are:

  • When analysing scientific data the only number that should be entered in to the spreadsheet are the raw data
  • All calculation being performed should reference cells (e.g. A2) used for the calculations and not contain numbers (e.g. the number from cell A2

So, this means that cells should be:


and not...


Thursday 3 April 2014

Video of Paramecium, C. elegans and Gram stained bacteria

The video below I put together from videos shot using the main teaching microscope during classes. The video shows Paramecium, C. elegans, and Gram-stained bacteria. Enjoy!

End of a journey - no more blogging at Scitable

For the last three years I have been blogging over at Nature Scitable about bioscience elearning and today, after 143 posts, I have decided to stop.

I have two main reasons for stopping:

  1. The pressure of day to day life as an academic. To much to do, too little time to do it.
  2. I have never really got on with the blogging platform at Scitable as I find it old, slow and clunky, and these days I like to blog in Markdown (as I am doing here).

It has been fun posting over at Scitable as it has given me the excuse, and therefore the time, to every so often step back from my day-to-day work and think about teaching and what I could, and should, do differently.

The problem now is I need to find an outlet for these 'teaching thoughts' and so there may be an increase in pedagogical material on this blog from now on...