Designing Resources for Optimal Usage

Last week Clinical Key changed their interface and there was a big discussion about Clinical Key and how it works (or doesn’t) with Internet Explorer 8 & 9 on the Medlib-l listserv.  Basically the conversation fell into three categories.

  1. There was a general feeling that Elsevier did little to no testing of their website with hospital and other users.
    • Lack of functionality with IE 8 & 9 seem to indicate they didn’t test it very well using those browsers.
    • No A-Z alphabet listed for e-books and e-journals, so users have to wait for the entire list of e-books or e-journals to load and then scroll down to their title. Annoying, but not a big deal if your title begins with a C. But if you are J or another middle of the alphabet letter, it is worse than annoying.
    • Changing the way e-journals display a title.  In the past they displayed the title, current issue and then listed past issues on the page.  This is no longer the case and it makes finding the past issues very difficult. (update 10/2/14: ejournals now display current and past issues.)
  2. Most hospitals are stuck using Internet Explorer and often old versions of the software.
    • Many hospitals have legacy systems and are stuck on older operating systems which often dictate their browser software.  I know of one major hospital that has a goal of finally migrating to Windows 7 by Fall 2015.
    • If hospitals are a part of your clientele then it is a business imperative to know what the majority operating systems, browsers, and platforms your product will be used on.  Failure to do so means your product fails or is not used effectively. This leads to poor usage and will lead to non-renewal.
    • In general most hospital librarians CANNOT get their IT department to upgrade the hospital’s browsers.  At best they can get the computers in their library to have an upgraded or different browser, but they have no influence to have browsers upgraded elsewhere in the hospital.  It is naive to think otherwise.
  3. Academics have more flexibility and options regarding software and their IT departments are more open to other resources.
    • As a result they are often good places to try new things and experiment. However if the product will be offered to hospitals, vendors must be aware that what works at an academic institution may not work at a hospital.
    • While academic institution are concerned about privacy, in general they do not have to deal with HIPPA regulations.  This adds a layer of complexity to security that must be married to multiple hospital systems.

While the medlib-l discussion on Clinical Key could be boiled down into one of these three themes, it does impact more than just Clinical Key.  They are just the most recent example, but others have failed to understand the market they sell to.

Before a vendor decides to upgrade, they would do well to have beta testers from both hospitals and academic institutions (large and small) and make sure the company or programmers they are using to upgrade their product know design to the lowest common browser.  That won’t make things perfect, but it will help.

 

3 thoughts on “Designing Resources for Optimal Usage”

  1. That would assume their market is mobile devices. There is a large majority of doctors using the hospital computers in addition to their mobile devices. To ignore computers inside the hospital as access points eliminates a vast majority of users as well as brings the usage stats down. Less usage greater chance their product is cut.

  2. I think they are less worried about how it works on hospital computer systems and more focused on making it work on mobile devices. So I think they do understand their market.

Comments are closed.