Community: bloggers@brooklynmuseum

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.