We are especially happy to say we are part of the independent track, which is organized by NY Hacker and we are going to be in some awe-inspiring and jaw-droppingly good company with fellow presenters: Nodejitsu, Hyperpublic, Aviary, Etsy and Hunch!

Paul and I are looking forward to meeting you at the event; we are psyched to see what your new eyes and fresh perspective will bring to our 93,000 collection records available through the API. To get started, apply for an API key and we’ll see you at the event!

Art Collections iPad App is now available for free download in the Apple App Store.

The app uses our API and we’re pretty happy to see a developer pick up our data and run with it in this way.  You may remember the earlier issues we had with app store confusion that resulted in changes to our API’s Terms of Use.  Wayne’s app reflects those changes nicely—in its branding, it’s very clear that Art Collections is coming from outside the instituion and that leaves us plenty of room later down the line to create our own solution without confusing users.

Wayne’s got a nice Q&A up on his own website about the app and has been blogging about the process of coding it.  I also asked him a few additional things as well…

Tell us about the app you’ve created.

Browsing the collection.

Our application, named Art Collections, is a free app that allows users to browse art, photographs, antiques and other content from the museum.  The application provides access to over 25,000 pieces and was built specifically for the iPad (and iPad 2) because the large touchscreen allows users to scan, zoom, and touch the art.  The app is available in the iTunes App Store.

How did you hear about the Brooklyn Museum API?

We heard about the Brooklyn Museum API through the Creative Commons (cc) website.  We were really impressed with the level of sophistication put into the model, as it closely mimics an API one would normally associate with a technology company like Google or Amazon.  When building an app using someone else’s data, one needs to have confidence not only in the data, but with other components like performance, documentation and support.  We’ve been really happy with the end product and our decision to use the API.

If there’s one thing you’d really like to do in version 2, what would it be?

Looking at an object in detail using the Art Collections App.

An important goal for the project has been to experience the richness of art in a casual setting. Now that the foundation is place, we see being able to put the app in slideshow mode as the next major feature.  It would allow for casual discovery of new favorites.

Results from the App Store when searching "Brooklyn Museum." The two apps are not distinct enough and confusion ensues.

We are pretty thrilled that our API has been used to create such a public-facing use and hope that this innovation continues, but we also needed to make some changes to our API terms to help eliminate possible confusion in the App Store.  These changes are especially important now because we’ve seen other developers requesting keys to create their own apps with our content, so it’s likely that we’ll eventually have even more choice in the App Store for our visitors.

Interestingly, this tweet came up just as we were making the API changes.

Recent changes to our API terms now state our name, likeness and logo can’t be used without prior permission and there are a few other app-specific disclaimers that we require such as ensuring apps developed with our content are distributed free and without any in-app advertising.  It should be noted that even though this wasn’t explicitly stated in the terms prior, every developer that has worked with our API and wanted to use our logo has specifically asked our permission and, in the case of Brooklyn Museum Mobile Collection, Adam had conscientiously worked with us to both name and brand the app in a way that worked for all of us.  However, now that time has passed and there are more apps in the store and, likely, more apps on the way – we are making a formal change.

So, what now?  These changes will help us moving forward, but what do we do about the two existing apps in the store?  We’ve been talking with Adam and are privileged that he’s been so open to the problems we’ve been experiencing and open to making adjustments.  As it turns out, he’s been working on a new and improved version of the app that will contain both new features and fix crashing in iOS4.  In addition, he’s moved from Iconoclash to Caravan Interactive and was looking for a way to move the app from his old company account to the new one, which we hear from Apple can’t be done.   Given all of this, it seemed like the best answer was to pull the existing Brooklyn Museum Mobile Collection from the store under Iconoclash and release the new and improved version with different branding under Caravan in the coming months.

