Good post on LIMS Finder debunking SaaS myths. SaaS isn’t for everyone but I can’t help but feel that any vendor without a true SaaS offering is going to have a really hard time – and there are a lot of ELN vendors who have backed themselves into a technology corner were providing a realistic SaaS offering is going to be really difficult.

Not that I mind that too much :-)

(of course any vendor can claim a SaaS offering, just as any vendor can claim to be web-based by wrapping their thick-client application in IE. Unfortunately there’s a world of difference between a marketing-led “Paper over the cracks” effort and a true solution. Tthe economics of SaaS will mean those vendors will quickly find their customers don’t renew and then it’s game over.)

 

It’s a well known but little admitted problem with Enterprise Software that the User Interface sucks, and that it matters – it’s kind of a weird “Don’t ask, don’t tell” thing.

Sadly we’re all conditioned to this, accepting it as the norm – to the extent that users feel bad because they can’t immediately use the product, and companies require as a matter of course that their vendors provide extensive documentation and training to make a badly designed product usable.

The Electronic Lab Notebook industry is no stranger to these problems, and in fact suffers more than most. Products are designed by Geeks (of the IT or science variety), evaluated by teams concentrating on feature count, and thrown at users who are just required to use them.

I’ve always been concerned with the problems created by the ELN selection process, but even when a product has been selected adoption is hampered by usability issues. Good products shouldn’t need extensive consulting, training, customisation to enable the users to be productive – they should “just work”. Of course there should be APIs and the ability to customise the system (and our products do) but that work shouldn’t be a requirement to get things going.

One of the best early decisions we made was to hire an Information Architect to work on PatentSafe. What I learned is that Usability isn’t just a matter of a nicely designed User Interface, it’s also about the concepts that the software exposes to the user. In fact, consistency and transparency are more important for usability than “prettiness”.

There’s a good article on ComputerWorld on how Bad Software Design Inhibits Use of Enterprise Apps. Some choice quotes from the article (I’d encourage you to read the full thing) with some comments…

“Software manufacturers are generally confident that their products will succeed on the strength of their technology,” Hambrose writes. “But products that don’t appeal to their users can be self-defeating. Whenever software systems create obstacles-technical jargon, ambiguous messages, illogical sequences or visual clutter-the people who use these systems will respond in a variety of ways.” That typically includes undesired behaviors that users (and CIOs and applications managers) know all too well-frustrating and inefficient workarounds, complete disregard for business process, or abandonment of the application altogether.

As a vendor I’m always interested in hearing from users about how we can improve our products, and it’s depressing the number of times something’s not quite right and they just live with it rather than shouting. All the stuff in PatentSafe that makes people go “Wow” has come from conversations which have started from us probing into what a user thinks is a minor issue not worth actually mentioning. This is the major reason we visit our customers face-to-face, and I often come away with half a dozen new feature ideas.

Sadly so many companies buy stuff over and above the real interests of the users – because the user’s don’t have a voice, or because they don’t know what to ask for. Yes, there are user representatives on the purchasing committee but they suffer from what I call the Toaster problem. Again from the article:

“Hambrose: It’s the same problem, different day: dashboards, CRM systems, or whatever is coming down the pike this month. And the dashboard suffers from same problem. The consumers of the technology-the business side of the house-don’t know how to ask for what they need. They ask for what they want. That’s different than understanding the need. The tech group on the other side of the house, they’re ready to buy or build what’s asked for.

Finally, I loved this bit on what happens when they are invited into product demos. (it’s a bit too large to quote in full here).

Some days I feel we’re punished a bit by evaluators because PatentSafe is too straightforward to use. Yes, there’s a lot of power there but we’ve worked hard to make the learning curve shallow and ensure you only need to understand the bits that are relevant to you. It really does take a lot more thought and effort to design a “simple” system rather than an complex one, a lot of watching how people adopt the system, and good communication with customers long after they’ve purchased and deployed the system. Ironically sometimes people evaluate PatentSafe against other products which take a week’s training and customisation, and feel the other solutions are somehow more “powerful”. Of course, they aren’t – they just make the user work harder.

This is why we encourage prospective customers to pilot – use the system in real life, get a feel for it. 90% of the time, they fall in love – even when compared like-for-like with other products and approaches. The other 10% is where we learn a lot about how to make a better product.

By the way, our IA is Karen Roles, she’s an excellent Information Architect and available for contract work – you can see her Portfolio here. We like her to come back every now and then to make sure we haven’t strayed too far from the One True Path :-)

 

