So true, it isn’t funny.

This is why in PatentSafe we encourage the use of a phrase for signing documents. We can’t change organisation’s password policies (and most large companies use LDAP anyhow) but we can try to enforce sanity in signing pass phrases.

Maybe we needed short but hard to guess passwords years ago when memory was tight and CPUs weren’t able to chew through all possible combinations as fast as they do today. Nowadays having a 255 character string for a password shouldn’t be a problem – and it needs to be long to slow down brute-force attacks.

(there’s clearly features in PatentSafe to detect and/or defend against brute-force attacks but the first line of security should be sensible passwords).

As a general rule Apple MacOS X, Linux are second class citizens in the ELN world and it is all the salesperson can do to stifle a laugh when you mention those “other platforms”. The iPad and Android equivalents don’t even get a look in!

I’ve felt this situation is increasingly unsustainable – not only is Apple’s Macintosh experiencing a resurgence, but we’re quite possibly on the cusp of a tablet-drive revolution.

An interesting blog post from the CTO at the UK’s Department for Work and Pensions wonders if their current Windows desktop refresh might not be their last.

Personally, I think it likely this is the last version of Windows anyone ever widely deploys, though.

The reason? I think they’ll be fewer workloads that actually require a heavy deskop stack. Today, of course, we have all this legacy that’s coupled to the desktop, but in a decade, I really doubt that will be the case. Most stuff will arrive via the browser.

Talking with our larger Enterprise customers, it appears their Windows Desktop infrastructure is increasingly cumbersome and it is very hard to innovate in such a complex environment. In the smaller Biotechs there’s a real push to avoid cumbersome IT generally and there’s ready adoption of web and Cloud technologies, as well as additional platforms such as Macs and iPads.

The article makes a good long term point which ELN project teams should urgently consider:

From a strategic point of view, if you’re designing the future technology estate of a large organisation, that last thing it makes sense to do in this kind of context is build stuff that depends on a desktop stack. Furthermore, decoupling legacy from the desktop stack also has to be on the agenda, because you just can’t count on that stack being relevent in 10 years time.

Most ELN products on the market are tightly linked into the Windows ecosystem, even to the extent that one vendor just trumpeted the re-launch of their ELN which is now completely based on SharePoint!

My feeling is that organisations looking for an ELN which is going to last for more than 2 years should consider a situation where there are more than just Windows Desktop PCs in their IT infrastructure – not an unreasonable consideration, but one that needs thinking about up front rather than purchasing a product that locks you in to a dying ecosystem. The Windows PC isn’t going to be replaced but it won’t be the only way you’ll want to access your ELN, and whatever you select needs to be able to work with whatever you might adopt. That such lightweight “thin” solutions are easier to deploy than a thick client just icing on the cake.

(update: this story has been picked up in The Register)

The resulting lack of competition on top of vendor consolidation has led to Chemistry-focused ELNs tending to lag in terms of ease of use, and openness, whilst of course being pretty expensive. As those vendors seek to expand into other scientific disciplines, they bring with them the same costs which are then unnecessarily imposed onto other areas.

One major reason for this is that the Open Source Cheminformatics world has historically been under-developed. My theory is that’s because Cheminformatics started in earnest before Open Source took off as a concept (in comparison to Bioinformatics) but I have no real evidence for this.

Open Source is an important part of todays’ software ecosystem:

• It provides a set of building blocks, and I would imagine almost every software product (commercial or otherwise) has some Open Source components. By sharing the basic foundations, the cost of entry is reduced and this results in more entrants and lower costs for everyone.
• Open Source drives innovation by allowing people to re-mix things to “scratch their own itch” and produce new approaches as needed. Even if those solutions remain in-house they still inspire others, and perhaps allow the engineers inside the commercial vendors to successfully propose new approaches.
• The threat of “free” competition as well as more players in the market generally keeps vendors on their toes. Without a complete lock on particular functionality, vendors must instead compete on value and functionality.

Amphora are not in the Chemistry ELN market (and have no intention of being in that market), but I look at what’s out there and compare with what I see happening in other areas and it is clear there’s a lot that could be done which would benefit the wider ELN world as well. Frankly what’s going on Chemistry is giving the wider ELN community a bad name – especially as marketers keep positioning their products as the only “proper” approach for any kind of science, chemistry or otherwise. You really don’t need to spend thousands of dollars a seat and days/weeks of implementation time to deploy an ELN!