If you’ve already downloaded the Brooklyn Museum iPhone app (link opens iTunes), you may have noticed an update (or two) for it in the app store.  We are psyched to mention that version 1.3 was just released and has fixes for many of the issues you mentioned via the blog and twitter, as well as some new slickness.  At this point, we hope you will download the new version and help test it out.  We’d adore it if everyone would do it all at once, so we can test our server load : ) The last time we went through this, it was popular enough to crash our server and while we think that’s pretty cool, we’ve made some changes to help fix those issues and would like to test our improvements. Here’s what’s new:

• Images that are displayed small due to copyright protection are no longer pixelated—the app now respects the size of the images distributed via the API, so they will still be small, but fuzzy no more!
• In the randomize feature, objects that do not have images are suppressed, so you’ll always be able to browse at random now without “image cannot be found” interruption.
• The app is now respecting the object’s primary image via the API, so no more strange side or rear views popping up when there’s a better one to display.
• Some of the navigation buttons have been renamed to be more clear.
• Many of the reported crashes have been fixed.  A good deal of the crashing was due to some server-side stability issues on the Brooklyn Museum side, but other crashes were due to coding in the app itself.  It took us a while to narrow everything down and figure out who was responsible for what aspects, but we think we’ve made a lot of progress and now we need to launch for extensive testing.
• Adam is doing a lot of caching, so the app is a bit zippier.

As with every technology project that we talk about on the blog, we try and present a well-rounded account of the process, so with the good there are always challenges and here are some of those issues:

Letting Go: When we released the API, we talked a lot about letting go of data.  Truth is, that was a lot more difficult than I personally ever thought possible.  There’s so much we do internally with our collection online to make things very clear for viewers.  Simple stuff with big impact… like highlighting search terms so visitors can see why their search results returned the way they did … or making it ultra clear when works are on view and when they are not.  All these issues were carefully thought out on our side and while that data is often available via the API, we can’t control how another developer work with those options.  With all instances of the API use, we are seeing a lot of these issues surface.

Mission:  Everything the Technology department spends time on relates to our mission and the goals of the institution.  In the case of an iPhone app, we have to question the idea of an app that can only be used on one platform (iPhone) and that, perhaps, this is not as on-mission as we’d like due to accessibility issues.  This can be a good thing—something that we’d never set aside time for internally can be accomplished via the API by an outside developer (yay!), but we have to consider that in a high-profile project such as this one, the institution is represented and, going back to those letting go issues, that is something that we have been grappling with. We are going to talk a bit more on this soon.

Limitations and Purpose:  With the iPhone app specifically, we’ve run up against the limitations of the API.  The entire application uses the API and nothing else and there’s only so far it can go with features at this point without branching from the API.   As constructed (especially with the new update), this is great app for browsing the collection, but we have to consider…does it work in the gallery?  Personally, I love the tool when I’m not in the gallery, but when I’m in the gallery I want something else entirely and that’s something else we are going to be talking about soon.

Priorities: Much like our own situation here with a small staff and many competing projects, there are priorities.  In this instance, we’ve got an awesome volunteer developer who’s dedicated an amazing amount of time to create this app, but we have to acknowledge that his time is limited.  This came up with the latest round of fixes and feature requests. It was difficult to make fix lists recognizing how much time they would take and knowing that the person doing them doesn’t actually work here, but also knowing that the app does represent the institution even indirectly—our app has a 2 1/2 star rating in the iTunes store based on 38 ratings.  I have to thank Adam for being such a trooper at this point—for trudging through the fixes and being open to all the issues that we’ve been grappling with.

All that said, we are going one more step today and Adam is open-sourcing the project.  Due to the nature of how the app store and its process works, we will be working out logistics as we go along.  While there are some open source iPhone apps out there, it’s not the norm and we expect this will have to be a coordinated effort so we don’t have different versions of the app running around.  We are looking forward to this next step in the lifecycle of our app and will report back on what we learn.

As you install the latest version, we’d love your feedback and your input—if you are a developer who’d like to help us with the project, we’d love to hear from you.

This is a rare weekend blog post from us, but we found out that Brooklyn Museum iPhone app hit iTunes and, well, we just can’t contain ourselves—yay!

