Geotagging my photos for greater datanerdery

When I do my year in photos project (every odd year since 2005) my worst librarian tendencies surface and I get somewhat obsessive about organizing them and making sure all the metadata is just so.

This year I’ve got a new wrinkle in that mix: geotagging. GPS data can be embedded in a photo, enabling all kinds of cool mapping stuff. Mostly I just like looking at where I’ve been this year in Picasa:

When I take the daily photo on my phone, all’s well with the geotags. The phone uses it’s GPS function and embeds the coordinates in the photo. But my phone’s camera isn’t amazing, and I try to use my Canon camera instead when possible. The Canon has no embedded GPS, so has no way to know where each shot is taken. Sure, I could manually place them on a map in Picasa or Flickr, but that’s tedious and inexact and requires a more detail-oriented memory than I usually possess.

I could also upgrade to a new point & shoot camera with GPS built in, but I’m not willing to face that expense right now. I wanted something that would tie my phone’s GPS into the camera. I didn’t expect to find much, but somewhat surprisingly there’s actually multiple options to do this:

First I found the aptly named Geotag Photos software. There’s two pieces: a phone app (for both Android and iPhone) and a desktop application. Turn on the phone app while you’re out taking pictures. It logs your position at regular (configurable) intervals. When you’re back at your computer, the desktop application compares photos’ timestamps with the gps log from the app. When there’s a reasonable match, it adds the tag to your photo. In my experience this works very well, but requires that I remember to turn the app on and get it logging before I snap a shot. That’s not a big deal for a day of frequent shooting, but for spur of the moment stuff it becomes an issue. I should note that the mobile app can be significant battery hog too.

Second is LatiPics. I’m a little astonished that Latipics has such anemic coverage on the web, because it’s pretty amazing. Latipics removes the separate mobile app from the equation, using only a desktop app. Instead, it pulls locations from your Google Latitude history. I already have Latitude turned on and logging, so it requires no extra effort on my part. Otherwise, the desktop application works a lot like Geotag Photos – it compares photo timestamps to my Latitude log, and adds geotags to the photos where there’s a match. This is pretty much my ideal solution (see the aforementioned lack of extra effort), but Latitude updates my location at somewhat random intervals and as a result doesn’t always provide a precise location for a photo. And of course, LatiPics requires you have Latitude history logging turned on and use a phone that can regularly update the service.

A third option is using an EyeFi SD card. I haven’t tried this personally, but don’t think it would suit my needs. EyeFi geotagging relies on examining your proximity to wifi access points, and so is less precise than a real GPS unit. And if you’re not in range of any wifi networks, it can’t do any tagging at all.

Geotag Photos and Latipics have different strengths and weaknesses. I find that I use both as a result: Geotag Photos for higher precision when I’ve planned taking pictures well in advance, and Latipics as a slightly less precise ‘better than nothing’ backup plan for spur of the moment opportunities. I should also note that Latipics is free, while Geotag Photos’ mobile app costs about 3 Euros.

(As a perhaps obvious final note: there’s clear privacy issues with sharing geotagged photos online. Mythbuster Adam Savage once accidentally revealed where he lived via a geotagged photo. Just be careful and use common sense.)

Upcoming presentation: Computers in Libraries 2011

I’m very excited to be presenting briefly at Computers in Libraries in DC next week! Come see me at 4:30 on Monday, 3/21. I’m not quite sure where I’ll be, but I’m part of the Cybertour series of quick presentations. Here’s my slides in advance, though they probably make more sense if you hear my talking that goes with them:

Virgin’s Project – app overkill

cover of Project, issue 1Earlier this week, Virgin launched an interesting new project. It’s called, well, ‘Project’. Project is essentially an iPad-only magazine. The key word is only. I’d link you to an article in the magazine, but I can’t.

See, Project has no real web presence. They maintain a blog, but that blog’s content is entirely separate from the app’s articles. The only way to read those articles is via the iPad app ($2.99/issue). This restriction cuts to the heart of my ongoing concern with app culture. As I’ve said before, Apps lock up data and go against one of the central ideas and advantages of the open web – the ability to link between pages.

Project could have the most fascinating articles in the world, and nobody would know. The Project app has no copy/paste option, no real export ability at all. The only included export feature (and I use that word loosely) is emailing a screenshot of one page of an article to someone. I’d be embarrassed to share info with anybody that way.

Without the ability to link articles, Project loses out on the magic Google juice. The only way to find text in the article is by random browsing through the pages. Nobody will ever just stumble across a Project article unless they were specifically looking for it in the first place.