So I’ve waiting for a decent Open Source approach to Chemistry-based searching because if nothing else it will inject some innovation where it has been sorely lacking.

So I was delighted to read this post on how to Enable Exact Structure Search and Substructure Search for Your Chemical Database. I don’t think there’s a great breakthrough here, but it is a straightforward set of instructions on how you can do it which demystifies Cheminformatics a lot.

This could get pretty interesting in the next few years…

• HTML5 and other web technologies are surely at the stage where we don’t need a “thick client” deployed onto a desktop anymore – can’t we do it all in the browser?
• What about all the tablets (like the iPad), can we make them full clients?
• Can we finally have true cross platform chemistry ELNs?
• Can we easily embed chemistry into a variety of other applications, rather than having to buy a complete implementation of someone else’s idea of an ELN?

Amphora’s focus will remain on our particular slice of the ELN problem, which is providing the secure recordkeeping back end, discipline-neutral collaboration etc. Once you’ve done all that work the lawyers generally want to make sure you get the credit for all that Intellectual Property you’ve created even if they don’t explicitly apply for a Patent – even in Academic environments this is becoming more important as the journals and funding agencies raise their expectations in terms of record keeping etc. Amphora’s job is to help our customers focus on the science, and we’ll look after the Intellectual Property and Records considerations.

Even though we don’t plan to directly participate, I’m really looking forward to this. It is great fun working with our customers’ in-house Bioinformatics solutions, and I’d love to see that level of innovation in Cheminformatics.

Flexibility is the ability to change how software works; power is the ability to do more with less effort

Historically we have been sucked into believing that “Flexibility = Power” and the complexity of most ELNs shows the result. As Brent mentions, iOS and the like are causing us to understand that the benefits come from Power – that’s how we deliver the return on investment. Flexibility can distract from that.

I suspect in the future we’ll see a lot more focused, powerful systems which allow us to concentrate on the job in hand rather than having to figure out how to configure all the flexibility we thought we wanted.

When you add a new App to your iPad/iPhone you are generally up and running within seconds. Imagine if that was the user experience for ELNs…

Comparing a recent ruggedised tablet with an iPad shows why the iPad is so interesting for accessing an ELN from the benchtop.

The latest PC Pro magazine has a review of the Motion Computing J3500 which is a ruggedised PC with a touch screen which I guess would be one of the devices you might consider if you wanted a PC in the lab. At £2,253 (ex VAT) it isn’t cheap, battery life is just over 4 hours, and it is going to take a lot of bench space.

Compare that to an iPad which is £365 (ex VAT), a battery that will last most if not all of the day, much more portable, doesn’t take up nearly as much space on the benchtop and can be placed in a protective plastic bag if desired.

The difference in price, form factor and battery life is stark, and I suspect the iPad will be a lot cheaper to manage from an IT perspective. Given the move to web-based systems I can’t see there’s much the iPad is missing in terms of functionality either.

And that is why we’re excited about the iPad…. and it is too small to be used as a tray which is a concern with Tablet PCs!

In an article on 52 weeks of UX, exploring “The Distance Between Maker and User” the following principle is espoused:

As the distance between the maker and user increases, so does the difficulty of designing a great user experience.

This is our approach to usability – we make sure the Geeks are never too far away from the end user, and we achieve this in the following fairly simple ways:

• The people responsible for writing our products support them. We don’t have a support team – the guys helping our customers are the ones who you will speak to if you have a problem or need advice. This is probably the our effective way of increasing usability because not only do the developers get swift feedback on their decisions, they have an incentive to engineer out problems at source.
• We regularly review the kinds of issues we’re getting and see if we can make them go away entirely. Sometimes this is a re-worded screen, sometimes it is removing a step or component completely. I appreciate lots of vendors do this as part of a standard quality process, although we tend to do it in fairly tight feedback loops.
• We use the product internally. Did you know that PatentSafe makes an excellent financial records system? . Not only does that mean we have internal customers who deliver feedback every day, but the developers (and managers!) interact with our products daily. You’d be surprised how many little tweaks come out of this, things that customers probably notice but don’t think it is worth bothering us with.
• Our Sales, Development, Admin and Management teams are all co-located in the same office space, which means there’s lots of gentle interaction and sharing of context. It is interesting how often a problem in one area can be resolved in another. There are some problems with this because the different functions have different working styles (for example sales people switch context every 10 – 30 minutes, developers every few hours) but some simple informal rules make things easier.

