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?

Export

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...

If you would like to support my blogging efforts, then please feel free to buy me a coffee at https://www.buymeacoffee.com/drnickm

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 around (~2007), so they are not mobile-friendly. Your site may look great on a desktop machine...

But it may look awful on a smartphone, which most students now have.

It may look OK, but it is impossible to read and use. In fact, the only way to use it is by zooming in, which is fiddly and makes it difficult to find your way around the site. 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 it was 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 pros and cons, and I have used both approaches.

1. Responsive web design (RWD)

This is the correct way to do things. However, this approach could be improved.

A well-designed website should separate the content (the words and pictures) from the layout. Typically, the page's design is controlled by 'code' in a file separate from the content file, called a cascading style sheet (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 than 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 page, which could be time-consuming for huge sites.

This separation of content from layout means that if it is possible to determine the screen size of a device, i.e., whether 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. As the webpage loads, the browser can run a test for the device screen size and determine how to format the page.

The 'pro' of this approach is that the content is displayed correctly for the device being used, and images and movies are shrunk to fit the smaller screen. However, the 'con' is that even though the image or movie appears 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 information (text): 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 using PHP or JavaScript. (As you can imagine, this makes things even more complicated.) Another problem is that the page may need to be correctly crawled (indexed) by the search engines as they may not be directed to the mobile version of the material, 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. 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 tricky question. Both approaches have 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.

If you would like to support my blogging efforts, then please feel free to buy me a coffee at https://www.buymeacoffee.com/drnickm

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.

We came up with the Hairy Tree Rat because 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 a 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)."

With the introduction of the Hairy Tree Rat, we now have the ability to control the genetics and adapt the parameters of the assessment. This empowers us to assess students against the learning outcomes with a high degree of confidence, knowing that the students haven't simply 'googled' the answers.

If you would like to support my blogging efforts, then please feel free to buy me a coffee at https://www.buymeacoffee.com/drnickm

Additional Resources

Sunday, 1 June 2014

Designing a virtual fruit fly lab using HTML5

A few years back (2011, 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 ran the lab four times).

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

We decided to make the lab virtual after thinking long and hard about the problem.

The problem

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

Therefore, for the online fruit fly practical, we needed to deliver something interactive and moving and, where possible, reproduce some of the students' experiences 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. 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 (judging by the speed at which W3C is moving, it will never be a finished standard); therefore, it is in a state of flux and liable to change. However, a number of the significant 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 helpful in dealing with this lab was animation.

Using the animation commands and tools that are available as part of HTML5, it was possible to produce several 'virtual' fly labs, and the final version of the practical had three such labs:
  1. Sexing fruit flies;
  2. Identifying fruit fly mutants;
  3. Determining the genetics behind the mutation.
All three 'labs' had the same underlying idea in that there was a small window with several 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 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

The student has 'anaesthetised' the flies in the above image, so they are no longer moving. Then, the student clicks 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 pretty straightforward, 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. This was a real shock, as I expected any problems associated with Internet Explorer. (It turned out that the lab would not work in Firefox because Firefox had yet to implement one of the key animation calls used to control the animation.)

The other problem was purely down to my code. The virtual labs rely on several '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, all the flies end up in the bottom right-hand corner of the screen. Although this does not detract from the lab experience, it is annoying!

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

Summary

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

The lab worked well, and there were no apparent problems or complaints during 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 that the site requires significant maintenance. The code base needs changing every year as the HTML5 standard continues to evolve, and the support offered by the different browsers continues to evolve.

If you would like to support my blogging efforts, then please feel free to buy me a coffee at https://www.buymeacoffee.com/drnickm

(* Gamification is using game-like ideas and strategies to help students learn; that is, the students learn while having fun and playing a game. 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 "hardcoding" key numbers into the formulas they are using. The consequence of doing this is that if the student later changes any of the numbers, these changes will not cascade through the spreadsheet, and this can lead to errors.

The video below demonstrates the importance of 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 into the spreadsheet is the raw data
  • All calculations 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:

Correct

And not...

Incorrect


If you would like to support my blogging efforts, then please feel free to buy me a coffee at https://www.buymeacoffee.com/drnickm

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!

If you would like to support my blogging efforts, then please feel free to buy me a coffee at https://www.buymeacoffee.com/drnickm

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...

If you would like to support my blogging efforts, then please feel free to buy me a coffee at https://www.buymeacoffee.com/drnickm