If you read this blog, you may remember this app is a product of a real-world use of our newly released API by developer Adam Shackelford at Iconoclash Media.  The creation of the app was announced on our blog about a month ago and as Adam was shepherding it through the app store approval process, I’ve been keeping in touch and hearing stories about Apple’s pretty thorough rounds of testing.  As Adam mentioned at one point, “It never occurred to me, for example, how the app would function if the phone were in airplane mode.”

That said, version 1.0 is in the store for free download now and we are already starting to see the feedback roll in via Twitter and the app store rating system:

So, we’ve seen some early responses and Adam is graciously asking for feedback.  We are grateful to him for his hard work on this app and it amazes me how he and others are using our API to show off our data in innovative ways, all on their own time!

Leave comments here and we will be checking in.

We couldn’t have been more thrilled when Adam contacted us to say he was working on this.  It’s the kind of thing we couldn’t do with our existing workload and quickly realized the API was allowing us to do more by collaborating with the developer community.   Before you run off to the app store for this free download, we’ll mention it’s a few weeks off from being listed.  Adam came over for a site visit to show us his just-finished version 1.0 before he submits it to Apple for inclusion in the store.  We’ll be sure to blog when the app is ready, but in the meantime we wanted to share this Q&A, so you can meet Adam.

This will be the first in an ongoing series of Q&As with developers using the Brooklyn Museum API.  If you are curious about our own internal process to create the API, check out the interview Paul and I did for Mike Ellis on his blog. Additionally, you can chart developer progress in our new Application Gallery and find out about our latest additions in the News section (note, there’s an RSS feed to keep you up-to-date).

Site visit!  Paul Beaudoin (left) and Mike Dillon (center) check out Adam Shackelford’s (right) iPhone app version 1.0.

How did you hear about the Brooklyn Museum API?

One of my friends is increasingly involved in museum 2.0 (or 3.0?) emergence, and given the adoption of mobile technology in museums, we often talk about the intersection of our fields. She pointed out the API to me one day, and I thought to myself that someone surely was working on an iPhone application already. As it turned out, no one was, and so I built the app with the time I could find over the course of the last couple weeks.

Tell us about the app you’ve created, thought process behind it, etc?

In my mind, there are few things that inspire people to learn like museums and the web do. They seem like natural companions, and yet often this is not the case. Then along comes the iPhone, which has thus far created countless geeks out of otherwise normal people. Once I saw what the API allowed, it seemed like an opportunity to create something that people would enjoy. The key to invention in this field is to build things that people don’t realize they will use. I have only found one other museum application in the App Store, and it was something like 400 megabytes of space, composed of static elements, so we wanted to do something different. The app is entirely driven by the API, so it is always updated with museum content, and you are always connected to the museum in a very concrete way that was not technically possible before, and isn’t possible yet with any other museum in the world.

If there’s one thing you’d really like to do in version 2, what would it be?

Version 1.0 is being submitted to Apple very soon, and it is really only a foundation of everything we want to do with the application. Because all the content is pulled from the API, it is a very lightweight app that will be convenient for users to update. When the iPhone 3.0 OS goes public in June, we are planning a much more exciting geotagging experience, because the built-in mapping is making a great leap forward. Also we are interested in allowing users to tag items in the collection, expand the browsing options, etc. The main point I want to emphasize is that this is only the beginning, and we are planning to expand the application as the API evolves.

You mentioned this app was designed to scale, so that if other institutions release an API (hint, hint) you can grow the app. Tell us a bit about that?

Version 1.0 is largely just a demonstration. I could spend months refining it before its initial release, but as I said it is a very light app that can be easily updated, and the architecture is designed so that we can add or take away as needed for this or any comparable application. Indeed, we are hoping that this serves as a proof of concept and encourages other institutions to open up their collection to developers and thus the public. I also think that the iPhone can play a bigger role when people are actually visiting the museum, and I have some more elaborate ideas to develop someday. We are of course also interested in being hired by museums to assist with this.

We see from your website that you run an interactive media firm based in Brooklyn (!) – tell us a bit about your background and your company.