Every time we bring someone new on board they are surprised that we aren’t more “formally” organised, but so far this setup has really helped us. It does mean we need to check that techies also have people skills, that our admin people need to be slightly more techie, and our sales people do need some involvement in the more geeky side of the shop. However it does seem to work very well for us, as demonstrated by the short training period that new users need to get up to speed with our ELN, and also the low volume of support calls we get (which apparently is very low compared to most software vendors).

Interestingly once new employees get over the initial shock of the proximity of roles, they really enjoy the richer environment it creates.

Having a small distance between the designers and developers is something that happened when we were a small startup, but I’ve come to view it as tremendously important for our ongoing success.

I’m intrigued how using an iPad causes me to think differently about user experience, and perhaps raise my expectations of what is a possible and indeed necessary.

I was reminded of this post on the ACM talking about “Why Features Don’t Matter Anymore” from 2006, where Andreas Pfeiffer talks about “the age of user experience”. He gives 10 rules about user experience:

1. More features isn’t better, it’s worse.
2. You can’t make things easier by adding to them.
3. Confusion is the ultimate deal-breaker.
4. Style matters.
5. Only features that provide a good user experience will be used.
6. Any feature that requires learning will only be adopted by a small fraction of users.
7. Unused features are not only useless, they can slow you down and diminish ease of use.
8. Users do not want to think about technology: what really counts is what it does for them.
9. Forget about the killer feature. Welcome to the age of the killer user-experience.
10. Less is difficult, that’s why less is more

We’ve just had one of our regular consultations with an Information Architect (IA) and even though we’ve attempted to keep PatentSafe as clean as possible, the results were enlightening. A fresh pair of eyes asking “Why are you bothering the user with that?” is always enlightening (and humbling!).

More features, especially when shoved in the user’s face, do not make for a better user experience. The user experience is one of the most important factors in the ability of any ELN project to deliver the return on investment it promised to stakeholders. That ability to deliver a return is a key aspect of any project’s success.

Interestingly we get two different reactions from customers when they look at our PatentSafe ELN.

• In the sales process we often get asked “Is that it?” in a rather disappointed tone when we’ve demonstrated the product – of course it isn’t but we don’t overwhelm people with features in the Demo – we talk about the things relevant to to their business problem. PatentSafe is designed such that you don’t have to wrap your head around everything to understand the positive impact PatentSafe can have on your life.
• Later when training, we get the same “Is that it?” but in a much happier way. Yes, with 15 minutes training and very little disruption to your existing workflow you can stop having to cut and stick, and move to a completely electronic world with all the benefits that brings.

One small anecdote might serve: We periodically survey our customers and one of the questions is “How long does it take to train your users”. One large pharma customer responded (slightly tongue in cheek I guess)

“45 minutes. 15 minutes to show them the system, and then another 30 minutes to convince them they already know everything they need to know”

Just because a product is powerful and can deliver a great ROI doesn’t mean it has to be complex. In fact, that’s the whole point of good design… I can’t claim we’re perfect but a good dose of Information Architecture really helps.

(most IAs work freelance – we are lucky to have worked with Karen Roles of Nidbe since we’ve started, and would highly recommend her to anyone. She delivers the sometimes painful medicine with a distinct charm… and you know it is doing you good)

This is a really important point – you can have innovation, but if you can’t figure out a way to present it in a way that people will adopt and pay for it, there’s no way you can ever take that innovation out of the lab.

We have plenty of ideas kicking around, but it isn’t just about the technology. One of the reasons our PatentSafe ELN has the form and features it does is that we seem to have the sweet spot in terms of something we can sell to people, they can install, deploy and ultimately pay for. I’ve seen so many fellow ELN vendors come up with cool products (often received by much enthusiasm by self-styled industry watchers) which fail the “Can people actually buy & deploy this thing” test. You see plenty of marketing buzz, a couple of pilot deployments, and then it all goes quiet.

Having a good product isn’t just about feature count, it is about creating something that your customers can buy, they can install, and live with. Turns out that writing software is the easy part, creating a product people can buy and use after the marketing hype has died down is a lot more interesting.