Jeff Bridges wanders through a Project article via videoI understand that Project wants to experiment with magazines in the emerging tablet world. And it admittedly has some nice features integrating video and slideshows into the pages (Jeff Bridges wanders around the cover and a couple of interior pages while you read (see screenshot), and the effect is not unlike a photograph from Harry Potter). But locking all the content inside an app is a huge misstep.

Why not go after the tablet market with an HTML5 webpage instead? I’m willing to bet that 90% or more of Project’s multimedia functionality could be replicated on the open web. The result would be cross-platform (other future tablets could read it too), and the content would be linkable and Googleable. Lock it behind a subscription wall if that’s the desired business model, whatever. But on the open web users could at least stumble on an abstract or summary. Just put it on the web somehow. I’m not saying Project’s content is particularly amazing, but with the existing model how would anybody even find out? It’s impossible to post a link to an article on my blog, twitter account, or anywhere else.

Or please, at least allow readers to copy and paste text snippets. If I ever wanted to quote a Project article, I’d have to transcribe the text word by word. In the year 2010, that’s insane.

Apps have their place, but locked-down magazines aren’t it. This kind of thing hurts the internet.

LILRC Presentation

Last week I had the opportunity to talk with the friendly folks at the Long Island Library Resources Council about mobile web development for libraries. I had a ton of fun, and the group had some great questions! Thanks everyone!

My slides are embedded here, and the original powerpoint file is available at http://bit.ly/LILRCmobile

(note that the animations don’t work on Slideshare)

Android’s App Inventor: Drag and Drop Programming

It took a while, but Friday afternoon I finally got an invite to use Google’s App Inventor program. What is App Inventor? It’s Google’s attempt to simplify building apps for Android devices. Apps are built using a drag and drop interface, and reflected instantly on a connected Android device.
App Inventor UI screenshot

I was skeptical about the system’s ability to produce apps of any real functionality, but I was happy to be proven mostly wrong. Building a well-structured UI is admittedly almost impossible, with only basic layout and design tools available. But the app inventor does provide easy access to surprisingly complex elements of the Android functionality. The GPS, barcode scanner, camera, speech recognition, and accelerometer are among the tools easily usable via drag and drop. After placing buttons and labels to design the UI, a separate drag and drop interface is used to establish how those elements interact with each other. A series of blocks click into each other, with a bit of typing to provide some details.

Blocks Editor

It’s a nice system, and my skepticism about App Inventor’s potential beyond the toy level was quickly overcome. I ran through the first tutorial app (touch the picture of a cat and it meows! This didn’t help my skepticism…) in a few minutes. Less than an hour later I’d built an app to search the UNC catalog via an ISBN barcode scan. It relies heavily on our existing catalog webapp to do the actual search, but still! I mastered using the barcode scanner for apps in less than an hour. My previous attempt at Android programming (in Java, before App Inventor existed) took me four hours to build an app that simply displays an image. And that simple task drew on every single bit of programming know-how I could dredge up from my undergrad days.

The barrier to entry for using App Inventor is almost absurdly low. My slight background in programming did help, and I would have taken a bit longer if I wasn’t familiar with things like variables and function returns. But the point of App Inventor is that I wasn’t required to know those things in advance. I could have picked it up in a little extra time. This kind of setup seems perfect for intro-level computer science courses, teaching basic programming concepts while retaining the satisfaction of seeing a fully functional app at the end. Google definitely realizes this and is targeting educators as potential users.

App Inventor is clearly still a beta product, with some notable limitations. Apps built in App Inventor can’t be distributed in the Android Market. The install files need to be manually distributed to phones. There’s also no resulting Java source code to tweak for more advanced purposes. And disappointingly, using APIs beyond a prescribed few (Twitter, Amazon, etc) involves more complicated Python coding. There’s also some strange odds and ends, like not being able to change the app’s icon.

I’m not under any illusions that App Inventor apps will someday replace Java-coded apps. But it got me excited about programming in a way I haven’t been in years. That’s gotta count for something.

If you’d like to try the barcode scanner app I built and see what App Inventor is capable of, here’s the installable apk file: http://dl.dropbox.com/u/905114/UNC_Catalog.apk

My favorite Android apps

I’ve had my Motorola Droid long enough now to feel like I’ve always owned one. Those dark pre-smartphone days of last October seem hazy as they retreat into the past. I listed my favorite Android apps in my early days of ownership, but that list has changed a bit over time. And while I have a lot of apps installed, not all of them get used every day. Here’s the dozen or so android apps I currently use most often:

