Tuesday, April 17, 2012

Cataloging Matters Podcast no. 15: Cataloging Interfaces

Cataloging Matters Podcast no. 15:
Cataloging Interfaces


Hello everyone. My name is Jim Weinheimer and welcome to Cataloging Matters, a series of podcasts about the future of libraries and cataloging, coming to you from the most beautiful, and the most romantic city in the world, Rome, Italy.

In this episode, I want to talk about cataloging interfaces. Do we love what we have or do we hate them all? Can we imagine any other possibilities? What could an alternative look like and how could it work?

To begin, I wasn't sure if I should do this as a posting or as a podcast. It got pretty long for a posting and seemed short for a podcast. After much deliberation, I decided that maybe my podcasts are getting too long anyway, and I finally decided to do this one as a podcast. I can only hope it works. There are a few times when I refer to YouTube videos or images so you may have to look at the transcript a few times to really understand everything. I apologise for that, but I haven't been able to figure out anything else except for a video and I'm not ready for that. Of course as always, in the transcript you will find links to everything I refer to.

On the RDA list, and I believe in an article in Serials Librarian, Kevin Randall of Northwestern University mentioned how the interfaces for catalogers need to improve. http://serialscataloger.blogspot.it/2012/03/rda-end-of-world-postponed-by-kevin-m.html These are the interfaces used by technical staff when they input records. Although I personally believe there are more pressing issues for catalogers that would have much greater consequences for the public, such as modernizing workflows, eliminating redundancies and most important, actually enforcing the cataloging standards that exist, the issue of cataloging interfaces nevertheless is a very interesting question and I would like to address it here by making a few suggestions that may turn out to have some promise, at least it seems to me that they could.

Lately, I have been trying to build some computer applications, or apps, and right now I am focusing on the Android operating system. I have been working with a rather remarkable online tool called “App Inventor.” It was originally created by Google, but they made it open source and it is now hosted at MIT http://appinventor.mit.edu/. To understand the motivation for this project, I need to provide a short background:
With the growth of mobile communications and the new platforms, iOS, Android, and so on, applications have become the current "hot" products for developers and everyone is now rushing around trying to make their own. Currently, separate applications are built for specific platforms, so an Android app will not work on an Apple Iphone while a app that works on the Ipad will not work on an Android device. And of course, there are other operating systems too, for Windows and Blackberry! So, we are looking at a major marketing fight.
Apple has a real advantage in this fight. Since Apple has retained control over practically everything including the software and hardware, as it always has, apps for the Apple products are apparently of much better quality, in that the coding is better done so that they work better. Apple's apps are also better designed or at least more consistently designed, and so on.
The Android market is different since everything is open: open source and open development. Because of that, where Apple has control, with Android there has been a corresponding lack of control, and it seems that the result has been inferior products: in Android apps, the coding is not so well done as in Apple products, the user interfaces have much more variability which apparently confuses people, and as a result the final products of the Android market are considered to be inferior. This was discussed in an article in Wired Magazine, MIT, Google Release New Tools to Fix Android’s Quality-Control Problem / by Mike Isaac, March 5, 2012.

Personally, I have practically no experience with apps from Apple so I have no opinion, but will simply accept that all this analysis is correct.

To counter these concerns, Google created a tool called App Inventor, which is supposed to ensure that at least the coding is reliable on Android platforms. How have they done this? App Inventor provides an interface for development that is almost entirely graphical and there is no need to know any coding at all, or practically none. So, for those who want to try to create an Android app, much of it consists of creating certain "blocks" of information, that is, of text, images, canvases to put the images on, and so on, and you can add all different kinds of functionalities, such as animation, GPS, phone calls, texting, changing orientation, timers, web browses and more.
As you build your app, you discover that some parts "fit" and other parts do not. This happens when you try to put certain blocks together and--remember that it's a graphical interface--the system makes it clear that a specific block cannot be connected to another block. So it looks a lot like when you try to connect pieces of a jigsaw puzzle that do not fit, except it is more obvious. Some blocks may require additional information of a specific type or even require other blocks. When you make an error, you are immediately made aware of the problem and given some guidelines for how to correct it. To see how this works, I provide a link to a short video tutorial on App Inventor. There are a lot of videos for App Inventor, but this is one of the shortest and simplest. 


Although I have worked with this tool to some extent, I am still far from an expert. Perhaps because of some residual memories from my childhood when I would play with my beloved Tinkertoys, I find App Inventor to be very useful and in fact, kind of fun. When everything “fits” together, you can download the app onto your cell phone and watch it go!