The future of our industry now looks totally different than the past. It looks like a sheet of paper, and it’s called the iPad. It’s not about typing or clicking; it’s about touching. It’s not about text, or even animation, it’s about video. It’s not about a local disk, or even a desktop, it’s about the cloud. It’s not about pulling information; it’s about push. It’s not about repurposing old software, it’s about writing everything from scratch (because you want to take advantage of the awesome potential of the new computers and the new cloud—and because you have to reach this pinnacle). Finally, the industry is fun again.

It’ll be interesting to see what the iPad and devices inspired by it do for the world of ELNs. Clearly Marc’s got a very cloud-centric perspective but the success of Salesforce.com (which he launched when Enterprise software was very much a 3-teir world client/server affair) does mean he’s worth listening to.

Human progress happens at 4% per year, averaged across many fields, ranging from 2% to 7%

How interesting! I wonder what the state of play is for ELNs…. I suspect we’d like to think it’s something like 10% or 20%, but I fear that if we took a good look at what’s really going on, it would be somewhat lower! One of the problems we currently face as an industry is there’s too much marketing spin in our communications and not enough real understanding of what’s going on.

I’d like to think at Amphora we’re on the realistic side – replacing the Paper Lab Notebook is a hard problem and we’re only going to get better if we pay attention to the whole problem and are clear-eyed about what’s really happening. Geeks at heart, we run a lot of stats about the performance of the business and customer experience and it produces really thought-provoking insights.

It isn’t just about the product, there’s lots more involved to the customer experience – from the sales process, pilot & training, commercial packaging, infrastructure requirements etc. all have a significant impact. Interestingly from a product perspective it is often more about what functions you leave out rather than making a complex mess, which does take a lot of discipline. For example we were recently eliminated from an RFP because we didn’t meet a “mandatory” requirement but we’d prefer to lose a deal than bend PatentSafe in weird ways which would lead to a more complex product which was harder for everyone to use. Purity of design is a good thing (yes, we’re Apple fans!).

• Business drivers
• Comparing the different sectors and disciplines
• Build or buy?
• An overview of the solution space
• Patterns of success

There’s a few concepts in here which deserve their own posts (presentations are so useful for stimulating the creative juices!) which hopefully I can do over the coming weeks.

Anyway, you have to give a 10 minute presentation talking about wider industry issues and I thought it was appropriate to draw people’s attention to what’s happening in the consumer space and how it might bring us towards the original vision of an ELN.

I’ll blog more on this tomorrow (after the Apple announcement today!) but for the moment here’s the presentation….

Having said that, whilst I believe we’ve done a really good job in PatentSafe replacing the corporate aspects (record keeping, long term records etc.) of the Lab Notebook, scientists still need a place to work. Sometimes that’s a discipline-centric product (sometimes badged as an “ELN”, sometimes something else), sometimes Microsoft Office and other general Knowledge Worker tools.

Looking forward I can’t help but think that tools like Google Wave and WordPress (especially with 2.9′s nifty features) are the long term future. A lot of vendors have “Web based” ELNs which are nothing more than their thick-client products wrapped in a browser – which I’ve always felt is cheating.

But when you look at what people are doing with web-native UIs these days…surely the next generation of Scientific collaboration products are going to come from the blogging or Web 2.0 space, with a little chemistry added to the mix. They’re cheaper, easier to use, easier to deploy, and often more powerful than a typical thick-client “Enterprise” app – and I suspect they’re more capable of dealing with large-scale use than any of the commercial products on offer at the moment (the lack of scalability being the dirty little secret of most ELN deployments right now).

All these tools need – apart from some open mindedness – is a decent record keeping system. Which we would be happy to help with

What an exciting time…

This discussion will start out with identifying the many forms of information we create and use, and the needs of those doing the creating and using. It would then move on to how best to share this information within our organization, and with our customers and partners in a secure manner. Our mental model will be the most well-known computer network – the Internet.

I really quite like this. I think The Internet has a lot to give in terms of sources of inspiration and it’s sad that the Lab Informatics market has been rather knocked off course by an obsession with a paper artefact rather than looking at what’s really going on.

I’ve always felt fortunate that we’re operating in one of the few “Green field” markets for IT systems. I thought my age would condemn me to working on incremental IT projects, as opposed to all the fun my predecessors must have had in the 80′s and 90′s going into manual processes and achieving quite amazing business impact by automating them.

