 Kura koto, ka Rob Homes tōku engawa, gadao aftinun, mae nama i Rob Homes, anu rungu te digitala producta i operatiynau tepapa. We've got about 20 minutes to tell you a bit of a story, but we're very much aware that there's about this time of the afternoon concentration levels get a little low, they can drop pretty dramatically, so we'll be moving pretty quick through a whole bunch of content, and just for your benefit, we've mixed in some crude and potentially cringe-worthy metaphors. And I'm going to start with a punchline, so spoiler alert. We've created a platform that we are about to open source. It's a platform that we use to create digital interactives and labels, and we hope some of you will consider using it too. We're running a stand upstairs at tepapa, so if you want to find out more about the platform, we'd love to talk to you. Come and see us in one of the breaks. It's been a very busy year for digital at tepapa, since the last NDF we've built cross-functional teams with a bunch of new recruits. These include product owners, scrum masters, UX designers, UX researchers you heard from Mike previously, developers. These people have come from all corners of the digital industry, and they've brought with them experience building award-winning digital products, including simulations, games, and they've built them within New Zealand and overseas. They've come from the BBC, from QBank, from Read in New Zealand, and a variety of educational organisations. But these people, like me, are new to tepapa—sorry, Mike— and new to the sector. And while we were all really excited about joining the magical world of a museum, we also rapidly found we had a lot to learn or re-learn, and I did check before using the photo that Mike was presenting before me, not after me. The green screen is part of Hinatore, a lab built by our learning innovation team, a magical world of VR, AR, MR, large 4K touch-tables, 3D scanning, 3D printing and more. We also encountered a world where digital looked like this, or looked like this, or like this. Now—and this one's a climate change interactive from very early days of tepapa. Now, I'm not suggesting these products are broken. They were absolutely cutting edge in 1998. These were some of the first touch screens anywhere, and they predate the iPhone revolution by about a decade. They have done and continue to do great service, and to be honest, I think they've aged incredibly well. And they are kept alive by an exceptionally talented and dedicated team. But under the hood, vintage digital products are generally much harder to maintain than a vintage car. The inner workings are often a black box, and those black boxes have support contracts which expire. And to add to the challenge, the products on the floor at te Papa have been developed by a variety of different vendors using a variety of different technologies. And fewer of them use open standards. So little wonder, I guess, that there's a wide variety of user interface design patterns and that it hasn't been possible or affordable to keep the interactives consistent. And the reality is that the problem is often worse than just a lack of consistent user experience. This, for example, is not a screen you want your users seeing ever, even if they are Windows fans. So as we look to create new interactives, such as this touchscreen for the Depahi Metal mini-exhibition or hotspot as we know them here, or a bigger batch of interactives for the recently opened exhibition for Karonga Fakata, or for other upcoming large exhibitions, we were thinking about how we could do it so that it was fast and efficient. But we knew we had to also avoid the problems we'd seen with these previous products. We clearly needed to do things differently. And while we needed to produce products that were the greatest and greatest user experience, who doesn't want one of these? We even more importantly needed to create an own effectory or a platform with a focus on processes and components to speed up production and improve quality, and which focused on the monitoring and analysis of product performance in the field and the capability to support and enhance products will be on day one. And finally, we wanted to ensure that we retained the IP and the assets we generated. Good afternoon. I'm Richard Hulse. Some of you will know me from my previous work at RNZ, where I built and ran the website until October last year. I started at Te Papa in January this year with a fresh challenge, which Rob's just outlined, which was basically create a Tesla-like factory at Te Papa. One of the things I had to do when I got here is start listening. As a product owner, the most valuable skill that you can have is listening to the voice of your customer. One reason was that I came from broadcasting, quite a different field. Glam sector wasn't so familiar, and of course I had a lot to learn. The other was that according to Peter Drucker, only those in the process actually have the information needed to improve that process. Now, in this case, my customers were not customers on the floor. They were actually internal customers, so the digital producers at Te Papa and other exhibition stakeholders. So I listened a lot and wrote a lot of notes, several books worth. And after a few days, a week or so, I started to join some dots up and started getting an understanding of what the problems were and particularly what controls were in place in the current process. So these are often unspoken controls. They're rules that stop the organisation churning out material that is of a poor standard or broken. One of the things that I did during this is that once I'd formed a theory of a process that might work, I started sort of pitching that in story form as a narrative in small pieces to various people. And then on their feedback, adjusting it so that each iteration I would be updating my story with improvements that I'd pinched from everybody else. I went through quite a few iterations, but what I was doing was building foundations. So the foundations are very important in any system. The primary foundation that we have here, and I think Mike's probably mentioned it, is the digital language system. So when we do a piece of user research, we discover a foundational principle or a pattern, then we can codify this in this document and then it is available to recycle and reuse. So it means we don't have to... we don't have to test stuff again, and I'll give you an example of that in a minute. The other thing was a whole bunch of design principles. These were things that sort of came out through the conversation, things like modularity, off-the-shelf stability, reusability, accessibility, multilingual, built for the future, and for change particularly. One thing we wanted to do is build on web technologies, HTML5, CSS and JavaScript, and make those our primary toolkit. The reasons were flexibility speed and then being, of course, open standards. We use a DPDF here, the Digital Product Development Framework. Have I got that right, team? Yep. Lots of acronyms. And part of that is developing a lean canvas for the product. Of course, the key thing in the lean canvas is the elevator pitch. And the idea is that you have to get in at level one, and by level three you have to have got this, got the elevator pitch out to your manager. And the one for this product is a little bit long, but it's for staff who need to create and maintain engaging digital experiences for museum audiences. The digital experience system is a platform and set of processes that accelerates the creation, publication, and rapid update of digital experiences. Unlike Tepapa's current solutions, this system provides audience insights and facilitates rapid production consistency and continuous improvement across all the deployed digital experiences. So that's a pretty high bar. We started out by building a few interactives. Now, a few things at this point. This new process obviously had to sit alongside existing Tepapa processes such as writing and video production. The existing processes were stable, and obviously we didn't want to disrupt those while we're working on our new digital processes. This process is designed to adapt over time, so we're using agile scrum for our design and development processes, and we have retrospective every two weeks, so we basically build any improvements back into the system, any problems that we find, we try to solve those also. And user experience discoveries are codified back into the digital language system so they can form the basis of future work. So we started out using a framework called Marko. Has anyone heard of it? A couple of people. The people who worked at Tepapa. So this is a templating framework built by eBay, and we built a couple of stand-alone interactives with this. We learned a lot, but we decided not to continue with that technology due to a lack of community and it being a little bit monolithic. And it was also very difficult to get contractors to help us who knew the framework. So we pivoted to React.js and decided to architect things up front. So deeds comprise of five components. The first is the component suite. So this is reusable components such as video player, an image component that holds an image and can zoom and incorporates all the touch elements that are required for touch screens and a language toggle. It's built using React and Redux for the technically inclined and it can be imported into other projects as a node module. So what do these components look like? This is the Tepahi medal interactive. You can see a home button on the left, language toggles on the top right. There's also layouts for wording and images. There's an explore gallery button which leads to a gallery and a timeline at the bottom. Now, since I took the screenshot, we've actually changed the explore gallery based on research. We found that with no image, few people actually clicked and explored the gallery, but when we add an image to that, then people click through and explore. Another component is what we call the gloss. This is where we use a Maori word in English. People can tap on the word and it pops up a little pop-up which says what the translation is and then you can listen to that. So that's now standard fixture in all of our interactives. The second part is the starter kit. This is a basic framework for containing the interactive. It sets out standard directory structures, places for images, video styles, that sort of thing. The third part is the deeds player. This is based on Electron which is basically a Chrome web browser packaged to run as a standard desktop application. It always runs full screen and when it starts up, it registers with our build system and it runs the interactive standalone so that basically you don't need a network. This was one of the things that the audio visual guy stressed when I started. The floor has to run with only power. We can't rely on the internet and it can run on Windows or Linux. So currently we use Windows on the floor but we've also built a Linux kiosk running an interactive as a proof of concept. So the fourth part is our build system which is based on Jenkins. It takes the code and the assets such as images and video and so on packages them into a format that the deeds player requires and then the last part, the deployer, can then take that package and send it to the device on the floor. Now I came to Papa with quite high expectations in regard to deployment. In my first week here someone came to me and asked the question, do you think we could possibly be able to update content once a week? I came from broadcasting and obviously with a web background and we're updating content dozens, hundreds of times a day and I said, yeah, I think a week will be possible. So prior to deeds, updates were generally done also outside of ours, perhaps every few weeks at most. But now we can update whenever we want. All we have to do is walk out on the floor with a tablet, make sure no one's around and press the button. So this deployment was done during office hours. Now an important part of the platform obviously is analytics. We do go out on the floor and observe the interactors being used but we also collect live analytics. So this is an example of some of the analytics. Time on page, gloss usage, which language is used, which navigation type is used. So we can see that next and previous is the most common, followed by swipe and then the actual menu at the bottom. And video starts, stop, and whether it was ended, it basically ran its full course. So all of this kind of feeds back into what we design. And if you're interested in analytics in particular, Amos Mann is talking about analytics from a specific exhibition point of view tomorrow at 2.15. The other thing that we've introduced as a bit of a trial was monitoring of our live interactives. We're using a system called Nodal. It was funded by Museum Victoria in Australia and released as open source. So we've added a few new features to this, including the ability to automatically run our players at start-up. We can monitor the state of the running interactive. So there's a little heart beat that's admitted every 20 seconds. So we know that the interactive hasn't stopped. And it also reports the version number of the current interactive, which is quite useful if we deploy to the floor while we're not standing there, we can see that the version number updates. And we also added the reading of UDP commands, which basically is another way of controlling interactives on the floor. Deeds is the product of many hours' work by the whole digital team here at Te Papa, and it's allowed us to reduce cycle time and be more responsive to changing requirements. The last interactive that we built, the Land Wars Interactive, which you can see on the right as you walk into where we have lunch and morning and afternoon tea, took about half the time of the previous interactive to build, and it was of similar size and complexity. And that was because we could re-use existing technical components. But in terms of the user interface, if you have a look at that interactive, it has the same scrolling gallery pattern that was used for Artwall. So when we put that to be designed, we said to the designer, use this user interface pattern. It's already well-tested. We're worried that it's not going to work. And so we've put that on the floor and it works great. The other thing was that in the final stages of Rongafakata, where we built seven interactives, the last three of them were built in about a week, based on existing components and existing designs and styles. Last slide. A reminder that we're very keen to share more on the platform and also to mention again that we're currently preparing the code for public release under an open-source licence. And the aim of that is so that we can lower the bar for other institutions to make this kind of interactive using what we've produced. Thank you very much. Any questions? Questions? Easy crowd, thank you. Wait for the mic. Oh, it's just because this has been recorded. Thanks for the presentation, Richard. I'm absolutely fascinated. How much of the myriad of software you've just shown us is open-source? How much of it is free? What are the expenses we can expect if we want to reproduce what you've produced? So we've used only open-source libraries in putting this together. Obviously, Redux and a whole bunch of other libraries. But when we release it, it will be under an MIT licence, which is very permissive. The costs that you'll have will be design and integration. We will include some examples of how to stitch together the components. So there will be some heavy lifting required. But I guess over time I'm hoping that we or some other institution might come out with some generic white-branded, unstyled interactives. That could mean that you've got a home button, language toggles, a basic gallery, and then you can just throw the images in, throw the content in. Not that we throw anything in without thinking, but it's just to mean that if you have in-house developers, they can use it, and also go to your contractors and say, hey, there's this existing framework. We'd like to use it. Potentially they could come back and say, well, it'll do 80% of it, and then you could go and say, well, okay, we'll fund the other modules that are required, and then they could then be open-sourced. So hopefully over time, as with most open-source projects, I hope it will become more and more useful to the entire glam sector. Thank you.