Additionally, the Android community has created a "best practices guide" http://developer.android.com/design/index.html which is excellent. The design principles provided in this document are for developers to follow when they create apps. These principles seem to be based primarily on Web2.0 design principles that you can find in different places on the web. I give a link to one example http://www.webdesignfromscratch.com/web-design/web-2-0-design-style-guide/. I would like to list the basic guidelines here as given in the Android “Best Practices Guide” that a developer should keep in mind when designing the application. Of course, in the actual guidelines, each of these points go into greater depth:

  • Delight me in surprising ways
  • Real objects are more fun than buttons and menus
  • Let me make it mine
  • Get to know me
  • Keep it brief
  • Pictures are faster than words
  • Decide for me but let me have the final say
  • Only show what I need when I need it
  • I should always know where I am
  • Never lose my stuff
  • If it looks the same, it should act the same
  • Only interrupt me if it's important
  • Give me tricks that work everywhere
  • It's not my fault
  • Sprinkle encouragement
  • Do the heavy lifting for me
  • Make important things fast 
It remains to be seen if any of this will serve to be a genuine competitor to the apps from Apple, but to me at any rate, it seems like a worthy experiment. The person who creates an app in this way does not need to know any coding at all. Many reviewers are describing App Inventor as “apps for the masses” or they use similar terminology. Some reviewers definitely like it while others definitely do not. One problem with this tool seems that currently, you can only do relatively basic apps with App Inventor, and if you want to do something really intense, you would eventually have to get into the code. Still, since it is open development, there will definitely be improvements, and sometimes such developments can happen surprisingly fast. Some theorize that the capabilities of App Inventor will improve so much that it could end up similar to creating a blog or a website, which now can be done by people without a need to know any coding at all, although App Inventor has not reached that point yet. http://articles.cnn.com/2010-07-12/tech/google.app.inventor_1_app-inventor-android-market-iphone?_s=PM:TECH

At the very least, the idea of App Inventor is intriguing. It simplifies an entire range of highly technical functions and has this "best practices" guide that is well-organized and clearly written. Of course, the principles in the best practices section do not apply only to Android apps, but to many other projects as well.

I do not care to enter into a discussion whether Apple or Android is better or worse. I am interested in considering an App Inventor-type interface as a possible herald for a new cataloging interface. These are also not all of the problems with open source development of apps, I have placed a couple of links to relevant articles in the transcript for those who are interested.  

Why Google Android Can't Compete With Apple's iPhone, The Market Oracle, April 04, 2012 http://www.marketoracle.co.uk/Article33963.html  
Is Google App Inventor A Gateway Drug Or A Doomsday Device For Android? / Mg Siegler. Techcrunch, Sunday, July 11th, 2010. http://techcrunch.com/2010/07/11/google-app-inventor/

Of course, the Android design principles that I quoted have a lot to do with the public interfaces of the catalog, and they will have much less to do with an interface for a cataloger, or at least, I guess so. Also, creating standardized catalog records is quite different from these simplified apps.

Many of the Android design principles come straight from what is called “Information architecture,” but there are some functions that definitely would apply to an interface for a cataloger, such as: only show what I need when I need it, make important things fast, and only interrupt me if it's important. One part, let me make it mine, is vital for catalogers to do their work: each cataloger needs to add his or her own notes, dog ear specific pages they refer to all the time, and so on.

So, in a normal workday for a cataloger in an App Inventor-type environment, I could see bibliographic records displayed graphically, so that the cataloger would just drag the name heading from another bibliographic record, or from an authority record, into your own record, or conversely, in doing some form of copy cataloging, dragging information into the wastebasket.

OK. I know pro-FRBR folks will probably say that with an FRBR structure, such a tool would let you drag a work or expression entity, including multiple authors, titles, and subjects into your own record all at one time. Of course, I reply that this will happen only in the case of a new edition of something that already exists, such as a new translation of Homer's Odyssey, or a new version of Shakespeare's Sonnets, which is currently less than 20% of the items in our databases. I personally can't imagine that this percentage will go up significantly in the future, such as to 50% or more, and will in all probability go down, that is unless the powers-that-be require everyone to start cataloging “internet memes” such as each version of the “Dramatic Chipmunk” or “Nyan Cat”. http://en.wikipedia.org/wiki/Dramatic_Chipmunk, http://en.wikipedia.org/wiki/Nyan_cat