Setting Profiles
This is magic. Based on criteria like my location, presence of a wifi access point or time of day, Setting Profiles changes settings on my phone. For example: When my phone sees the wifi signal at work it turns the ringer off automatically. When I plug it into the car dock Bluetooth turns on. It’s a bit complicated to set up, but works perfectly. $3.95

CardioTrainer
Tracks my exercise via GPS. I use it to chart my times when I ride my bike home from work. I even used it to track a bike tour we took in Paris, and had a great time examining the route on a map afterward. Google’s My Tracks app performs a similar function, but focuses on just collecting raw data. CardioTrainer is tweaked specifically toward fitness tasks and provides some low-level analysis. Free.

Drop7
I don’t play nearly as many games on the Droid as I did on my iPod Touch. Why that might be is a topic for another time. But when Drop7, my favorite iPod Touch game, launched an Android version I bought it sight unseen. $2.99

Foursquare & Gowalla
I like Gowalla better than Foursquare, but find myself checking in places with both for different reasons. Gowalla is more fun, but Foursquare has those tantalizing freebie specials. Gowalla’s Android app is also much prettier than the Foursquare counterpart. Free

Listen
Google’s excellent podcast client hasn’t changed much lately, but still works very well. Integration with Google Reader is handy. Free

Mototorch LED
This home screen widget turns the phone’s camera flash on for use as a flashlight. Comes in handy more often than you’d expect. Free

picplz
Foursquare + twitter + camera = picplz. This app takes a picture, then checks you in at a foursquare venue. I have an archive of pictures associated with the actual places I took them – both in GPS and foursquare venue form. The picture can also be posted to twitter. It’s like twitpic, but with better geodata. Free

PRO Paint Camera
The stock Android 2.1 camera app is awful. Focus and flash options are hidden away and hard to get to. Thankfully there’s Pro Paint Camera with a much better UI. I replaced the stock camera app and never looked back. Free

Quick Settings
Does what it says. Hold down the Droid’s search button and a menu of various options pops up. Volume, brightness, wifi, bluetooth, etc. Quick Settings puts all the toggles in one place. Free

RockPlayer
If you’ve ever wanted to play a video file that’s in a format the Droid doesn’t natively support, RockPlayer does the job. Still in Beta, not yet available in the Android Market. Free (beta)

Touchdown
Android 2.1’s built in Exchange support is pretty useless – I couldn’t get it to see any folders other than my Inbox, Sent, and Trash. 3rd party to the rescue! (sensing a theme yet?) Touchdown does a much better job, though at a fairly steep price. The UI could use some work, but functionality is rock solid. Now that we’re an Exchange shop at work this is completely indispensable for me. $30

Twidroyd / Twitter (official)
I go back and forth on which of these two Twitter clients I like better. Twitter’s official client has an amazing UI and integrates twitter messaging into the phone’s contacts list, but Twidroyd has some extra functionality like the LED alert for new replies that I’ve come to rely on. I keep both installed and use whichever matches my needs at the moment. Free

Google Voice
Verizon wants to charge me $3 per month for visual voicemail access. Google Voice gives it to me for free. That’s a no-brainer. I don’t use the SMS or calling features, but might switch to them someday. Free

DC-bound

A couple notes on where I’ll be at ALA 2010 this week:

First, I’m presenting on ALCTS’ Mobile Catalog Interfaces panel:
Saturday 6/26/10 10:30 am-12:00 noon
HILTON WASHINGTON, Columbia 5

I’ll be going over our mobile catalog interface, a bit about the design process, pointing out some new features, and hoping for great questions.

Second, I’m co-chair of LITA’s Distance Learning Interest Group. We’re co-sponsoring a program with ACRL’s Distance Learning Section:
Open Access: A Conversation
Saturday, 6/26/10 1:30 to 3:30 pm
Washington Convention Center
Room WCC-144A-C

Third, for the DLIG annual meeting we’re trying something a little different. Instead of having a giant room reserved for a standard roundtable discussion for a block of time, we’ve reserved some space in the Networking Uncommons: http://annual.ala.org/2010/index.php?title=Networking_Uncommons
Networking Uncommons space
Sunday, 6/27 9:30-10AM

The Uncommons is a space on level 1, concourse A, near the exhibits. There’s tables, a projector, and plenty of power strips. We have no specific agenda. Just show up, hang out, and mingle! It’ll be morning, so feel free to view it as a warmup for the day – bring coffee and ideas. We have the 9:30-10AM Uncommons slot on Sunday the 27th.

