 Hello, everyone. Everyone awake? The second session after lunch, yay. OK, we'll make this really exciting. My name's Leith from Palmer's North Library. I'm going to be talking to you about the needs analysis that we went through to get from our old digital library to our new heritage archive. After that, Glenn is going to talk about the how and the why of the build. And there'll be some interesting technical stuff and diagrams and things. And then Heather will excite you all with a deaf-defying live demonstration of the new site. It's going to be great. OK. So this is our trusty old Patakea Parangi launched in 2008. I think that was a year after the iPhone came out. It was kind of almost pre-mobile, pre-cloud days. And it really shows it's not interoperable, not indexable. Search engines couldn't index it at all. Not linkable. It had session-based URLs. And it was not easily harvestable as our friends from Digital New Zealand will know. And as Heather knows, because of all the unpublished content that was ending up being published on Digital New Zealand as a result. It wasn't able to show content adequately at all. Multi-page items, panoramas, video just really looked horrible. So this is a beautiful panorama that you can see up there. That's what we could show. Heather will show you what it looks like now on the new system. So the content itself is very well digitized, very well described, good metadata, but it just wasn't being shown very adequately on the old system. As for sharing and reusing content, well, just don't go there. That just doesn't seem to have been a thing in 2008. It wasn't mobile, frankly. This is kind of what it looked like. And you really couldn't facilitate community content, the uploading or creation of content. It wasn't interactive, not very engaging, not very usable. And by usable we mean not easy to use, not easy to learn how to use, and not easy to remember how to use it once you've learned the first time. And so the new system that you'll see when Glenn and Heather talk is really the kind of first year of development. It was launched in June. There are another two years of development to come. So you're seeing this sort of basic version, and we're currently ironing out some small things and adding more functionality. There's tons more exciting stuff to come. So the needs analysis took us two years to complete. You might think, well, that's inordinately slow. Well, we were waiting for funding, so we had two years. And so normally when you're buying a new system or building a new website or heritage repository, you might say what systems are out there and what can they do for us? Which ones can we afford? Which ones shall we go for? And instead we decided to ask a more important question, which is really why are we doing this in the first place? What's the point of doing this? What impact do we want to have? How do we want to best serve our community? And so in the needs analysis, we did tons of things. One of them was analyzing the current usage to see what users were making. We also mapped stakeholders. I don't know if you've ever done a stakeholder map. That's quite an interesting thing to do. So the idea is you list all your stakeholders. We had hundreds of them. And then you group them. You plot them on this chart depending on how much influence they have over your development and over the content that goes in it and how much interest they have in the system itself, in its development and in the content. And so some stakeholders, for example politicians and senior managers, have a huge amount of influence, but not that much interest in... They don't really love this thing in the way that you do. And some, maybe some of your content users or local historians maybe absolutely love what you do, but they don't have much influence over it. And then some, in our case, we found that our content creators really had no influence and they actually had no interest because the system didn't allow them to do anything. And then a lot of others ended up somewhere in the middle. Now where it gets really useful is if you pick one of your stakeholder groups, you can decide where you want them to be in the future and we decided that those content creators needed to move to there. And so that was just a useful tool that helped us in making decisions about what it was we wanted to achieve. We did surveys and focus groups. You can all read what the most important things were that they told us they wanted, but you'll see it's all about interaction. It's about active involvement and creating and curating content. And so we took that very seriously. We also spoke to Glam experts, perhaps some of you are here. You'll remember it was a very long interview. And again, it's about reusing content. That's the important thing. Having really simple ways to find and interact with content and, of course, effective tools for staff to manage the content. We also forced ourselves to make some tough choices. In an ideal world, you would have a system that is both incredibly usable and very accurate. For example, your search interface. Very easy to use and delivers incredible accuracy of search results. We knew that only happens in the ideal world. In the real world, you have to choose because those two usually pull against each other. Same with simplicity and functionality. Do we want a simple and functional site? Forget it. You have to choose which way you're going to go. With collaboration and control, open access and strict legal compliance. And so as a team, we kind of pitched it there and we decided that what would serve our community best would be a usable, simple system that would allow lots of collaboration and open access. And so that, all of these processes we went through in the needs analysis enabled us to explain to potential vendors and developers what was really most important to us. And so we knew that we wanted it to be really fast. Super fast. The experience should be instantaneous. We also wanted it to be incredibly reliable. A bit like those knee gaiters that you see there. It would never let you down and never break down on you and just always keep on working. It needed to be incredibly simple in its design. It should do a few things incredibly well rather than have bucket loads of functionality that get in the way of each other and that perhaps interfere with each other. It had to be mobile from the ground up. It had to be built with mobile in mind first. Not something that's tacked on to the end of your desktop user experience. And it also needed to be interoperable and talk with lots of other systems. And so that enabled us to refine all of our expectations and explain to vendors and developers what it was that we wanted. Instead of sending them a list of pages and pages of functional requirements which were just confused matters. And so we had three excellent responses to our RFP. We really could have gone with any of them but we chose to take the riskiest of those options. And so we chose to build from scratch. But we went with a developer with the right values and vision and track record and crucially a developer who really understood what it was we wanted to achieve. And that was Glenn. And so Glenn is going to tell you now about how and why he built it the way he did. So let's get on with the how and the why of the actual build and implementation. And like C.M. Ross, how do we guarantee satisfaction? Firstly, it's good to see what we had to work with when the RFP landed. The RFP was great and the core part of the RFP was a list of fairly well described features and wishlist items. And this allowed us to interpret the requirements and write a concise response to each one. I can't stress enough how much a well written RFP can benefit both the vendor and the clients. It also allowed us to get a really good handle on whether we could or even wanted to build what the library wanted. We thought this was key. We were going to spend a significant amount of time in responding to the RFP and a significant amount of time building the solution. And this platform was something we had been thinking about for a long time and we wanted to make sure there was a good fit. And we kind of wanted to make sure we could build a long term relationship with the library and we wanted to make sure that the values, we had some shared values and our values were aligned. And just to be clear, it wasn't all about us but more how we could really add value to the library's mission. So I think it's good to go over, we started thinking about what are our philosophies as sort of a company and what we do. Our philosophies were to start simple, minimal viable product and I'll just slide on there in a second to dive into a little bit more. MVP means kind of de-scoping for quality so leaving stuff out so you can build a few things really, really well. What really lies behind the specs that have been given to us. So that means starting with a clean, simple design and that's hard to get right. It's easy to add a checkbox, it's really hard to take one away. So we're starting simple and adding more later based on user feedback and what we thought we wanted to build in the future. And then we had some more sort of platform-based concepts that we've been thinking about. At Accor it's just an object store. It isn't a website. It's a platform to deliver services where needed. And storage is not a limitation. It's 2016. We can scale to millions of records and terabytes of information so a 300 megabyte TIF file should not be an issue in this day and age. And in this day and age who wants to own servers so we built this for the cloud. Which brings us to our last point. We're keen proponents of open data and open access. So cloud and proprietary software shouldn't mean vendor lock-in. It should be about delivering great services but still allowing the client to get access to their data whenever they like. And I just want to skip back to MVP for a moment because I think it's quite misunderstood. Around the tractor one says minimal viable product. MVP is not taking a stab at doing everything and doing a poor job. That's kind of more like prototyping which does have its place. But MVP means taking each part and doing a great job on a minimal set of requirements. So what's going to get us to the next stage in our learning to still deliver a great user experience. So instead of going across the bottom here, we just take a thinner slice of the really important stuff and try and do that well across all of those areas. So taking those, when we start to think about the RFP it became clear that you could break this project down into three kind of areas and this allowed it to silo features, control scope and work on different parts at different times. So the way we built this is the object store handles uploads and processing of assets. It's a search server, it's an image server, an API and it can be accessed via REST or GraphQL. On top of that sits the collections online kind of website or the main sort of, the main website and the most visible part of the platform. And lastly we encapsulated community as all the features handle interactions with the platform. Things like comments, favourites, sets and articles and the future things like transcription and geotagging. And it's a bit more of a technical slide so it kind of looks like this. So it isn't a website, it's a cloud based object store with an API layer on top that provides access Now it's a bit hard to see but every object is simply a text file of metadata and the source image. So the API is the smarts that sits on top of that to deliver the content in a coherent way. But if everyone went Pete Tong, then you only had backups then if you only had backups of that object store you could really rebuild the archive. The front end is currently driven through WordPress although we've just started redeveloping this natively. We found in the project that was probably one of the most successful parts of the project to date. Right, it gets harvested to Digital New Zealand and as one of the issues before was the session-based URLs we now got 7.5 out of 8.5 thousand pages in the Google Index. It does cloud-to-cloud backup to Backblaze B2 so we've got the main store, we've got a Backblaze B2 and it can also be backed up by Palmerston North Libraries. Palmerston North has access to this object store where they can read all that data and back it up into their own sort of corporate IT systems. So we're starting to build in a little bit of that digital preservation kind of stuff into it as well. In terms of performance, you're just running to the other day against Google's tools. It's 99 out of 100 mobile rating so again that increases your Google indexing in Google rankings. 70 out of 100 for the speed test, not 100%, but we can get a bit better on that and we're using HTTP2 and SSL so again that stuff that makes the website faster and gets stuff well indexed by Google. And lastly, kind of what's it built on? It's really simple actually, it's a Ruby on Rails application with Elasticsearch, it's for the technical folks. It's the main website, it's built in React and it's built on Amazon Web Services and the image hosting, not just yet but will be soon will be AAAF kind of image serving so that'll allow a whole bunch of really interesting things that we can do with the images. So that's kind of the how and the why we built and now it's time for the live demo of death. Just bear with me while I get all set up. That was easier than I thought. I told you it wasn't up there. This is a trouble with a live demo. Leave people muttering in the background, I'm sure it'll be fixed soon. There we go. Oh, alright, okay. That's exactly what they told me not to do before. That's fine. Anyone know any jokes? There we go, thank you so much. Okay, so my name is Heather Glasgow, I'm a heritage assistant at the Palmerston North City Archives and I'm here to tell you about how Manitou Heritage has helped us to offer a better user experience for our community and I'm going to be focusing on those issues that Leith specified before in his overview of Patek Iparangi. One thing I'm not going to talk about today is platform design as I click around. Now you can see it on the screen. Hopefully you'll be able to decide for yourselves whether we have that right mix of functionality and simplicity. It is a really fun platform to use and I hope you all take the opportunity to explore it for yourselves. So the first thing that Manitou Heritage does is it allows us to use our master images. Palmerston North Libraries has an extensive digitization program and we have thousands of high quality, beautifully digitized images that before just sat on our internal servers and weren't available to the public. Manitou Heritage enables us to share them exactly the way they were intended and all images can be zoomed in on to reveal all details like this one here. So you can see how quickly and easily you're getting all of the information in any particular image. Now people love this feature. The availability of the high-rise images helps with identifying people in groups, so something like this and as Richard Foy said before he was very excited when he found his grandmother in that archives photograph. It's the same thing in our community. People come in, they find family members in photographs that they didn't know existed so it's really exciting for members of the public. It's also great for finding those little details in images that you might not have noticed before which of course involves finding Annie and all cats in the photographs but also I think this is a really interesting image because before zooming in you might not have noticed that these gentlemen they clearly work in the dying end of this this is the flax photograph and you can see their black hands. So it just gives a little bit of clarity about what those gentlemen did in their day-to-day life. Even we're finding new information in the collection like in this photograph here we had this one labeled as an old woman but as a matter of fact when you zoom in she's in fact painted up to look like an old woman. Unfortunately, Manuatu Heritage isn't CSI if you zoom in on a low quality image it won't make it more clear but if you do have high resolution images Manuatu Heritage is a great way to share them. So it's fantastic for all those regular size images but as Leith mentioned before we have a lot of large format items which are completely unusable. Using Manuatu Heritage we're able to share them just as they were intended. The original of this panorama is about a meter long so making it 800 pixels wide really diminishes its quality. Archives are about more than just photographs. We have a variety of complex objects including videos, photograph albums, books, postcards and more all of which are available right on this platform. I'm going to use a photograph album to display a complex object for you. This one is a 1917 flax album so you can flip through it just like you're holding it in your hand very quickly and easily and you're also getting that deep zoom that we had with the individual images as well. So you can see the quality of your images is really important when it comes to Manuatu Heritage. It's something that we never would have shared in the past because all we could put up were low quality PDFs now we can share them just the way that they are in real life. The next improvement is that all of the content of the simplest image to complex objects can be viewed on any device. Now we had a mobile emulator we're going to try this instead so you can see, hopefully you'll be able to see that the content shifts around the screen based on whatever size you're looking at so from videos to the front page searching everything works just the way you would expect and it looks great on both large and small screens. It's an important matter to consider because a lot of our views come from social media shares and so you're clicking back on your phone but you're still able to use the entire website. Now Manuatu Heritage also gives us much greater flexibility when it comes to making things available for access. About 85% of the content we have on the site is available for download either under a Creative Commons license or under a no-none copyright. This is an example of one and by hitting original you'll download the original master size file and large is as you can imagine a smaller but still usable copy. Now we do have donors who want to donate content to us who want to place restrictions on them and we can cater for that as well but what's great is that you're still getting the deep zoom function just like you were with the more open access copies but when it comes to downloading them you're not able to do that. The fifth and last final feature I'd like to point out is the community upload feature. So we really wanted to give people the ability to upload directly to the repository because we know so much of the important history of Palmerston North is in the community. So we've given the options to either upload single images at the moment or also to write an article which is usually a story which you can either populate with images that you upload or directly from the repository images we already have. I'll just see if I can quickly show you what that might look like. This is an example of an article that's made from all three kinds of object. This is an image that was already on the site. We have some text and also some images that were taken specifically for this article. So it's a really visually appealing way of displaying lots of different kinds of information. Once an image is uploaded to the repository it is displayed alongside everything else just as soon as it's been moderated. We also offer favoriting, tagging, commenting, and sharing all those normal ways of engagement that you would expect. So what you're seeing here represents just one year of development. We have thousands more records to upload and we are also looking to expand functionality based on both usage and feedback. It's been years in the making but we're hugely proud of how Mono2 Heritage has evolved and the feedback from our community has been extremely positive. With the same content we're able to connect and engage much more effectively because we took the leap and the risk of reimagining what a community archives could be. I think on behalf of Glen and Leith I'd like to thank you for being such a great audience today. And thank you. And we stand due into silence. All the way over here. So you mentioned IIIF for the image store since that's kind of a standard. This is a bit nerdy, sorry. What backend server did you go with? Yeah, we're going to be switching out to IIIF. It's not something that's our next but we're going to switch out what we've got to that IIIF. Still deciding on which one. Still deciding? Okay. But IIIF I've just seen is just getting a ton more interest in the glam sector in general and I just think it seems like the right way to go. Now it just gives you everything in a box essentially. Sorry, can you just wait until you get the microphone because it's being recorded and I need the questions. Thanks. When the community uploader is being used where does the content live until it's been moderated and added to the live site? It still lives with everything else but it's just in a process of being unmoderated so the admins can see it but not the public. Okay, but it's already kind of on the servers you're using. Yep. Okay. Now someone right at the back. Hi, I was just curious as to whether you had all the high res imagery before you started this project or it was a part of the transformation of prepping all this content into high res? No, that was really the main thing is that we had all of these thousands of high quality master files but no way to display them. Now we did have a four step process that involved e-mailing and forms and things that people could get access to them but in order to make them available we had to start from scratch with the new platform but the content was already there. It's interesting hearing this, having just seen the presentation for it to need in public libraries. In the discussions that you had in terms of looking for a system and where you were going to go was much consideration given to something like Recollect or another platform before going out to design something or not quite in-house but something within the organization. Yes, absolutely. I can't give any detailed comments about the RFP process because a lot was commercial in confidence but yes, we had three vendors and developers. One was an open source product which was Islandora. It would have been supported by a local development company and the other was Recollect and then Glens was the third one. So we were surprised at how few options there are for the Glens sector to choose from. I really shocked at how limited it was. Once you knew what you wanted to try and find vendors that could do everything you wanted but yeah, so Recollect was definitely there. One of the options we looked at seriously. OK, supplementary question. Is this a product which can be sold? Sure is. Come and see me upstairs later. Yeah, we built this as a platform to roll out to others. The more people get on the platform, the better it gets.