To be honest, I have never seen how FRBR structures would make a cataloger's actual work much easier, if any easier at all, as opposed to what is done now: that is, where the cataloger finds a record for another edition in the database and derives the new record from that one, tossing out certain parts and adding whatever new is needed.

Still, much of this is beside the point for our purposes. Far more useful I think, would be an App Inventor-type of tool in conjunction with the digital resources themselves. That is, those that have information in special metadata fields, or in some kind of XML format, or in any case that use some kind of structured metadata that could be accessed in some way, then the title could be taken directly from the item itself, or the dates, or any of the structured metadata. For instance, any information needed by ISBD could be taken directly from the item, perfectly transcribed, all in a graphical way.

Of course, it is no more difficult to catalog electronic resources than anything else, but just as any specific format has specific problems, electronic resources have their own peculiarities. One very basic task where I have always had trouble is simply examining the electronic resource. Examining an online resource is completely different from a physical item, such as a book or DVD. In fact, I don't really know what to compare it to. It's probably closest to examining a serial because with serials cataloging, you can only see part of the entire serial, and the cataloger can see the entire serial only after it is dead. But even while it is still alive, when you are working on it, you are nevertheless holding an entire issue in your hand. With a web resource, you can click around randomly but it is very difficult to get an idea of the whole and consequently, it becomes very difficult to describe. If a sitemap could be generated, and depending on the information retrieved, it could be used in conjunction with a cataloging interface based on App Inventor to get a better idea of the extent and structure of the site, and of course, to catalog it using drag and drop methods.

Finally, if a tool such as “App Inventor for catalogers” were created, would it be similar to what some are calling App Inventor now: instead of apps for the masses, it would be catalog record creation for the masses? Obviously, I do not think so but who knows?

Still, I want to go beyond App Inventor and try to figure out what could be used for a new cataloging interface.

It seems to me that an App Inventor kind of tool would not help much for the intellectual task of cataloging; that is, if you don't know cataloging in the first place, such a tool will not catalog a resource for you. It isn't that different from apps: if you have no idea what kind of app you want to create, App Inventor won't help you make it.

So, if you do not understand the concept of main entry, it does little good to give you the rules for determining it or even to provide the little “block” for it.  Such considerations are far more complex than experienced catalogers may realize. For instance, personally, I always thought that the guidelines for series treatments were relatively simple: when to use a 440 vs. 490 0 or 490 1/8xx, but I admit that it was difficult to teach it. The 440 has been phased out and LC even decided to stop series authority control. There are many far more complex issues than this relatively simple one, e.g. the appropriateness of a uniform title, what is a series, analysed sets vs. collective records, and so on and so on, which I do not believe could ever be handled by such a tool. Still, when cataloging a monograph, such a tool could turn out to be very helpful.

When it comes to subject analysis, that is, what is the subject of a particular item, and not only that, what is that subject in relation to a specific database that uses a specific thesaurus or some other type of authorized forms, plus following the correct levels of specificity and exhaustivity, all to ensure a level of consistent and reliable retrieval--such a tool probably cannot help much here either. But if we are talking about the creation of LC subject headings, when the cataloger must create the subject string, this tool could make the inputting much simpler because of the order of the subject string, and whether a specific subdivision can or cannot be used under a specific heading. The order of a subject string should not be important today, I agree, but it still is important and can be very complicated to do correctly. I think App Inventor could make this sort of task much easier.

Also, when assigning subjects, I have mentioned before about the existence of subject arrays, that is, where a subject on, for example, “the library reference question interview” actually gets the two subjects: “Reference services (libraries)” and “Interviewing”, or that an item about archaeology may require a whole number of other subjects. Finding these subject arrays so that searches retrieve reliable and consistent results, can be very difficult and time consuming, and it is something I have always felt would be suitable for graphic methods.

The way this could work would be with boolean-type circles, where the cataloger would search e.g. “library reference question interview” and the related subjects for the items would appear, but each would be displayed in separate circles. The cataloger will be able to see the circles coming together in various places, and the cataloger could click on those places to see the subjects used in those records. I provide an example of how it could work for searching “library reference interview question” and the cataloger has selected the section “library interview question”. When you would select, the subject headings used in those records could be displayed as a tag cloud, which the cataloger could click on as well. You may instead wish to look at “library reference interview” to get other headings. I have an example display in the transcript.

