Soon after the launching of Hardin MD, in 1996, we began adding keywords in the hidden META keyword field (The first pages for HMD in Internet Archive [Dec, 1998] show them on all pages checked.) We began checking to see if HMD pages were appearing in search engine results in about 2000, and found that meta keywords didn’t seem to have much effect.

So, in late 2000, we began experimenting with putting keywords (aka tags*) at the bottom of the page, where most users wouldn’t notice them. At first we didn’t see much effect in search engine results, when using the tags mostly for variant spellings or terminology (e.g. on the Hematology page: blood diseases, haematology).

In 2001, as Google rose to prominence, and Search improved, we began using tools that gave the ability to see the popularity of specific words (HitBox, ExtremeTracking, WordTracker). We learned that using mis-spelled word variants as tags worked very well in drawing SE traffic. It was also during this time that links to pictures were being added to HMD, and we discovered the power of the word “pictures” in drawing SE traffic.

Time-line of tagging in Hardin MD

Based on invaluable help from Internet Archive — Starting from here: Internet Archive for Hardin MD, 1999+

The first HMD pages in Internet Archive in Dec, 1998 have meta keywords, but not tags on the page. Example of meta keywords (Hardin MD: Cardiology): health, medicine, medical, nursing, nurses, nurse, disease, diseases, best, list, lists, consumer, cardiology, cardiac, heart, stroke, cardiovascular, cardiothoracic, pacemaker, defibrillator, attack, arrest

Tagging for misspellings – Ophthalmology, I’m sure, would have been one of the first pages on which misspellings would have been used. Internet Archive pages show clearly that the first implementation was in early November, 2000. …

Ophthalmology, Nov 7, 2000 – No misspellings in meta keywords. There are no tags on page.
Ophthalmology, Nov 15, 2000 – Has misspellings in meta keywords and on page: [ophthamology]

This fits my memory of events — I was especially motivated to look for ways to draw Web traffic, because Google was just becoming prominent, rationalizing the search process, and making it easier to predict the effects of changes on page traffic.

Other examples of pages with tags on the page, with variant spellings, from about the same time: Orthopedics Nov 16, 2000 [orthopaedics] and Hematology Nov 29, 2000 [blood diseases, haematology]

Use of the word “pictures,” in tagging and in page titles

First use: Genital Warts Jun 10, 2002

First widespread use – Several pages linked on Hardin MD Index page Sept 30, 2002

.

Eric Rumsey is at: eric-rumsey AttSign uiowa dott edu and on Twitter @ericrumsey

All Hardin MD (HMD) pages have tags at the bottom, to make them more visible for search engines i.e. Google. We have been doing tagging in HMD since 2000, and it works very well. As shown in the example to the left, the tags are for variant spellings (measels), variant terms (rubeola), and words and word combinations relating to pictures (we have found that the word “pictures” is especially favored by Google).

One of the things that has made HMD fun has been applying longstanding practices of librarianship to a web-based system. Having been a cataloger for a brief time early in my library career, it seemed natural to put tags at the bottom of the web page, just like subject headings are at the bottom of cards in the card catalog. Including mis-spellings in the tags to help users find the page seemed natural, too — As a cataloger, I had been taught to put x-ref cards in the catalog for variant ways that patrons might look for a book, and following the same principle on web pages, it became possible to apply it on a much larger scale.

It continues to surprise me that this simple idea — Putting tags on web pages — has not been more widely applied. I have seen very few cases of it at other sites. I suspect part of the reason for this is that people have tended to think the hidden meta keyword field was the place to put tags, rather than “cluttering up” their pages by putting them on the page. Google’s announcement a few days ago that they ignore meta keywords finally puts an end to that idea. But many SEO people have thought meta keywords were ineffective for a long time, and it was certainly our experience — Around the time we began putting tags on pages in 2000, we compared meta field tagging and on-page tagging, and found that meta field tagging seemed to be ignored by Google.

Another factor that may have discouraged people from putting tags inconspicuously at the bottom of the page is that SEO people generally say that words need to be in a prominent place on the page, preferably near the top, to be found by Google. That’s no doubt true for common words that have a lot of competition, but for relatively uncommon words, like variant spellings of medical diseases, placement at the bottom of the page works well. (One proviso: Our pages with HMD are relatively small, usually no more than two screens. Putting tags at the bottom of larger pages may not work as well.)

I suspect a reason that people don’t think more of experimenting with tagging and Google visibility is that it is a lengthy process. Google’s not going to see new words on your page right away. It may take several weeks or even months. So it requires careful record-keeping, to note when words are added, and having a regular schedule of Google checking to see if your pages are starting to appear in search results.

The idea of Google Flu Trends is shown nicely in the snapshot above from the animation at the Google Flu Trends site — Google finds that there is an excellent correlation between flu-related terms that people search and the occurrence of flu, as measured by CDC data. And, as shown in the animation, the Google search data in near real-time precedes CDC data, which takes 1-2 weeks to be reported and compiled.

Complications

The idea of using search data to track the progression of disease outbreaks certainly is elegant, and Google deserves congratulations for it. In choosing flu as the first example, however, Google has chosen a disease with complicating factors.

