Subcompartmentalized publishing

The other day, someone's Twitter recommendation convinced me to add Craig Mod's essay Subcompact Publishing to my Readability queue. And after reading it, I recommend you read it too. It's full of interesting stuff (I didn't know what skeuomorphism was!) and interesting points for librarians to keep in mind ("Content without a public address is non-existent in the eyes of all the inter-operable sharing mechanisms that together bind the web."). But still, I think it got at least one thing fundamentally wrong.

Mainly, the article presents Marco Arment's iOS app/publication The Magazine as an example of a "subcompact publishing." Roughly, that means it uses a simple, innovative, forward-looking approach rather than trying to adapt existing business models to a changed technology environment. Mod provides an eight-point list of qualities associated with subcompact publishing as a starting point, and it seems like a decent list as far as it goes. (Conveniently, The Magazine illustrates all eight points.)

I would add another quality, though, on which The Magazine fails: interoperability. You need an iOS device, preferably an iPad, to read it. This definitely does not feel like a model of The Way Forward for the Publishing World. Most publishers would probably prefer to sell to readers, regardless of what device they own. Selling content packaged in a platform-specific app might seem like an innovative fusion of programming and publishing, but it limits your market before you even start. Using Apple's Newsstand may work just fine for The Magazine, but there's likely a reason it's "under-leveraged."

[Speaking for myself, The Magazine looks pretty interesting, but I don't have an iPad. I do have an iPod touch, but I'd prefer to read long articles on a desktop machine or my Kindle Fire. So there's some friction there. And there's a lot of other interesting stuff to read that I can queue up in Readability.]

One other point: Mod sensibly advocates for "digital-aware subscription prices." But publishers should keep in mind that when it comes to newspapers and magazines, the content is usually a loss-leader, and delivering advertisements to readers is the real product. (With books, the content is the product.) "Digital-aware" probably means that a paid product should not rely on advertising, so digital publishers lose that revenue source as they save on production costs.

Data Visualization on the cheap

Well, I may be the last person in the world to learn this, but newer versions of Excel now let you apply more than two conditional formatting rules. I was making a chart counting the hours of the week when our "Ask a Librarian" questions come in by email, and thought I'd highlight the busiest times with a conditional formatting rule or two. But it turns out, for this chart at least, that setting up four easy rules is all it takes to make it into a passable heat map:

Redirecting OPACs in the Evergreen ILS

We currently use the Evergreen open-source ILS, and after upgrading to version 2.2, we switched to the new TPac from the old JSPac. The new OPAC is faster and has some nice features, like sending call numbers to a phone.
But there was one problem: we have a whole lot of links in our web content (mostly in libguides) to titles on the JSPac. I wanted to redirect those URLs to the same items on the TPAC, so users wouldn't be confused by the old interface. In the process, I found that some of our librarians linked to title searches rather than individual item records. (Thanks, libguides authors!) So I decided to try to redirect a few more kinds of the old OPAC URLs.
Just in case there's anyone else in the same boat, here's a generic version of the code I came up with. This is all Apache configuration info, placed in the relevant VirtualHost section of eg.conf.

It handles all the old links I could find in our web content:

• links to the main catalog page
• links to the OPAC login page
• links to individual item records, and
• links to basic search results

One could do a more thorough and/or reliable job of this. I didn't attempt to handle advanced searches, for example. On the off chance anyone uses or improves on this, please let me know!

Mapping flickr photos on Google Maps

One of my hobbies is photography, and like many photographers I am frequently on flickr looking for good ideas to steal. For some photo projects, like street art or weird stuff, I am often looking for new subjects, and I need to know not only what they are but where they are. Luckily, many flickr users geotag their photos, so that flickr can display a map with the location where the photo was taken. For me, planning a trip to another city usually involves looking on flickr to find new things to photograph and their locations.

Flickr isn't the best tool, however, for keeping track of lots of locations. For that I use google maps, which makes it easy to create lists of locations. It also makes it easy to export them to KML, which can easily be converted into formats that can be loaded onto a GPS device. So I've spent a lot of time copying coordinates and other information from flickr to google maps. There had to be an easier way.

One easier way is to use a Greasemonkey script by "tarmo888" called "Alternative Map Links for Flickr." This adds links to many mapping services from any flickr page that includes a geotagged photo. With one click, you can plot the photo's location on any of these services, including Google Maps, where it's ready to be saved to your own custom map. Handy!

There are a couple small drawbacks, though, for my purposes. First, to use the script I'd have to use Firefox and install the Greasemonkey add-on and the script to every Firefox profile I'd want to use for mapping. Second, the point the the script passes to Google Maps is identified only as "Flickr." I'd still have to copy other information to Google Maps.

So I made this little bookmarklet, borrowing a few ideas from tarmo888. You can install it by dragging this link to your browser's bookmarks toolbar:

flickr2gmap

From any geotagged flickr photo page, the bookmarklet will open a Google Maps window with a marker at the photo location. It passes along the title of the photo, the date taken (if known), and a link back to the flickr photo page.You can save the point to your own custom map and edit further as desired.

Here is the code in more readable form. Feel free to reuse if you wish:

javascript: (function() {
    var m = document.getElementById('photo-story-map-zoom-out');
    if (m) {
        var cut = function(str,cut) {
            str = str.replace(/&/g,'%2526amp;');
            if (str.indexOf(cut)>0) { return str.substring(0,str.indexOf(cut)) }
            else { return str }
        };
        var re = new RegExp('[\\?&]c=([^&#]*),([^&#]*)');
        var c = re.exec(m.src);
        var lat = c[1];
        var lon = c[2];
        var t = cut(document.title,' | Flickr - Photo Sharing!');
        var d = "date unknown";
        var s = document.getElementById('photo-story-story');
        if (s) {
            var dre = new RegExp('/date-taken/([0-9]+/[0-9]+/[0-9]+)/');
            var r = dre.exec(s.innerHTML);
            if (r) {d = r[1].replace(/\//g,'-');}
        }
        var l = cut(document.URL,'/in/');
        var u = 'http://maps.google.com/?q=' + lat + ',' + lon + '(' + escape(t) + '+' + d + '+' + l + ')';
        window.open(u,'flickr2gmap');
    } else {
        alert('No map info found on this page.');
    }
})
()
And no, this doesn't have anything directly to do with the Systems Librarian gig.

Update, 2012-07-02:

Minor change to the script to make it work with the new flickr maps.