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.

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

Thanks to publisher Tor’s generosity at ALA 2010 last month I have a copy of the book in hardcover. And thanks to Doctorow’s business model of giving away free ebook versions of his works I had the text in e format too. This is the first time I’ve read a book while having access to both e and print versions at the same time.

As much as I enjoy my Sony Reader, a print book is still my personal ideal for most of the novel reading I do. I use the Sony primarily for convenience, like when I don’t want to carry a large hardcover on the bus. But if I’m sitting on the couch I still prefer a standard print book experience. With access to both print and e versions I was able to jump back and forth between the two, using whichever provided a superior experience at the moment.

And actually I had 3 options – Hardcover, Sony Reader, and the Aldiko ebook reader app on my phone. (Doctorow provides his ebooks in a variety of DRM-free formats compatible with a large number of devices.) I read the hardcover on the couch, the Sony on the bus, and a few pages here and there on the phone whenever I had some waiting in line time. It was convenient, easy, and I got through the book much faster than I would have otherwise.

But now I’m spoiled! Doctorow’s ebook give-away model is pretty unique, not many other authors do it. I’m not going to buy a book in both print and e, and library ebook options are pretty anemic. The only way this would happen again is if I pull titles from Project Gutenberg. But I’m not much of a classics reader, and Gutenberg doesn’t have a lot from my to-read list.

While I don’t think it’ll ever happen, I’d love for a purchase of a print copy to come with a free ebook counterpart. I’d even pay a little extra for the option, and the bonus to researchers of having a searchable text to supplement the print could be a considerable advantage.

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

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.

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:

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.

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:

Install RMaps on your Android phone. RMaps is a free android app which has the capability to read maps from a file instead of loading them over the web.

Next, we generate the maps to store. This is done on a PC, with a program called Mobile Atlas Creator. There’s tons of different versions of this program scattered over the web. It took me a while to track down one configured for what I needed. Here it is. Download and unzip the file called “Mobile_Atlas_Creator_1.7_SQLite.zip”. Open Mobile Atlas Creator.

Now, set the options for your map. I’ve annotated a screenshot with numbers pointing out where all these settings are. Click it for a bigger version.

• Pick a map source from the drop-down (1). I used Google Maps.
• Check off the zoom levels you want your map to have (2). 19 is the most zoomed in, and 0 is the most zoomed out. The more zoom levels you include, the larger a file size your map will be. 19 and 18 in particular are gigantic. I included all 20 in my map of Paris, which for an area this size results in about a 205mb map.
• Click the Clear button (3).
• Give your map a name in the Name box (4).
• In the big window on the right, click and drag a box around the area you want your map to include (5). Obviously, the more area you include the larger the resulting file will be.
• Click the Add Selection button (6).
• From the Format dropdown (7), pick BigPlanet SQLite.
• Click Create Atlas (8).

Now the map will be downloaded and packaged for reading by RMaps. Depending on your web connection, this process can take a very long time. So walk away and get a snack or something. I made a map for each of the 3 cities we visited, and my maps ranged from 80mb to 220mb.

If all’s gone well, now you have a map file! Connect your phone to the computer via USB, and browse to the phone’s rmaps/maps folder. Put your map file there.

Disconnect your phone. Open RMaps. Press the Menu button and pick Maps. Now you should see the map you made as an option. Pick it, and you’ll see your map! This map will work anywhere, with or without a cell connection! And with GPS enabled, it’ll even show where you are on the map.

RMaps has one major limitation: Maps aren’t searchable. You can’t get point to point directions. But it was still far far better than nothing, and a quick ‘where are we’ check saved us from being lost a handful of times. Definitely worth the advance time to set up!

I consider this feature to be pretty experimental, so I’d love any feedback on how well it works and whether I’ve explained what it does well.

Note that this isn’t a feature you have to use. If you want, you can keep using the generator and pretend it doesn’t exist. I also recommend not using it more than once in your generated mobile site – pulling in multiple RSS feeds can slow down the page dramatically. I hope to build in some ways around this problem in the future.

I’ve been thrilled to see the response to the generator! I’m glad that people are finding it useful. If you’ve launched a site and used the generator at some point along the way, please let me know about it. I’d love to build a practical showcase of what this thing can do.

Today’s slides, on slideshare:

(A couple of images got scrambled in the process of uploading to SlideShare, but all the content is intact)

First, while there’s many other available frameworks than just the two I talk about, I do want to specifically point out the MIT Mobile Web project. The folks over at NCSU have done a great job implementing it with their library’s mobile site. They’re talking about it in a session right after mine, so I won’t be covering it in too much detail. MIT’s code is fairly robust, but also much more complex to get set up and running than iUI or Jason Clark’s work.

Second, some interesting stats. From two separate reports, both with data about December 2009. Looking at them side by side:

-Apple has 25.9% of the US smartphone market share (in devices sold), but iPhones also make up 54% of US mobile web traffic.

-Android has just 5.2% of the US smartphone market share (in devices sold), but makes up 27% of US mobile web traffic.

-Blackberries have an astonishing 41.6% of the US smartphone market share (in devices sold), but make up just 10% of US mobile web traffic.

There’s an important lesson here to keep in mind when choosing which devices to support with a mobile website. At first glance, looking at Blackberries’ market share alone, they seem to be the platform to support – it’ll get the most users in, right? Not when they use just 10% of all mobile web traffic! The heaviest users, the people we should be targeting now with our services, are on Android and iPhone. By supporting their combined 31.1% market share of devices with our our mobile sites, we’re available for 81% of mobile web traffic. That’s a pretty solid return on investment. I’m not surprised by these results, but it’s always nice to have numbers to back up intuition.

This isn’t to say that blackberries should be ignored – they’re just not the best target audience for a pilot program.