Hope to see you there! If anyone wants to meet up during the conference, the best way to get ahold of me is a message on twitter. I’ll be around from Friday – Sunday, leaving Monday morning and trying not to melt.

Barcode scanning: Closing the app gap

I still think a lot (some might say too much) about what libraries’ mobile presence should be like. I’m still mostly happy with the decision to make a webapp instead of an app, but every once in a while I want to do something a webapp can’t. Barcode search has always been at the top of that list. We’ve got all that ISBN data in the catalog, and every book in a bookstore has an ISBN barcode. Matching those two things up would be pretty convenient. Why spend money on a book if it sits in the stacks above my head every day already, right? It’s also a feature that’s definitively mobile – it doesn’t really make any sense to search via barcode scan on a desktop browser. The best use case for catalog search via barcode scan is when I’m out and about in a bookstore, not sitting at my desk.

But webapps can’t access a phone’s camera. And no camera means no barcode scanning.

Both Android and iPhone have a number of barcode scanning apps available – including Zxing and RedLaser, respectively. Thankfully developers of both included ways to invoke those scanners from a webpage! More info on how to do this is here and here. It’s not too difficult – the only technical skill involved is understanding how to build catalog search URL.

Earlier this month we built barcode scan searches into our mobile catalog. It only works on Android and iPhone devices, and requires that Zxing or RedLaser is installed first. So it’s not a seamless experience and requires some explanation to users. I’m still working out those kinks, but was both comfortable with and excited enough about this feature to push it out with a beta label. It’s live on our mobile site at www.lib.unc.edu/m

Webapps still can’t do everything, but with a little creativity the functionality gaps close up a bit. I can’t tell you how happy I am that I was able to add barcode search to the site with a simple link instead of learning to code in Objective C 🙂

Here’s a video of barcode search in action on Android:

Geolocation at ALA 2010!

Screenshot on a DroidAs I’ve mentioned before, summer is often my most productive time of the year at work. Especially when it comes to special projects. Last summer I focused on developing a mobile site, and this summer I’m looking into the potential of geolocation in websites. My ultimate goal is to mash up GIS data with our special collections and a user’s current position. I’m not there yet. But I do have a system up and running that might provide some utility at ALA in DC next week!

Here’s the site, designed for mobile devices: http://www.hiddenpeanuts.com/ala I pulled the 18 program sites out of ALA’s list of programs, and plotted them on a google map. Then it plots the user on the same map via the phone’s GPS signal. I’ve tested it on an iPhone and Android phones, but I think it should work on webkit-based Blackberries and maybe even the Palm Pre too. (Update: Turns out the Pre doesn’t support geolocation via javascript. boo, indeed!) I’d love feedback on how those devices work (or don’t).

Obviously the site won’t show you much unless you happen to be in DC while loading it up 🙂 So here’s a demo which simulates the user being in DC.

I’m very interested in any feedback on this system. I know that the interface needs (a lot of) work, but this is as good as I’m likely to have time for before ALA. I’m also open to suggestions on what details about each location would be helpful to have on the mobile site. For now it’s just address and phone number.

Dumbphone: Using a US smartphone to navigate Europe with RMaps

After we got married (!) last month Melissa and I spent 10 days in Europe on our honeymoon. London, Paris, and Rome! It was an amazing trip, especially since neither of us had been to Europe at all before. But this post isn’t going to be our amazing trip’s slideshow. On the more technical side of things, I was fascinated at the idea of using our smartphones (we both have a Motorola Droid on Verizon) in Europe.

A little background: not all US cell phones work in Europe. I’ll avoid the nitpicky details and just say that in general AT&T or T-Mobile phones will work in Europe, but Verizon and other carriers won’t. While we could still open and use apps on our phones, anything that required a cell network connection would be dead.

This distressed my inner techie – I’ve become hopelessly addicted to navigating with my phone’s google maps, and google maps pulls the maps over a cell connection. I really wanted to use it to find our way around. The one thing that still worked on the Droid in Europe is the GPS – it can get your position in latitude/longitude. But with no data connection It has no maps to plot that point on! All that Google Maps would show me is a blue dot on a grey background. Not exactly handy for finding my way.

But with a little foresight and pre-planning, I set up my Droid to cache the maps locally before we left for Europe. This process was a bit of a pain, because it’s not well documented anywhere that I could find. Here’s a tutorial: Continue reading