These days, a criterion of looking for a new LIMS, ELN or LES is more and more commonly that it have mobile capabilities or some other mobile factor. More customers are looking for this. Yet, how critical is this on your requirements list?
Using Your LIMS in a Browser
One way to allow mobile devices to use the software is to use it in a browser. Technically, you can purchase something like Citrix and you can run your programs through a web page. If you absolutely want your software available within a browser, you can do it without the software vendor making changes to their system. I’ve had customers do this, used the applications in this manner, and they seem to work fine, as long as the customer has properly set them up and tools such as Citrix can take some time to get properly setup. But this is some amount of extra cost and work.
Using your software directly in a web browser without something like Citrix depends on whether the software vendor has made that available and has done that for all the parts of the software you need to use. I mean to say this: it’s fine to get the main part of the software running but if you specifically want to use some of the add-ons to the software on your mobile devices, these also need to be compatible with the browser(s).
But with all this, each software package is optimized to be used within a certain browser. Some of the software vendors make an effort to rigorously test with multiple browsers, as well, meaning that they might suggest a certain browser but be able to tell you that they know the software also works well with specific other browsers. Other vendors don’t do that and you need to use the browser they tell you to use or you’ll have unexpected consequences.
Browsers and Devices
Even if the software vendor tests across various browsers they would also need to test across a variety of devices because each device works a little differently AND remember that the size of screen will affect the function you want to use will be practical. You wouldn’t try to do stability grid management on a cell phone, for example, but some functions need to be given a try to determine whether they’re practical to use on the screen size you’ve selected.
If you haven’t run into this, you’ll be surprised how many problems you can run into. For example, with a big result entry grid, you might run into lots of data entry errors because the device you’re using it on was not the intended device to be used with that screen. Of course, you can get around this by hiring someone to do nothing but verify data entry, right? 🙁
But the issue that each device works a bit differently and that each browser works a bit differently means that some functions just might not work with the combination you select. And this is where I get to the “maybe you don’t care that much bit” because…
Write an App
While software vendors might provide some “apps” to run directly on specific devices and for specific functions, you can also just write these if you have internal programming experience. Now, I should add that learning to do this is a little different than other types of programs your staff might have written but, depending what kind of programming they’ve done, this might be something they can handle.
My main point is this: buy a LIMS based on the price and features you need, and one that basically runs with the types of databases or platforms that you need. Past that, identify specific areas where you absolutely need mobile technology and, if the software vendor doesn’t offer it, just write it or pay someone to write it. In fact, even if they do offer it, you still might need to get something special for your own implementation.
At this point, if you were a software vendor, it would be somewhat more difficult for you because you’d probably be trying to make it work across many browsers and devices but, within your own LIMS, ELN or LES implementation, the variety of devices should be small. If you’ve properly standardized your devices, your program should be able to be written to run with a single device, two at the most (one smart phone and one tablet, if absolutely necessary). So, where I talked in the past about my struggles to write programs that were more generic and could be used across devices, I was doing that to make it work for a variety of customers. When you’re writing it for yourself, you don’t need to do that.
The uses for our software on mobile devices tends to be rather specific. Most implementations don’t actually need to do this and, for the ones that do, the pieces of the system for which this is needed should be able to be clearly identified within your requirements and they will be limited. If you feel frustrated that you are finding quite the right combination you just need to look at this differently than you have been.