Perhaps what’s happened is our generation have forgotten some of the basic system analysis skills that our Dads used?

Regardless of the cause, I strongly suspect if the Paper Lab Notebook didn’t exist we wouldn’t have come up with the concept of an Electronic one. Which does make you wonder how much more effective we could all be if we focused on the real problems scientists and their companies have?

I’ve become increasingly concerned that what’s said in public forums (e.g. articles, conferences etc.) isn’t a true reflection of what’s really going on. A lot of ELN systems are being introduced based on tools companies already have (Microsoft Office being typical), and those don’t get any publicity (no vendor to push it!), and of course you never hear about the problems, disasters, and near misses!

This systemic fault in how the industry communicates is really serious – and will result in an awful lot of money being wasted, and our credibility damaged – just because people think doing X is the safe way (for any given value of X), but in fact the case study they’ve seen was the only one where X has worked and there are 10 other people who tried X who have hit really serious problems (often fatal).

Given the nature of our business and product we see an awful lot of ELN projects across a wide variety of businesses, disciplines, and vendors. What we’re seeing in terms of best practice is at times completely contrary to what you’d think listening to conference talks, reading magazine articles etc. Of course, there’s no reason to suggest we’re right and everyone else is wrong, but on the other hand there’s a huge gap and that’s a worry.

So my presentation was an attempt to draw attention to this and propose some solutions:

• Be very careful about the use of the “ELN” word, as it’s too ambiguous. Ideally, stop using it entirely. It is especially useful to get vendors to describe their offerings without using the term “ELN” – then you find what their real focus is.
• Keep the ELN project as simple as possible. I mentioned some of the frameworks we use for this – The Triangle, Broad Vs Deep, etc.
• Blog – read blogs, and join in yourselves.

You can download a copy of the presentation here here. I had some interesting chats with people afterwards – I’ll try to expand on some of these points in future posts.

As an aside, I’ve nearly given up on SlideShare – the Keynote conversion process doesn’t seem to be working well.

Update: Rich Apodaca over on Depth-First makes some contributions here.

We didn’t know what the attendees were going to want to cover so I must confess the presentations don’t read as well as they hopefully came across. However, I hope they will provoke some thoughts all the same.

My overall proposition is that Biology is a very different beast from Chemistry and what works in Chemistry – the products, approaches to the projects, rollout strategies, etc. all need to be reviewed in the light of the special challenges of Biology environments.

There were two main presentations I used. The first looked at the ELN story from Chemistry from Biology and some of the differences between the two. You can download it here.

The second presentation looked at the Technology Adoption Lifecycle (TALC), which was first described by Geoffrey Moore in his book “Crossing the Chasm”. The TALC describes how people react to discontinuous/disruptive innovations and how you can help your innovation get adopted as easily and widely as possible. My contention is that Biology userbases are sufficiently complex that you should use Chasm-crossing techniques to both develop and deploy your ELN. You can read the presentation here.

Interestingly there were a number of people in the workshop who had successfully deployed an ELN into Biology and they had used Chasm-crossing techniques to do so – not because they’d heard of the concept (they hadn’t) but because it was the most sensible approach.

I’ve also uploaded the presentations to SlideShare, but the conversion process is taking some time. Once they are up the SlideShare versions should have the transitions and builds etc. which might make for a better reading experience. They should be on my SlideShare page in due course.

There’s lots of other stuff that came up in discussion, which I will try to cover in later blog posts. For example:

• What you see in conferences and publications in terms of case studies etc. isn’t representative of what’s really going on. There’s a lot of in-house development, a lot of use of Microsoft Office and other applications – but because there’s no vendor involved, they don’t get publicity because most publicity needs paying for, e.g. speaking slots, article placements etc. Sadly these are often the most successful deployments of ELN functionality – but it didn’t come from a vendor with “ELN” stamped on the box!
• I don’t believe you can have one ELN for Chemistry and Biology – or even for all of Biology.
• All of this is dependent on your definition of “Chemistry” and “Biology” – and this varies from company to company. In particular big Pharma seem to conduct a restricted set of activities on a very large scale (perhaps because all the really weird stuff is effectively outsourced to Biotechs) – which makes taking lessons from any company very difficult.
• Of course, sales and marketing efforts by various vendors do nothing to clarify this already muddled picture!

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