The company was started in January 2009 by myself and Katy Walker, our creative director, and Angela Chumley, our chief of operations and information architect. All three of us have worked primarily in advertising and corporate design firms, but agreed that it was time for a big change. We are all creative and passionate about our work, and bring diverse skills to the table, and a healthy amount of conflict and disagreement as well. We started Iconoclash Media because while we do enjoy making other peoples’ visions become reality, we also have our own ideas which we pursue together. The museum app is one example, but we divide our time between contracted client work and the development of original applications and have found that each aspect of our business influences the other.

So, you live in Brooklyn and have probably been to the Museum a few times…. Any favorite exhibitions, objects or events that come to mind?

I marvel at the geometric ingenuity of Islamic textiles, text, and ceramics, and Brooklyn Museum has a good amount of these. I’m also very interested in Japanese art, but I’m going to stop myself here before I list everything at the museum. One feature we built in the app is the ability to browse items totally at random, so I’ve been spending some time cycling through the 20,000+ items in the API, but many of those I have not yet seen in person. And there’s still no substitute for actually going to the museum.

What is an API? Well…you can look at Wikipedia for a super-techy explanation of this, but for those of you who are not geeks a short translation: it’s basically a way outside programmers can query our Collections data and create their own applications using it.

Mike Ellis presenting in Amsterdam…this guy can really convince you if you give him a chance.

So, how did we get here? Recently, I was presenting at a conference in Amsterdam along with Nina Simon and Mike Ellis. Mike’s highly entertaining presentation was about encouraging the public sector to consider releasing their data so that the community of developers worldwide could take advantage and create wonderful things with it. In Mike’s own words “if you love something, set it free” and that idea was something that resonated with me. Mike is a practical guy and he talked a lot about the stresses of staffing at cultural organizations, that we can’t possibly do it all ourselves and he wanted to spread the news of the potential in allowing outside developers the chance to add their own talent and wealth to our data.

This presentation of Mike’s stayed with me as we’ve watched many developers in the Flickr community work with the materials at the Flickr Commons. Flickr’s API is very flexible and several very talented programmers are taking advantage of the materials at The Commons and doing interesting things with them. It’s been inspiring to watch and given that we are an institution with a community-minded mission, we recogonize that developers are a significant part of community on the web and one we’d like to work with moving forward.

So, you may be wondering what kinds of applications could benefit from our data. There’s a wonderful X factor to all this—that we just don’t know what interesting something that someone will come up with—so it is exciting to wait and see. One thing we do know is people within our own industry have been working to create various pan-institution collection databases. By releasing our API, Brooklyn Museum data can now be included in these endeavors without requiring more staff time from us (something that would have been impossible prior to the API). The API offers us a way to share our data in a very democratic way—the work we do on the API can benefit all developers working with our collection online—not just major projects coming out of the non-profit sector.  Frankie Roberto: next time you are building something in your garage, please remember to get your Brooklyn Museum API Key and include us in the fun.

It should be said, that in looking for examples to guide us in the non-profit world, we didn’t find many, but there was one shining beacon of light coming from New Zealand. The National Library of New Zealand released an API recently (fabulous interview here) and we carefully looked at what they were doing, how they structured the Terms of Use. This was a terrific example to follow and we couldn’t have been happier to have it to consider as we moved forward with our own.

Tourist with ‘roo at the Taronga Zoo in Sydney!

Now, there’s a little bit of irony in all of this. Seb Chan at the Powerhouse Museum in Sydney has been asking me for three years to provide Brooklyn Museum data, so it could be integrated into D*Hub (awesome site run by the Powerhouse where designers can search many collections at once). For years I’ve been saying that getting the collection online was a higher priority—that we just couldn’t devote staff time to providing a data set for a specific project like this one. I think after three years, Seb got so darn tired of us putting him off that he just stopped asking, but as I write this, I’m in Australia and New Zealand for speaking engagements in both countries. Seb, I’m here to tell you come get that API key so we can finally do this and Courtney, I’ll be coming to thank you and your awesome forward-thinking team in person.