Jul 31

Adding your Library to Book Burro

Update: Jesse just started a blog at his Book Burro site.

Jesse Andrews, creator of Book Burro, was kind enough to answer a question of mine via email about his super-cool Firefox extension, and gave his kind permission to post it here.

I had asked Jesse for instructions on adding a library’s catalogue to Book Burro. Jesse replied that he’s working on a way to make adding libraries easier, that he’s just released a version that works with WorldCat, and added the following for the more geeky do-it-yerselfers amongst us:

…there is a small amount of code for each library that needs
added (as an example:

{ name: ‘us.cmh_public’,
title: ‘Columbus Public Library’,
link: function( isbn ) { return
+ isbn; },
process: function( req ) {
var status = ‘yes’;
var results = req.responseText.match( /0 publications match
your ISBN search for/ )
if (results) status = ”;
return status;


Jesse rocks. Book Burro is one of the neatest Firefox extensions yet created. If you like to buy books and haven’t tried it, you’re wasting time, money or both.

Jul 29

A Masterlist of MedLib Blogs

Update: At the suggestion of some talented folks (see the comments on this post), we have copied all of this blog information to the LISwiki. Please make your changes and updates there instead. It is advertisement free, and a more central location that allows better sharing with libraryfolk of other sorts. New Location: http://liswiki.org/wiki/Medlib_Blogs

Update: Thanks so much to those of you who have added to this Wiki of MedLib blogs! When the list seems to stop growing, I’ll create and post an OPML file containing all the feeds for these blogs, so we can all easily subscribe and follow each other’s blogs.

What’re you on about, David?
I’d really like to put together a complete list of all Medical Librarianship blogs. I mean…wouldn’t you like to have a list like that, too?

How are you defining a “Medical Librarianship blog”?

  1. A blog specifically about Medical (/ Health/ Health Sciences/ BioMed) Librarianship,
  2. A blog written by (a) Medical Librarian(s),
  3. A blog maintained by a Medical Library, or
  4. A blog maintained by professional association of medical librarians and/or medical library paraprofessionals.

So David Rothman is going to put the list together?

I’m willing, but I’d rather prove to the rest of the biblioblogosphere that people in medical librarianship can get as Library 2.0 as any other libraryfolk. I propose an easy-to-edit site where we can collaboratively create a good and thorough list. A wiki. Besides, this could be a really fun and gentle introduction to wikis for MedLibs who are new to them.

Wouldn’t this be redundant? Isn’t Dean Giustini going to do a Health Sciences Librarianship Wiki at UBC?

He’s going to, but it is months away right now. When UBC’s Health Sciences Librarianship Wiki is created, we can fold this into it, but in the meanwhile I’d really like to be certain I’m subscribed to every other MedLib blog there is- and I’m guessing that a lot of people who read this blog would like that, too.

Where’s this Wiki?

Here: http://medicallibrarianshipblogs.pbwiki.com/List%20of%20Blogs

How do I add a blog to it?

I added my blog (the one you’re reading) and a couple others as examples, but here are some specific instructions to get you started:

  • Click on Edit page button

  1. Enter the password: medlib
  2. Enter your name (or pseudonym, if you prefer)
  3. Enter your email address
  4. Click the Log In! button

  • Click the Edit page button again
  • Click the Preview button
  • Now you can see both the source for editing (below) AND how it displays (above)! To make rows of the grid we’ve started, just make sure that each column element is preceeded and followed by the ‘|’ character as it is the first few rows.

What if I have questions about how to use the Wiki?

Let me know! Or you can use PBwiki’s really decent help information and/or forums.

Anything else I can do?

Do you have a Medical Librarianship blog? Point people at this post or copy and paste it into your own blog and spread the word. Don’t have a blog? Email your friends and colleagues who work in Medical Librarianship and ask them to contribute or suggest blogs to you.

Jul 28

How to: Create a PubMed RSS Feed for 30 Journals

Marilyn, a Medical Reference Librarian in New York State, writes to ask how she can set up a single RSS feed to cover 30 different journals for one patron in PubMed.

I thought this topic had been covered, but I can see in the archives that I missed a good chance to touch on this earlier.  My apologies to Marilyn.  When you get to PubMed…

  1. Click on the Limits tab.
  2. Click the Add Journal button and enter in the Journal you want included in your RSS feed
  3. Click Add Another Journal
  4. Enter another Journal name
  5. Click Add Another Journal
  6. Repeat steps four and five another 28 times


Then follow the instructions on generating a feed that were detailed in this previous post.

I did try it out, Marilyn.  PubMed will allow one to add at least 30 journals. 

I say "at least" because I…um…stopped after 30 because I felt silly.

Happy Friday, folks!

Jul 27

How to: Limit PubMed Feed to Articles Not Ahead of Print

We've covered how to create a custom feed from PubMed, but Medical Librarian Linda Schwartz writes:

…the present system we are trialing sends out the TOCs before we actually have access to the fulltext because some journals are only available in print or embargoed electronically and take a while to before we can actually provide the full text to the requester. Right now, there is no way to keep the TOCs for journals that come in slowly from being pushed if the TOC is published first. We'd rather wait until we have the print/access in our hands before sending out TOCs so requesters would get their requests in a timely fashion (via Linkout if available and we won't have to keep a file of requests waiting until the print shows up).  Of course, we'd like to do this without having to filter all the TOCs through a staff member before routing to the users. Do you see a way that RSS would solve this problem?  [David's emphasis added]

In pursuit of an answer to Linda's question, I did something that was (if I may be permitted to toot my own horn on my own blog), extremely clever:  I asked the NLM.

NLM answers:

You can search "NOT pubstatusaheadofprint."

Have I mentioned recently that I love the NLM?

I tested this out and it seems to work well.

Please note this additional cautionary note from the NLM, though:

…we don't recommend this as you will be excluding the very latest additions to the database.  We have found that links to online full-text of a large majority of ahead of print articles are usually available in PubMed within 48 hours.For example, as of this writing, there are 52,954 ahead of print items in PubMed.  Of these, 52,871 have links to online full text.

 So, it isn't for everyone or all circumstances, but this might work very well for Linda.  Or maybe you. 

Jul 26

Federated Search: long story & short morals

Dang Woody Evans.  Dang him to heck.  This post is all his fault.

Here's the whole content of a recent post of his at ISHUSH:

"Convince me, someone, that all federated searching does not suck."

I argued:

Doesn't any particular application of Federated Search suck or not suck depending quite a lot on (among other factors) the needs of the searcher, what resources are searched, and how well the metasearch engine is designed and built?

It seems to me that a blanket "Your favorite technology here sucks" is just too broad to be true. 

(I also made the argument that Book Burro is federated search and is great.  I notice Woody didn't contest that- probably because Book Burro is awesome.)

Woody elaborated on his complaint very succinctly:

The main problem, as I understand it, is that the f.s. uses vocabulary that isn't (and can't be) universal. So you end up with missed articles because the search term subject headings are not in a universally controlled vocabulary.

Woody and I are clearly not disagreeing.  Where I think we differ is that I'm far from ready to give up on federated search as an idea.  What follows is a long explanation why. 

I used to work for a company that managed HR and benefits data for very large clients. One of our clients, for instance, was one of two very large soft drink companies, and its name rhymed with… "Schmepsi."

Now, imagine you run this company, and you have employees across all 50 states, and you want to give them all comparable employment benefits. Here are your problems:

  • Your offices throughout the country use all sorts of different HR systems (PeopleSoft, SAP, a piece-of-poop MS Access database, you name it). 
  • There isn't a single Health Insurance carrier (or vision, or dental, or flex, etc.) that covers all the markets where you have offices and facilities.  In fact, you can't even limit it to just a few, you actually need to work with dozens of different carriers in pretty much every market in the U.S..  All your carriers need different elements of the data, and each has its own proprietary format for data interchange.
  • While you're at it, you have to track national trends and expenditures, and manage disbursement of payments to carriers.

So you've already got data from a significant number of different sorts databases chunking out HR data in wildly different export formats using completely different data definitions, and you have to get just the rights parts of this data in just the right format to all the right carriers at the right time.  Nightmare, right?

That's where the company I worked for came in.  We checked out their systems and their data exports, learned their business needs and data definitions, then designed and built automated custom import processes to get their data from all their various HR systems into OUR database, using OUR data model.

We also got to know their vendors, the vendor's business needs, and the vendors' systems.  Then we designed and built custom exports that got JUST the data each vendor needed in EXACTLY the format that worked for the vendor's systems.  When this was done well, the results were a wonder to behold.  Automated, centralized, electronic data exchange with impressive accuracy.

Near the end of my time working for this data management company, certain HIPAA rules came into effect that mandated a number of our feeds (in and/or out) use a particular standard for EDI called the 834 ASC X12N 834 (004010X095).  We affectionately called it "the eight-thirty-four."

(It was while working for this data management company that I learned to think of myself as a data-monkey, and started to learn SQL from some really great programmers.)

In a number of ways, the advent and growth of this EDI standard made the job easier and faster, and it was hoped at the time I left that industry that this increasing move towards standardization would make data interchange easier and less expensive.

What does this have to do with federated search?  Everything.  What's to stop a good, well-designed, federated search tool from importing indices from multiple databases (per custom designed and built import processes built specifically with the data definition translation needs in mind), and searching the combined indices by the data definitions they now share?  Can we not hope that standards of data definition will be be encouraged (/demanded) and eventually implemented to one degree or another by database vendors?

First moral: I'm not saying it is easy.  I'm saying it is do-able.  I'm nowhere near ready to give up on this relatively young idea.

Woody also wrote:

Federated searching in most cases turns out to be sorta like searching Picasa, Flickr, CC, and Wikimedia Commons all at once for a folksonomic tag term and calling the results thorough.

This is a completely fair point.  After all, the data I helped manage at my former job WAS all the same kind of data: HR data.  This leads us to the second moral: Some databases shouldn't and can't be effectively searched in a federated model because their data types are not similar enough or because they have virtually no structure.

Third moral: The result set from any one query cannot be called thorough, even it is performed in a single database.  If I searched for "library" at Flickr, that wouldn't get me all possible library-related images.  Human judgement would also demand that I search for "libraries", "librarian", and a number of other related words and phrases.

However, using Flickr as an example seems a little of an unfair analogy.  Sure, some databases don't define their data well enough, but none are as chaotic as the folksonomies online.  (That'll be the topic of a future post.)