The nature of these potentially complicating factors is suggested in the graphic above from the Google Flu Trends site — A big question here is — What caused the spike in flu occurrence and flu search activity in Dec 2003 – Jan 2004?

Because Google has chosen not to reveal the exact search terms that they are using to determine the volume of searching for flu-related searching (see supplementary material accompanying Google’s paper in Nature), it’s difficult to know the cause of the 03-04 spike with certainty. But looking back at the chronology of that time period sheds light — There was a major shortage of the flu vaccine in late 2004, which is certainly related to the spike shown in the graphic — The CDC spike (yellow) shows that many people had flu, presumably because they were unable to get the vaccine. The Google spike (blue) is even higher, which may indicate that there were a significant number of people searching for flu information not because they were infected, but because they were looking for information on how to get the vaccine. The accompanying article (Flu Symptoms vs Flu Shot) shows that there is in fact a clear indication of heightened search activity for flu vaccine-related terms during the autumn pre-flu season.

The other complicating factor in looking at flu-related search activity is bird flu, and this seems to have been addressed well by Google — The large bird flu outbreak in Asia, and corresponding bird flu scare throughout the world, occurred in late 2004 and early 2005. Since there is no major spike shown in the graphs for this time, Google apparently has excluded bird flu/avian flu search terms from the aggregate group of terms it’s using.

** This is one of a group of three articles on Google Flu Trends:

• Google Flu Trends: Kudos & Complications (this article)
• Google Flu Trends: Flu Symptoms vs Flu Shot
• Google Flu Trends: The Iowa Connection

Together, these articles suggest that, although it’s difficult to know with assurance because Google has not revealed the search terms that they use for GFT, it seems likely that they’ve done a good job in working around the complications of flu-related search patterns.

Recently Peter Brantley suggested that libraries should make it easy for users to find public domain content on their sites. So, with thanks to Brantley for this idea, we’ve made a page that shows public domain galleries for specific diseases (see snip below).

Brantley also suggests that libraries with public domain content make the content available from a specific directory called /public. This seems like a good idea, and we will be considering it.

Shown below are the “intro” pages for the book in the 2 systems. The clear advantage of the GBS intro page is that the sample thumbnails in the lower right make it immediately obvious that the book has COLOR pictures of good quality.

In Internet Archive the main job of intro screen (below) is to direct the user to options to view the book, in the box in the upper left, and there’s no indication that the book contains pictures.

Even after pulling up the DjVu option to view the book — which is a tricky matter, see how to do it here — there’s no intro screen at all in DjVu, just an imposing blank page waiting for the user to change display options or begin paging through the book sequentially.

It’s when the user chooses display options and begins viewing the book that the advantages of DjVu become evident. The most important option, especially if pictures are an important part of the book, as they are in the Mracek Atlas book shown here, is to turn on the thumbnail display bar (at left) by clicking the icon in the lower right corner of the DjVu display window. It then becomes easy to scroll through the thumbnails and get a good view of the nature of the pictures in the book, and how they relate to the text. In the Mracek Atlas, it happens that the first third of the book is all text, and the last two-thirds is mostly pictures, so the user can scroll to the pictures easily.

Use of thumbnails is a good way to provide access to pictures in a book. But as simple and obvious as it is, thumbnail access is lacking in most e-book systems, so both GBS and DjVu are to be applauded for providing it, in their different ways. Here’s a comparison of the two systems …

In GBS, the About this book page gives immediate thumbnail access to a maximum of 30 pictures. Additional pictures have no thumbnail access, and can only be found by scrolling through pages or text searching.

DjVu has the disadvantage of having no Intro page that gives an overview of pictures in the book. But when the user knows how to set the display options, it provides good thumbnail access to an unlimited number of pictures. In a book like he Mracek Atlas, with over 100 pictures, this is a definite advantage.

Postscript: It wasn’t easy to find a book that’s in both GBS and IA, so I was especially pleased to find the Mracek Atlas discussed here that has pictures in Hardin MD! The full citation for the book is: Atlas of diseases of the skin, by Franz Mracek, 1899 [GBS | IA]

In large mass-production systems like Flickr, automatic thumbnails are unavoidable, and my point is not that they should never be used. Instead, my point is that, on many levels, pictures require more human input than text to make them optimally usable. Pattern recognition — the simple observation that the thumbnail of a picture of a sunset SHOULD CONTAIN THE SUN — is something that the human brain does easily, but this does not come naturally for a computer.

Another sort of problem in automatic production of thumbnails is making a thumbnail by simply reducing the size of the large picture. If the main subject of the picture is relatively small, it is not visible in a small thumbnail.

The picture to the left is from the Hardin Library ContentDM collection. The inset in the upper right shows the thumbnail that’s generated automatically by the system, which does a poor job of showing details of the picture. The lower inset shows a thumbnail made manually, which gives a much more clear view of the central image in the picture.