Since these kinds of tag clouds can be generated now, the only real difference from today would be the graphical interface.

Of course, a cataloging interface needs to be closely connected to the rules, but as long as the rules are in subscription databases, this sort of development will take place mostly within the organization that owns the rules. With more open development of rules however, much closer and personalized connections could be made.

Whatever happens, in the future, I believe that one of the main points for cataloging will be to realize that the records catalogers make will no longer be aimed for use only within a specific catalog. They will go out into all kinds of other venues and take on lives of their own. In the future, records must fit into the entirety of the metadata universe. As a result, library catalogers are going to have to become far more aware of rules and guidelines from other communities as the libraries and their catalogs cease to be such closed islands as they have always been. This will have to be reflected in their cataloging interfaces somehow.

Perhaps most important is the ability to ask questions of colleagues. I have mentioned this already in some posts, and have suggested that a system could be built up that allows professional catalogers to discuss technical questions by sharing through wikis, instant messaging and now through free internet phone calls. For efficiency's sake, it is important that these specialized discussions and decisions become archived and shared in various ways so that all may learn and search the answers, along with the discussions. Such types of professional portals already exist in some fields, for instance for radiologists and dentists, where they can post questions, get replies, and so on. http://www.auntminnie.com and http://www.drbicuspid.com 

Skype allows people to share the desktops, but Teamviewer http://www.teamviewer.com is another program that could be useful for catalogers since this program allows a remote person not only to view your desktop but even work on your machine! Such tools perhaps have more promise for training and remote reference services as it does for cataloging but still, they could be very useful.

In short, there are many tools that exist now that could help catalogers become far more productive, and at the same time make the task of cataloging itself become more enjoyable by allowing catalogers to see how the records they make, and how they themselves, all fit into the environment of global metadata. Almost anything can be done, and the main thing is to cultivate our imaginations. I brought this out in a number of earlier posts of mine, under the subject “In praise of lazy catalogers,” which caused a bit of a stir but I still believe what I wrote there. http://blog.jweinheimer.net/2009/06/in-praise-of-lazy-catalogers-autocat.html  

And on that note, I come to the end of this podcast.

The music I would like to end with is one of the most popular songs in Italy, and you hear it everywhere. It is called “Bella ciao” which means, “Goodbye, beautiful” and was a song sung by the anti-fascist partisans during World War II. There are many versions available on the web, sung by children or even by drunken young people at soccer games, but I think this song needs to be sung by a group of men. Fortunately, I found one at no less a place than marxists.org http://www.marxists.org/subject/art/music/lyrics/it/bella-ciao.htm, and there you can see the lyrics along with a translation.

That’s it for now. Thank you for listening to Cataloging Matters with Jim Weinheimer, coming to you from Rome, Italy, the most beautiful, and the most romantic city in the world.


  1. Very interesting post, Jim. I have bookmarked the links you suggested and will poke around a bit with these. Your ideas are intriguing - but (but!) - I know far too many librarians who do not understand the process of cataloging, and I can imagine some of those folks demanding an instant ROI. Good cataloging is not that easy. Reliable subject analysis is even harder! I have always kept a list of OCLC codes of libraries I felt I could "trust" as having good records. For me, then, the concept of anyone being able to create records is anathema. Even so, it may be the future, and that is where we are headed. Thank you for something so thought-provoking. Amy Ranger, MLS, Grand Rapids, MI

  2. Go for it Jim! Program to your heart's content. App Inventor looks like a cool tool. Yup, Apple apps seem cleaner because Apple protects the users' experience. Android, which lacks screening, protects the enthusiasm of the programmers ("developers"). When you reach Apple's standards, release also at Apple.

    You are special. You live at the intersection of cataloging & programming. You can talk to each community in its native language and reflect a world of the other that neither really can experience.

    There is a nugget of an idea within FRBR that works, had it only have been correctly construed and acted upon. Heaney was closer. I have been trying to set my vision to electrons. It is simple & beautiful. When I finish I will share with you and others.

    The universality of the records has been tried at for a good long time. Before LC cards catalogers used the rules as a universal filter through which to describe books. After LC cards, well at least the places I worked at used catalogers as much as a way to rebel against the orthodoxy of the rules in a very institution specific way. Having rules applied consistently won't hurt--if that is what record contributors to will do. I can imagine a world where individual publishers & jobbers will try to do things distinctively to tweak search/shopping results towards their own products.


    Zoltan Tomory, MLS