Thank you, Woody, for the discussion.  I HAD written the above as a comment on your blog, but I thought it would be obnoxious to leave a comment of this size. 

Please feel free, of course, to tell me I'm all wrong on all of this.  I'm wrong a lot, after all.

And, folks: Check out ISHUSH.  Woody says stuff that makes me go "hmmmm."

Jul 26

Health Sciences Librarianship Wiki

Dean Giustini announces the anticipated Health Sciences Librarianship Wiki that his LIBR 534 students will start.

Here's hoping it is a bit like The Library Success Wiki.

This is great news and potentially a really useful resource to a lot of people in the profession.

I hope very much, though, that Dean allows it to be editable by even non UBC libraryfolk.  If outsiders will be allowed to contribute, Dean should count on my regular visits.

And I was JUST TODAY talking to someone about the need for a Wiki dedicated medical librarianship.  As usual, Dean is a few (or perhaps many) steps ahead of me.

Jul 25

Freemind: MindMapping Freeware

I'm not so impressed with Gliffy, but I am delighted with this piece of freeware.

Here's the sort of thing it lets you build (Click around with it a bit to see how it can expand and contract)

The interface is intuitive and sensible. Just to try it out, I started mapping out my job responsibilities, and discovered that the way the program works really helped me flesh out what I do and what I WANT to do.