The Project Failures blog has an interesting post on Chuck Norris syndrome.

Chuck Norris can fix everything without changing anything

And therein lies some of the problems people are hitting on ELN projects – they think that the old way of doing things will produce, if only they do it properly.

I’d argue that the old, “Big Software Project” way never worked all that well for something as diverse as science, and it certainly doesn’t work today – there just isn’t the money around to throw about hoping it will all turn out OK.

The blog post invites customers to ask: “Are our projects repeatedly late, over-budget, or not meeting planned expectations?”. Um, time for the ELN industry to look in the mirror!

Today we have to have the guts to admit that perhaps “One size fits all” (more accurately “one size will be made to fit all, dammit!”) approach isn’t the best way to approach very complex circumstances – even the best-designed software can’t compensate for the challenges of deploying very intimate software to a wide variety of use cases.

It’s time to tell our boss that we need a series of smaller projects which are more approachable, predictable, and less risky. If you work with the right vendors (and we’d hope we were one!) the total cost will be much less, your users will be a lot happier, and you’ll end up with a more integrated system than perhaps you can buy from someone who promises you can get everything from them.

Time for the quiet heros, delivering on time and under budget. Shame that doesn’t get the same press though.

 
This entry is part of a series, ELNs and the Credit Crunch»

Not all of the “Stuff” sloshing around the lab is the same, and distinguishing between them helps tease out the best place to store things. We use a simple Triangle Diagram (originally proposed by John Trigg of PhaseFour which really just tries to point out that stuff is related, but it’s at different levels of abstraction:

51DC4C72-5A54-4E90-B9D7-BA9AA67F3E31.jpg

It is quite hard to draw definite lines around things, but I think most people can appreciate that a raw data dump from an instrument is somewhat different from a report to management, or that an experimental write up in word is different from some tabular data in a spreadsheet. The differences between the levels come out in:

  • The software that’s used to read the file and interpret the content. Some will require very specific software (e.g. from an instrument vendor), but a PDF or text file can be read by many different things.
  • Who might be interested in the data. Again, some files are useful to anyone (for example, a report) but some only useful to certain people with specific training.
  • How long your company might want to keep the data, and indeed how long you are realistically able to keep the data. Typically the lower you go, the harder it is to keep something, so if you feel it’s business critical you really need to pay attention to the formats used.

This differentiation can really help in ELN System design. Partly it draws your attention to what needs to be stored in the ELN (typically the “Experiment” write up level), and what can be left in systems e.g. a database or a file server, which can be pointed to from the ELN.

Not everything needs to be stored in the ELN, and indeed it would be unrealistic to expect to be able to do so. The important thing is common keys so you can offer the user a link to more information, and the advent of web-based systems has made this level of “integration” so trivial one sometimes feels a bit of fraud describing it as such.

By building on the storage tools you have in place, and focusing an ELN on Experiments, the resulting system is cheap to run, costs little to acquire, and results in little disruption to existing practices.

You can read the final part of this series here.

 

This is a good post showing the problems of “Standards” and how they aren’t necessarily a guarantee of any kind of interoperability.

Standards can not force a vendor to be interoperable. If a vendor wishes deliberately to withhold interoperability from the market, then they will always be able to do so, and, in most cases, devise an excuse using the text of the standard as a scapegoat.

You can’t rely on any representations about a “standard” unless there’s clear evidence of different implementations working together.

This really matters for ELNs, for two reasons:

  • Your data is locked up in the ELN unless you know you have proved you can get it out.
  • The need for long term (typically 30+) access to proof of experimental activity for Patent purposes means you can’t rely on any of the existing vendors being around, or the software you are currently using being functional.

We recommend that customers reassure themselves before they purchase any ELN product that they can get the data they need out into some suitable format – you have leverage with your supplier before you purchase, after that you’re locked in. I am amazed how many customers are aggressive about price discounts etc. but don’t look carefully at the “open data” situation – which is surely much more important than a 3% cost saving on the license price.

There are a number of ELNs around at the moment which can’t reliably create a PDF of the experiment. To some extent it’s a hard problem, but my concern is the “How do we get our data out” is answered with a wave of the hand and “You can just export to PDF” and everyone takes that at face value. In fact in some cases the PDF export facility is unreliable, doesn’t contain all the data, and can’t be automated! Buyer beware…

In terms of picking good “standards” we prefer published, straightforward, and well-used file formats. In our case that currently means XML and PDF/A, both of which are very open and used extensively by a wide range of software.

© 2011 elnblog.com Suffusion theme by Sayontan Sinha