Community: bloggers@brooklynmuseum

Ever wish you could remix the gallery experience?  When I walk into a museum I enjoy the structure—the information given, which objects have been placed where, the specific sequence in which the space has been designed—but I will admit, there are times when I want something else too….something that’s a bit off the charts and possibly something that is always subject to change.  I’m positive this other need has something to do with all those Choose Your Own Adventure books I was hooked on as a kid.

Today, we are launching BklynMuse, a gallery guide that is designed to complement the more structured museum experience.  In its most basic form, it’s a community-powered recommendation system for the objects that are on display here.  As visitors move through the galleries, they can recommend objects to other visitors.  Based on the  recommendations you give it, this muse will crunch the collective data and present other suggestions for you as you move from room to room.  The guide does other stuff too—it gives access to our cell-phone audio stops, our YouTube videos—but the real power in the device comes from visitors sharing their own takes in our galleries.

This is one of a series of things we are implementing to bridge both the online experience with the in-person visit.  In the case of BklynMuse, Posse members get their recommendations saved to their profiles for future reference—think of it as bookmarking your favs on the go in the gallery and then being able to access them later.  Even more than that, Posse members can create sets of objects on our website and annotate them and, if you choose to sign into your Posse account on BklynMuse, your sets will be right there waiting for you to follow in the gallery.  Those same sets can be shared and featured for other visitors to see, so your voice…your notes…your selections…may be highlighted, in all their Posse glory, for all to see.

For those of you reading the blog, you know I’ve been on a bit of a failure kick lately—cautious observations of visitors glued to screens and kiosks that drive me slightly bonkers—you may be wondering how this could possibly be different.   We designed this interface as more like a scavenger hunt than a multimedia guide.  It’s something that can guide you to objects and something you can use to help guide others, but it’s not meant to replicate the actual experience of really looking at the work, so I’m hoping this reduces the screen glue. As with everything, only time will really tell the outcome, but it’s worth a try.

In areas like The Dinner Party and Luce Visible Storage, suddenly you have a whole kiosk’s worth of information at your fingertips…right there in the space when you need, it in an unobtrusive way.

There’s even more after the jump if you are curious. (more…)

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.

If anyone needed convincing that an API might be a good idea, this news might just do it for you.  A few weeks ago, we approved an API key for Adam Shackelford, a Brooklyn-based developer, to create an iPhone app.

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.