Build Online Research Community for Northwest Coast Collections
•
2 gefällt mir•1,235 views
The document discusses building an online research community called the Regional Records Network Pilot Project that allows users to search Northwest Coast collections from multiple institutions in a single place. It describes getting started by developing a basic tool and gaining early users. Key steps involved gaining users' trust by letting them search in their own way, addressing partners' concerns about time commitments and data control, and showing value by enhancing data and connecting with communities. The project aims to soon enable a public interface, add new partners, and officially open in June at its website www.rrnpilot.org.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Build Online Research Community for Northwest Coast Collections
Ähnlich wie Build Online Research Community for Northwest Coast Collections (20)
Mehr von museums and the web
Mehr von museums and the web (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Build Online Research Community for Northwest Coast Collections
- 1. Getting There: Building an Online Research Community Nicholas Jakobsen and Ryan Wallace
- 2. Getting Where? Build an online research tool Facilitate collaborative research Single place to search the Northwest Coast collections of multiple institutions
- 5. Getting Started Users don’t know what they want until they see it Get something up and get people using it
- 7. Getting Users Developing trust Letting user do it their way, don’t try to teach them your way
- 8. Getting Content Addressing Concerns Time Commitments Demonstrating Support Control of Data
- 9. Getting Content Showing Value Enhancing data Connecting with Communities
- 10. Getting Feedback Embedding Developers in the Museum Working with busy people Managing Expectations
- 11. Where to now? Enabling Public interface Soon ready to add new partners Official Opening in June
Hinweis der Redaktion
- Well, I’m happy to see that there are actually people in the audience. I thought being the last session on the last day I’d see tumbleweeds rolling through the room as I presented. So let’s get started while everyone has a bit of energy left. I’m Ryan and this is Nick and we work on a multi-institutional project called the Reciprocal Research Network as the designers and developers. I’ll introduce the project briefly but what we’re intending to focus on today is how we addressed some of the roadblocks we faced in creating a usable, content-rich tool.
- So let me start by quickly describing what the RRN is and more importantly why we built it. The RRN is a multi-institutional collections search tool focused on First Nations’ objects from the Northwest Coast of North America. The basic premise is to bring together First Nations objects from many different museum collections into a single web portal. By creating a central location for these objects and also by providing simple collaborative tools with configurable privacy settings, we hoped to create a contact zone where First Nations’ researchers, institutions and academic researchers could collaborate and enhance the knowledge of the objects within both the museum and First Nations communities.
- The RRN was co-developed by the Museum of Anthropology at the University of British Columbia and four First Nations Communities. The project was managed by a steering committee made up of one representative from each co-developer which oversaw the direction of the project.
- The RRN is currently working with 15 Partner Institutions located in Canada (9), the USA (4), and the UK (2) that are providing feeds of objects from their Northwest Coast collections to the RRN.
- So now that you know a little bit about what the RRN is, we can start to talk process. When Nick and I started on the project in 2007 it was still an idea. The Partner Institutions had signed the grant application in 2001 and the channels of communication hadn’t been kept open since then. We felt that we needed to build something tangible as soon as possible to show the stakeholders the project was moving forward. We adopted an approach similar to the approach used by the V&A. Small iterations that were shown to a varied group of users (first nations community members, researchers, museum staff). These demos were basically sanity checks. The demos gave us a talking point to start off with when talking about what users wanted. We wanted to know if people would be interested/excited to see what we had built developed into something more. We tried not to worry too much about the perfect solution.Don’t plan entire project before building anything.Started with a simple “tech demo”Showed to a varied group of users (first nations community members, researchers, museum staff) 2 months into project.This was our sanity check. Would people be interested / excited to see this developed into something moreImmediately after, the site was up on the web, and development was essentially “live”-Not worried about perfect solution-we didn’t spend time worrying about how to do something well, until we had found that it’s actually something that people wanted to do (if asked, talk about tags -> labels)-seen some companies take this method to the extreme-we heard story (tell story about accepting credit card info, and then having to say oops, there was an error)
- After we had done a couple of these sanity check-type demos, there were three fairly obvious things we needed to continue iterating successfully. If we wanted real users to generate real feedback, we had to give them real data to work with. Fortunately for us that MOA didn’t have their collections online and the staff was in the middle of a large museum renovation, so providing even rudimentary tools for them to use outside of the museum was better than what they had. We had something small and simple up online 3 months after the project started. Initially, this allowed us to tap into that captive audience that we had at MOA as an initial user base, and also have something for community members to continue to try and give feedback on after our demos had concluded.
- When you have multiple institutions data being combined together, no one is an expert in what is in the database. This makes not hiding objects behind a search box even more important. At the same time though, we wanted power users to be able to execute fairly complex searches easily. I’ll show you the find interface briefly. So you can see that our approach is similar to Arts Connected and a number of other projects these days in that we start with all of the objects and layer a couple of faceted searching mechanisms on top. Firstly, we created a very visual search interface for times when you are truly exploring and even auto completion is too constraining since you don’t really know what you want. We use the data that is fed in from the institutions to create tag clouds of all the available options. So let’s see what types of items the RRN has. Looks like we have lots of adzes, some amulets, a couple of anklets. Let’s find some masks. All of the items have been constrained to the set of masks, without needing to type anything in. You can see that the manufacturing techniques have also been constrained to just the ones that masks are made using. This makes it less likely that a user will hit a dead end. One of the interesting things that the RRN does that we can see now though is that the free text search box is actually facet aware. This means that, similar to how gmail search works, we could achieve the same search by typing item type: mask into the search box. Or we could further constrain the search by adding culture: Haida or Kwakwakwakw. Because the search box is facet aware we can actually make the autocomplete fairly intelligent. When I type in seaweed, it suggests I might want to look for things made of seaweed or things made by a person named Willie Seaweed. And if I type reid, it will suggest all the members of the Reid family. One of the nice things about the facets and the results being tied together is that you can actually use the facets in a slightly different way to get interesting information about your search. Now that I’m searching for all items associated with Bill Reid, I can learn a lot about these items just by looking at the facets. What types of items does Bill make? What materials does he use? Which institutions hold his items? When did he make them? In addition to this sort of transparency, we felt that another important aspect in terms of building trust was the social aspect of the site. Though we provide a help section, people also began help each other via the forum system that we had provided. Related to this, one of the things we’re thinking of trying, and I’d be interested to know how it went if anyone has tried this, we’d like to leverage our community by providing an option to crowd-source your search that came up empty for suggestions in addition to suggesting spelling corrections. Anyway, though we’d like to continue to grow and diversify our user base, getting users actually proved to be easier for us than getting content, but I’ll let Nick talk about those challenges.
- To get content, we needed to work with content providersPartner Institutions are the major source of content, so we needed them onboardBiggest surprise to us was that we had to convince them to participateAddress their concernsTime commitmentsMinimizing Burdens on Museum IT Staff – (give us ANYTHING)Demonstrating supportBC First Nations support by BC Indian Chiefs ResolutionSigning a Memorandum of Understanding – didn’t have legal bindingControl of DataIt’s okay to have ‘messy data’ - Promoting the Research AspectAddressing the Fear of Data NormalizationInstitutions Retaining Control of their DataShow data tab and source data tab
- Also need to show institutions what’s in it for themEnhancing DataRRN provides a fresh look at information that has been hidden in databases for decadesVery easy to spot Anomalies and AmbiguitiesConnecting with communitiesPresentations by Community Liaisonsshowed that real people in communities were positively affectedProviding Pathways for Feedback (User Submissions)building new partnerships through communication (musqueam now will be in contact with MAA to discuss proper protocol regarding culturally sensitive rattle)
- Explain that the development happened physically in-house Can watch how people work, and how people use the software Show MOA coast salish collection used to make the physical presentation in the MOA galleryBusy people Working with so many partners has its challenges Keeping people informed of changes, and getting feedback was difficult over teleconferencing Best way we found was to digest details for them in emails with Screenshots and ExplanationsManaging Expectations Because of proximity to actual users (our boss, coworkers on project, etc.) there was pressure to create tools to accomplish their specific tasks Often we were asked, I need a button to do X Need to ask: why do you need this can it be accomplished using existing features is this a valuable feature to enough users