Cropping of a picture to produce a thumbnail, as done here, takes more subtle human judgement than the case with the Flickr picture in the first example, where the weakness of automatic production is obvious. With cropping, there’s inevitably a trade-off between showing the whole picture in the thumbnail or showing the most important subject of the picture. In cases such as this one from ContentDM, where most all of the detail in the picture will be lost in a small thumbnail, it seems better to focus on a central image that will show up in the thumbnail.

Finally, a few examples from Hardin MD, below, show how we have done cropping to improve the detail in our thumbnails. The thumbnails on the left in each of the three pairs are made by simply reducing the size of the full picture. On the right in each pair are the thumbnails we use, that we have made by cropping the full picture before making the thumbnail.

The biomedical, scientific pictures that we work with in Hardin MD are fairly easy to make thumbnails for, because they generally have a well-defined focus, that’s usually captured well by automatically-generated thumbnails. More artistic, humanities-oriented pictures, such as the ones discussed here from Flickr and ContentDM, however, often have more subtle subjects, that benefit from the human intelligent touch in the production of thumbnails.

As the volume of pictures has grown, providing access to them becomes more difficult. For some time, we have grouped pictures on specific disease conditions into small galleries, each with about 3-12 pictures (ant bites, athletes foot, atopic dermatitis below). Recently, however, we have expanded the gallery format, broadening it into larger gallery collections, which have links to the smaller galleries.

Use of the gallery format has been very effective in increasing access to our pictures — We are finding that users are much more likely to click thumbnail disease links deeper on the page than when a list of text links is provided.

In addition to the gallery collection pages for AIDS, cancer, and child diseases, which are shown on the gallery gateway page above, there are also gallery collections for foot problems, herpes, insect bites, mouth sores, nail problems, oral diseases, skin rashes, STD’s, and tropical diseases, all of which are linked on the inclusive gallery page.

The screen-shots below, for the Hardin MD : Impetigo Pictures page, show this clearly. The Extreme Tracker shot for this page shows the large proportion of search engine traffic from the word “pictures” (36%) compared to the small amount of traffic from the word “images” (0.6%).

Hardin MD : Impetigo Pictures page	Keywords (Extreme Tracker)

The Google screen-shots show that the Impetigo Pictures page gets an equally high ranking for the two words, so it’s apparent that “pictures” is being searched much more frequently.

Google search: impetigo pictures	Google search: impetigo images

(Note that these screen-shots have been photo-edited to fit the space — Ads and other text not relevant to the article have been removed. All screen-shots captured in July 2008.)

Here’s the background …

In about 2001, we started noticing how people were finding Hardin MD pages in search engines, and designing our pages to make them more likely to be found. An important part of this was using words that people were more likely to search (e.g. “heart diseases” instead of “cardiology”). Tools such as WordTracker that show how many people are searching for particular words are especially useful for this.

About this same time, we were starting to make links to other sites that have pictures on medical/disease subjects. Using WordTracker, and ExtremeTracker (to see words people were searching to find our pages) it was striking that the word “pictures” was very effective. At the time, we assumed that the appropriate word to use was “images,” since that word is what’s used on most medical/disease pages at other sites. We could see clearly, however, that using the word “pictures” on our pages brought much more traffic than the word “images.” So we’ve gone on from there, and now have high rankings in Google for many medical/disease subjects combined with “pictures,” as with Impetigo.

Hardin MD: Impetigo Pictures | Extreme Tracker | WordTracker

In pre-Google days, the task of finding good lists of web links needed the input of smart humans (and Hardin MD was on the cutting edge in doing this). Now, though, Google Web Search gives us all the lists we need.

Pictures are another story — on many levels, pictures require much more human input than text.

The basic, intractable problem with finding pictures is that they have no innate “handle” allowing them to be found. Text serves as its own handle, so it’s easy for Google Web Search to find it. But Google Image Search has a much more difficult task. It still has to rely on some sort of text handle that’s associated with a picture to find it, and is at loss to find pictures not associated with text.

The explosive growth of Hardin MD since 2001 (page views in 2008 are over 50 times larger) has been strongly correlated with the addition of pictures. This time period has also gone along with the growing presence of Google, with its page-rank technology, and this has come to make old-style list-keeping, as had been featured in Hardin MD, less important.

Though Google has accomplished much in the retrieval of text-based pages, it’s made little progress in making pictures more accessible. Google Image Search is the second most-used Google service, but its basic approach has changed little over the years.

The basic problem for image search is that pictures don’t have a natural handle to search for. Because of this it takes much more computer power for the Google spider to find new pictures, and consequently it takes much longer for them to be spidered, compared to text pages (measured in months instead of days).

Beyond the problem of identifying pictures there are other difficult-to-automate problems for image search:
• How to display search results most efficiently to help the user find the what they want — Do you rank results according to picture size, number of related pictures at a site, or some other, more subjective measure of quality?
• What’s the best way to display thumbnail images in search results?
• How much weight should be given to pictures that have associated text that helps interpret the picture?

So — Good news for picture people! — I would suggest that pictures are a growth sector of the information industry, and a human-intensive one. I would predict that text-based librarians will continue to be replaced, as computers become more prominent. But there will continue to be a need for human intelligence working in all areas relating to pictures, from indexing/tagging to designing systems to make them more accessible.