I found this hugely useful and helpful in organizing my thoughts, and can imagine using it as a tool to help communicate my ideas to others. Also interested in making use of it as a navigation tool…but need to think about that further.One last bonus: it runs off a USB thumbdrive.

Jul 25

NEXGENLIB Wiki Coolness

So there was some abusive behavior going on at the NEXGENLIB-L ListServ, and the former moderators seemed to have abandoned the list, so a number of its members started a new one in Google Groups in hopes that with restrained moderators actually being present, the community (made up overwhemingly of pleasant and helpful young libraryfolk) could continue in a helpful manner.  Within a few hours, about 40 members had migrated over and started building up their new community.

That's not even the coolest part.

The coolest part is that the community started discussing if they should have a website and what the website should do.

Said one member: "we could use it to store useful information, links, advice and other things new librarians might find useful. In creating a site together, we would have a collaborative effort that could add to overall group cohesion."

Said another member: "How about a Wiki, then?"

BAM!  The NEXGENLIB Wiki was born and is actually developing pretty quickly for being a few hours old.

Neat, huh?

Jul 24

Scopus RSS: a very brief review

As has previously been posted, Damien Sherman of Elsevier’s Scopus took exception when I suggested (at Michael Stephen’s Tame the Web) that Elsevier was behind on RSS because the product he works on, Scopus, does.  Excited to see this, I asked if I could see Scopus' RSS features and feature them on my blog.

