- bloggers@brooklynmuseum - https://www.brooklynmuseum.org/community/blogosphere -
Brooklyn Museum iPhone App ver 1.3 released + API Lessons Learned + Going Open Source
Posted By Shelley Bernstein On July 28, 2009 @ 11:04 am In Technology | 9 Comments
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:
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 .
Article printed from bloggers@brooklynmuseum: https://www.brooklynmuseum.org/community/blogosphere
URL to article: https://www.brooklynmuseum.org/community/blogosphere/2009/07/28/brooklyn-museum-iphone-app-ver-13-released-api-lessons-learned-going-open-source/
URLs in this post:
 Brooklyn Museum iPhone app: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=313392398&mt=8
 talked a lot about letting go of data: http://electronicmuseum.org.uk/2009/04/16/the-brooklyn-museum-api-qa-with-shelley-bernstein-and-paul-beaudoin/
 highlighting search terms: http://www.brooklynmuseum.org/opencollection/search/?q=dog&search_scope=all
 ultra clear when works are on view and when they are not: http://www.brooklynmuseum.org/opencollection/objects/1124/Girl_with_Dog/set/search?referring-q=dog
 all instances of the API use: http://www.brooklynmuseum.org/opencollection/api/docs/application_gallery
 mission: http://www.brooklynmuseum.org/about/mission.php
 API: http://www.brooklynmuseum.org/opencollection/api/
 awesome volunteer developer: http://www.brooklynmuseum.org/community/blogosphere/bloggers/2009/04/17/brooklyn-museum-api-the-iphone-app/
 open-sourcing the project: http://code.google.com/p/brooklynmuseummobilecollection/
 open source iPhone apps: http://opensourceiphonesoftware.com/
 love to hear from you: mailto:firstname.lastname@example.org
Copyright © 2010 bloggers@brooklynmuseum. All rights reserved.