At my request, Damien promptly set up temporary access to Scopus so I could check out and review its RSS features here. It is appropriate to again thank Damien for this. This sort of open communication between vendors and libraryfolk serves the interests of both, and his willingness to do this will always positively color my perception of the Scopus team at Elsevier.  Marketing, PR, and Sales: Please take note of this.

What follows is a very brief review only of Scopus’ RSS features.

After going to Scopus and painlessly logging in and setting up my account with the credentials Damien provided, I got straight to searching. As soon as I entered my search terms and clicked the ‘Search’ button…


…I was presented with the query used and the familiar orange RSS button.


I clicked on the RSS button to be brought to a screen where I can name my feed:


When I clicked the Continue button, I got my very long URL for the feed (cut off here both for display purposes and to obscure the actual URL).


Next, I subscribed to this feed in BlogLines to see how the results would look:



Things I like about Scopus RSS

  • The RSS feature is well-integrated in the search results page, and easy to find.
  • Naming of feeds makes them clear and unambiguous when they appear in the aggregator.
  • The RSS URL is created quickly and easily.

Things I’d like to see Scopus RSS do next

  • The RSS items should contain, if not the full abstract, at least a few lines of it. Now, all that shows up in the aggregator is the hyperlinked title and a one-line description of the source. More detail in the item would allow the user to do some filtering without having to go to Scopus. This would save the user’s time (Ranganathan's 4th law, anyone?).
  • The RSS feed contains ONLY the Scopus results, not the web results. Ideally, the user should have the option of whether to do one of the two, or both.
  • RSS feed URL produced should be a live hyperlink, not just text. This lets users with many kinds of subscription tools subscribe more easily.
  • More user documentation about how Scopus RSS feeds will work is needed. It isn’t clear, for instance, how often the search that generates the feed will be executed. Perhaps the user could select from a menu how often he/she would like the search to be executed and new results generated for the feed.
  • Change the RSS button to the proposed standard.

Summary: Scopus is off to a good start with their offering search results as RSS feeds and should be applauded for having them. However, from the perspective of someone working towards SDI goals, its RSS features are not yet caught up to PubMed in usefulness.

This was the first time I’ve tried Scopus. Perhaps a reader who is more familiar with its use might like to comment further on either its RSS features or other feature that especially stand out? 

Jul 24

Up-to-the-minute medicine

via Kevin MD, a decent article from The St. Louis Dispatch on evidence based medicine, medical literature, and the information technology to bring it all into the examination room to benefit doctor and patient.

When Dr. Charles Willey walks into treatment rooms, his laptop computer is as prominent as his stethoscope. After his examination and his diagnosis, he types information into the laptop. If the patient wants to watch, that’s OK.

The computer screen kicks back a list of the latest studies and information about the diagnosis he’s made – treatments, changes in treatments and the list of medicines that are available to treat the condition.

After he and the patient agree on treatments and medicines, he can hit a button to print out prescriptions or fax the information to a pharmacy.

I get happy-geeky goosebumps at stuff like this. If they’re easy to use, time-saving, and if they enhance the quality of patient care, clinicians will use EBM information tools.

Jul 23

Making RSS as “pushy” as email

After a very busy and stressful few days, I’m ready to try to get a start on the list of post topics that have stacked up in my inbox. First is to attempt to explain the difference between Push technologies and Pull technologies and to make some suggestions on how RSS can be made to be perceived by users as a push technology as convenient as email.

Geekier purists, please note: We’re talking about PERCEIVED Push vs. PERCEIVED Pull. I’d argue that this isn’t the same thing as comparing a true push to a true pull, but that’s an argument for another day.

Web Browsing: An example of a perceived Pull Technology
The best and most common example of a pull technology is your web browser. When you type http://www.davidrothman.net into your browser’s address bar, your browser contacts the server that HOSTS my blog and asks it (preferably in a refined English accent): “Excuse me please, web server. I’d very much like to see what’s available at davidrothman.net. Could you please deliver to me the default HTML file of davidrothman.net?”

The server replies (also in the Queen’s English): “Why of course, my dear browser- please do render this HTML file for your user!”

And the web server sends the file to your browser, which your browser interprets and renders for your viewing.

What makes this a perceived pull technology? You have to direct your browser to the web page so your browser can request (or PULL) the appropriate HTML file from the server to display for you.

Email: An example of a perceived Push technology
PC Magazine’s encyclopedia defines a Push technology as “[a] data distribution technology in which selected data is automatically delivered into the user’s computer at prescribed intervals or based on some event that occurs…”

Your email is probably a good example of this. If you use a version of Microsoft Outlook at home or at work, your Outlook client (the program what is installed on your computer) checks in the email server at regular intervals (perhaps every 5 minutes or so) to see if there are new emails. If it finds there are new emails on the server for you, it downloads them to your computer for you to view.

Viva la difference!
Note that the only difference in our examples between the perceived push and the perceived pull is that the email client automatically checks for new emails at regular intervals. So when the user starts up Outlook, it automatically checks the server to see if there are new emails. If the user leaves Outlook running all day, the user will see any new emails that are received by his/her email server within 5 minutes of their arrival without the user having to tell Outlook to go check the server for new email. The web browser is seen as a perceived PULL technology because it doesn’t automatically refresh the page from the server at regular intervals (unless, of course, the web site is designed to force a refresh at regular intervals- that is done sometimes).

Is RSS a Push or a Pull?
Let’s now look at the issue raised by a member of the MEDLIB-L ListServ about RSS a few days ago:

I see RSS as a pull technology and emails as a push tech. By that, I mean, that the user has to actively seek out their RSS aggregator and read whatever it contains. Emailed TOCs, however, are pushed to their email box and they don’t have to actively seek out another program to get info. I suspect that expecting busy HC professionals to seek out anything else (such as an RSS aggregator) will decrease current awareness usage.

This is, obviously, a really valid concern. The fact of the matter is that RSS is clearly a Push technology. Why? Because once one subscribes to the feed, the aggregator checks the feed at regular intervals to see if there is new information, and automatically displays it for the user.

RSS is as much a push technology in this manner as an email client. If you keep wither client open all day, you’ll know quickly if there is a new email/post.

The real concern shown by the librarian poster to MEDLIB-L here is that her users already keep their email clients open all day, and she doesn’t want them to have to keep another client open all day for RSS feeds. That’s a totally reasonable concern. Some users might see the need to visit a web-based aggregator as an additional step to their (already hectic) day.

How to make the push of RSS more conveniently “pushy” for the user
Here are some of the ways the user can be actively notified when there are new results from their subscribed feeds without having to visit the URL of a web-based browser OR having to install a “fat client” RSS aggregator:

  • If the user chooses BlogLines as her aggregator, she can install one of the many notifer tools offered by BlogLines that can, for instance, live in her Windows Taskbar and beep her when she has new information ready to be viewed via her subscribed feeds.
  • There are multiple aggregators available that are plug-ins for Microsoft Outlook. If your user already uses Outlook, she may be interested in one of the following plug-ins to allow her to read RSS feeds in Outlook, too:
    RSS Popper (Free)
    Attensa for Outlook ($20)
    BlogBot for Outlook (Free)
    inclue! (Free)
    IntraVnews (Free)
  • Please note that I have not tried these plugins myself, and cannot vouch for their quality or function. This isn’t a complete list, either; these are just the first five that I found in five minutes of searching. If any readers have used and liked an RSS plug-in for Outlook, please make a note of it in the comments for this post?

    While we’re fishing for opinions among readers, are there other options you’re aware of that would help users experience RSS feeds as more of a perceived push?

Jul 21

RSS Discussion (or lack thereof?) on MedLib-L (Take II)

Update: 7/21/2006 – Rrrrg. Been having some sort of feed/aggregator issue that I think may have prevented this going out to a number of subscribers via RSS when first posted. Posting it again in hopes that this will resolve the problem. Please forgive the duplicate if you received it the first time. Originally posted 7/20/2006

I was excited to notice this morning that someone had posted some general RSS questions to the folks in medical librarianship who subscribe to the MEDLIB-L listserv. I wondered at first if it was okay to post these online, then realized they’re ALREADY posted online and are universally accessible, so there seems to be no ethical problem in reposting them here.

From the original excellent post, full of good questions:

“…I’m looking for some input on the whole concept of current awareness by RSS versus TOC emails.

I see RSS as a pull technology and emails as a push tech. By that, I mean, that the user has to actively seek out their RSS aggregator and read whatever it contains. Emailed TOCs, however, are pushed to their email box and they don’t have to actively seek out another program to get info. I suspect that expecting busy HC professionals to seek out anything else (such as an RSS aggregator) will decrease current awareness usage.

I can see the advantages of RSS for SDI in which the user has an ongoing interest — and therefore motivation — to seek out that extra program with info tailored to their interest. I find it less compelling for the more serendipitous method of scanning TOCs.

Am I missing something here? Has anyone tried both methods for current awareness and one way clearly won out over the other? If so, I’d like to hear from you….”

I was very disappointed, though, to read this response:

“I personally have never seen the point of RSS when we have toc’s. Looks a lot like a wonderful solution for a problem which does not exist. (some thing like my husbands ongoing need to buy power tools for the furniture he will build me someday when he has a work shop and time)”

I’d like to share both what I posted to the ListServ, and a couple of additional notes. First, here’s how I replied on the ListServ (with corrections for spelling and grammar, and one edit for clarity [in brackets like this]. You can read the original here if you prefer):

I don’t believe in irrational technology evangelism. I think we should use what works for our environment and users, not champion digital solutions as one-size-fits-all cornucopias.

That being said, I think that both emailed TOCs and RSS are great, but that they have different strengths and uses.

If you don’t mind trying to manage an already overstuffed email inbox, TOCs are great for general awareness and serendipitous discovery of “information you didn’t know you wanted.” (Thanks, L, for that phrase) But when a clinician has a very specific SDI need, RSS can be amazingly helpful.

Say a gastroenterologist at my hospital wants to know any time “Probiotics” and “Ulcerative Colitis” both appear in a specific set of journals he/she cares about. I can set up a custom feed at PubMed for this clinician that will ONLY send him search results that meet his/her specific criteria as soon as they are indexed by the NLM.

Also, RSS feeds can be set up to create email subscription forms or can be easily re-parsed into a web page for medical libraries that want to have Up-To-The-Minute medical news pages on their intranets for clinicians to make use of. RSS also allows data about medical literature to be re-parsed for other purposes, (like those being developed at medworm.com).

Another reason why I prefer RSS to email is that email is used for an extraordinary variety of purposes: Hospital communications, family correspondence, SPAM, vendor solicitations…you name it. Adding a fresh new email for each TOC can make managing an inbox (often already a difficult task) even more extremely difficult. An RSS aggregator can be dedicated exclusively to current awareness/SDI needs. A good, easy-to-use web-based aggregator (like BlogLines) can let the user easily and automatically separate new information by subject, source, or search parameters. I get somewhere between 50 and 300 emails daily and find that hard to manage sometimes.

I have about 150 RSS feeds (yep- mostly about librarianship and technology) in my aggregator and NEVER have problems managing those because items I’m not interested in are so easily discarded.

But the shortest answer is that use of RSS and aggregators is growing, and we should be prepared to help deliver medical information to our users [by this method and using this technology] when they inevitably ask for it.

If anyone has specific questions about RSS, I would be pleased to receive them. If and when I cannot answer them, I can definitely point out good resources for further reading.


David Rothman
Community General Hospital of Greater Syracuse

Just to add a few additional notes:

  • I have received great emails with good ideas and clear questions from a few other MebLib subscribers, and their questions/concerns will be used to create some new posts next week on accomplishing particular tasks. Thank you to those who sent these my way!
  • Another topic for a future post will be explaining the difference between “pull” and “push” technologies, and how to help make RSS feeds a “push” from the perspective of the user.
  • Contrary to the comment above from the MedLib subscriber who dislikes her husband’s taste for power tools, RSS isn’t a solution for a problem that does not exist.

    It is a tool we can use (at very low cost of time, effort or money) to enhance the services we offer to our users. Ranganathan said a library is a growing thing, and it frustrates me to hear anyone in librarianship dismiss this potential for enhanced services because she sees nothing wrong with the status quo.

  • I have an acquaintance who is fond of saying that one should “never let best get in the way of good enough“.

    It is a fair point, but I might counter with “never let good enough get in the way of better.” My view is that if we are satisfied with mediocrity, we will never do anything excellent.

    I believe that if we fail to innovate, if we fail to continually refine, enhance, and improve our services, we are failing both our users and our profession.

Jul 19

GuruLib Creators Solicit Feedback: David Obliges (to the Chagrin of All)

(updated 7/20/2006: see bolded text at bottom of post) 

The problem with asking for my opinion is that you'll always get it.  Anyway:

The co-creator of GuruLib, Rana Basheer, left a comment in response to my post about GuruLib in which he solicited further comments about GuruLib.  How extremely cool is that?

Mr. Basheer, these are just off the top of my head.

Problems I see with GuruLib:

  • It isn't at all clear how to use the "Borrowed Items" function.  This may just be a problem of missing documentation, but if the interface doesn't reveal by playing with it how it is to be used, it needs further development.
  • One should be able to click an item on the shelf and mark it to be borrowed.  Marking it as to be borrowed should bring the user to a screen where the user can enter in the details of the borrower's name, phone number, and expected return date.
  • It makes sense to have some ads, but having both the amazon.com ads AND the google adsense is sort of intrusive. Suggest that GuruLib use banner ads and/or context ads, but not both.  Also, the roll-over pop-up ads are unpleasant.  If they offered something more than just commerce, perhaps they'd be less so.

Features I'd love to see developed to expand GuruLib's usefulness:

  • Borrow a good idea from Librarything and make the site more social by allowing users to find other users with the same particular item, or to find other users with multiple shared items.
  • Add RSS feeds.  I have friends with great taste in books, films, and music.  I'd love for them to be able to provide a feed (that they can shoose to share publically, or to share only by invitation to particular friends) to let me know when something new has been added to their shelf (or shelves), and also see any tags, notes, or reviews thay may have added to the item.
  • How about being able to look up a movie from the shelf at IMDB with a single click.
  • I'd love to have a Firefox Greasemonkey user script (or full extension) that lets me click from IMDB, Netflix, or Amazon to add to my shelf at GuruLib.  Such scripts exist to link IMDB with NetFlix, so this should be not too difficult.
  • How about the ability to click on an item on someone else's shelf to automatically add the item to one's own shelf, one's Amazon wishlist or one's NetFlix queue?
  • How about a button (or context menu) for my browser that lets me "add this to my GuruLib shelf" from an item page at Amazon, Barnes and Noble, NetFlix, etc.?

Kudos to Mr. Basheer and his spouse, by the way, for developing a nifty new tool on their own.  I like stories of independent developers building neat stuff without corporate support.  Here's hoping it continues to evolve and improve!

Anyone else have thoughts or insights we can share with the creators of GuruLib?

Update, 7/20/2006: I have received a very nice email from the Basheers:

Thank you David Rothman for the patience. I agree with you that borrow item option is outrignt confusing. I will try to provide an option for the owner to set a book as borrowed as you suggested. My current implementation is the reverse way. That is, If a person wants a book from his friend he clicks on the borrow item link in his friends library to send a request to his friend to borrow the book. The friend will receive an email and he will then set the number of days the person can borrow his item.
I understand that is unnecessarily complicated. I will try to make it simpler. I really appreciate your suggestions for improvement. I will get to it one by one.
Thanks and Regards
Rana Basheer
Jul 19

Notes on Scopus RSS features forthcoming

Damien was good as his word, and has quickly arranged for me access to Scopus so I can review its RSS features. Expect notes on them here within the next week or so.

For the record, I really respect Damien’s visiting and participating in library blogversations (Damien’s word, and I like it) and really appreciate his arranging for my access. This sort of open dialogue between vendors and libraryfolk can only serve to benefit the community as a whole.

Jul 19

How To: Create an RSS Feed for a Feedless Journal with PubMed

A few emails have indicated that some specific clarification on how to create an RSS feed in PubMed for a medical journal that does not offer its own feed would be helpful. Here goes:

We’ll start by paying a visit to our much-beloved PubMed, and clicking on the Limits tab.

Click on Add Journal

Type in the name (or partial name and click to select the name) of the journal you need a feed for. For our example, we’ll use American Heart Journal, which, as has previously been noted, Elsevier does not provide an RSS feed for.

Scroll down to the bottom of the page and click Go

We’re back to the main search page of PubMed now, and we can see that this GUI has formulated a search string.

(Don’t worry about the fact that there are 19,635 results of this search- we’ll limit the number you’ll get via RSS in the feed options.)

Next, go to the Send To drop-down menu and select RSS Feed

On the next screen, choose to Limit items if more than 50. Why 50? Because the July issue had 40 indexed items. Also, give the feed a sensible name, like American Heart Journal, and click the Create Feed button.

All that’s left to do is collect the URL of the feed. You can do this by clicking on the orange XML button and copying the URL from the new tab or window that appears, or you can right-click on the orange XML button and click Copy Link Location (or subscribe to it in the manner prescribed by your aggregator, browser plug-in(s), yadda-yadda-yadda).

That’s it. You now have a feed for the journal. I tested last week to see how much time elapsed between publish date of an issue and the journal’s articles being indexed and searchable via PubMed. It took about a business day.

Questions? Let me know. 🙂

Jul 18


So, I loved Librarything from the first moment I heard about it, but was bothered that it only covered books.

Just tried out GuruLib today. Still in Beta and a little cludgy, it seems a bit like a Librarything that can include DVDs and music

Still thinking about the neat things that could be done with this if they continue to improve the interface.  Worth checking out. 

Also interesting: Is it just me, or is the login area clearly modelled after Google login boxes?