 Fantastic. Hello, I'm Colin McFadden. I'm from the University of Minnesota. I came across the river. I'm specifically with our College of Liberal Arts, and I'm going to be talking about a new tool we've created in the sort of digital asset management, visual resource management, learning object management space that gets very blurry. I think we're trying to challenge some of the assumptions that we've seen in other tools in this space, and we think it's pretty cool, and we want to share it with other folks. I'm going to start out by talking a little bit about how we got to the point that we're at today. I'm going to talk a little bit about what we think makes our new tool a little different, and then I'm going to talk about what I'm doing at a Moodle conference, talking about a digital asset management tool. First off, how do we get here? Ten-ish years ago, people in our art history department started noticing that there weren't as many slide projectors in classrooms as there used to be, and they had an awful lot of slides, hundreds of thousands of slides, and so we needed a way to get those into the digital space so they could continue to be used in presentations and then increasingly in online classes. I would suspect that we're not unique in the case that the initial solution of this was FileMaker. This was our first tool. It's called the Digital Content Library, and it grew very organically to meet this need for getting, initially, these actual physical slides online in a digital format. Over time, other departments started to have similar needs, so we added content from the School of Music, our College of Design, the Weissman Art Institute that's right next door here, and we've got this sort of organically grown collection of content. We eventually added some support for media formats like video and audio, and it's grown to hundreds of thousands of assets and many terabytes of content. Still based on FileMaker. It grew a web front end at one point and then lots of scripts in between to make all those bits talk together, and it's a highly curated collection. As you can see, there's a ton of metadata here, and this is actually all entered by professional curators, people with library science degrees who are spending their time adding assets to this collection. How is this used? We see a few different use cases for this tool as it exists today. The first one I'm calling an archive case, which is I have some content, and I want to make sure it doesn't go away, but I don't really know what I'm going to do with it, and so it's sort of this write once, read never approach. I want to put it somewhere and know it exists, but I don't have a plan for using it in the immediate sense. The next is at the other end of the scale, this content hosting model, which is I have some content that I need to use in my class next week. I have a stack of slides or some VHS tapes or some digital files from a digital camera that I need to get online so my students can see it next week, and that's very much all I need is a link to my content. I don't really care about discovery and all that other stuff. The next use case is discovery, and that is people coming in and actually searching our collection, just like they would search Google or any of the awesome resources that come out of our libraries, and that's really leveraging all that rich metadata to come in and search for a specific artist or a location or a material that a piece of art might be made of. And then the final one is this idea of understanding the context, the relationship between all the objects we've got, and being able to start at one place and end up somewhere different, sort of how you do on Wikipedia. That's one we don't do very well right now. This tool has some real limitations, though. As I said, it's intensively curated, which is awesome for metadata but bad if you have 100,000 assets that you need to put online by next week because we have limited number of people and entering all that metadata takes a ton of time. And so that becomes a real roadblock, especially because our workload tends to be very variable. Right now, semester is about to start, things are going to go crazy, and it's hard to serve all the needs that we need to serve. The next real issue we see is this fixed file format support. I said we added audio and video at one point. I was around for that transition. It was not a happy time. And none of us really want to ever have to add new file formats to this tool again because it wasn't designed with that in mind. It was designed for slides. And then we sort of glommed in these other things. And no one wants to touch it because no one really understands how it works anymore. And then finally, really expensive scaling. All this stuff is still running on hardware that lives in a data center across the river. And so when we want to add storage, that means like adding hard disks. And those are like data center hard disks, which are the expensive kind. And so it creates real issues for scaling because it comes in these big chunks and we can't sort of scale organically. So we did go out and look at the market because I'm really aware that in education, the answer of, we'll just build it ourselves. It's almost always the wrong answer. And so I'm fully aware of that. So we looked at a bunch of tools. We looked at things that come out of the commercial world, like CatDV, which is really a digital asset management tool. And we looked at more traditional tools like DSpace and Resource Space. And then we looked at stuff on the learning object side, like Aquela. And what we saw is none of them really met our vision for where we see the use of digital assets going on campus. You know, the commercial tools don't really think in the same way we do in terms of access control and having some things be fair use, you know, free to everyone and some stuff be locked down. And they didn't quite meet the bill. And some of the tools on the Aquela side, Aquela is Aquela, they can be pretty painful for users to use. And they don't really encourage the discovery and the fun that comes with some of our assets. So we decided to build our own. The new tool is called Elevator. And very briefly, Elevator is an open source tool. It's up on GitHub. We are really excited about getting some partners who want to collaborate really actively on this. It is cloud based. This is how we deal with those scaling costs. It all runs on Amazon's AWS web services. So we're using EC2 and S3 and all the wonderful things that Amazon provides, which means that we can scale nice and linearly. And it's very easy and very granular for us to grow the tool. It's metadata agnostic. What does that mean? Elevator doesn't have any core metadata. It's not Dublin core. It's not VRA core. It's whatever you want. And it can have many different metadata schemas so that you can pick and design the metadata schema that works for describing the types of objects that you're working with. So if you're working with art history objects, you might work with something like Dublin core or VRA core. But if you're going to catalog all of the trees on campus, you might want to create a different type of metadata schema. And so our tool is really designed around the idea that you build metadata schemas, you change them over time, and they become these templates for describing objects that are really specific to the types of objects you're describing. And finally, we support any file format. And the idea here is that I don't know what the landscape of technology is going to look like in five years or in 10 years. And so we built the tool from the beginning with the assumption that we would be adding support over time as technology develops. And so that's a core design feature. I want to talk a little bit about how Elevator works without getting into the techie side of things. And so I just want to take you through what the different components are, how they stack up. And so the very first thing in Elevator is something called an instance. And that's like a domain, a website. So Elevator.umm.edu or whatever. And that's going to take you to a custom website with its own design and its own look and feel and a collection of content that might be our history content or School of Music content. Next, we have these metadata templates. Each of these instances has whatever templates make sense for their objects. And so the School of Music has decided on a very different type of schema from, for example, the medical school. On top of that, we have permissions. Because we understand that sometimes we want our content available to everyone. And, you know, obviously that's, that's amazing when we can do that. But sometimes we want things restricted to just a course or just a unit or just a specific person. And we want to control, say, you know, undergrads can come in and view content, but maybe we don't want them to download content. Or maybe we want some people to be able to edit content and others to be able to just go in and pick and choose and, you know, curate little collections of content. On top of that, we build collections, which are like folders where you can group content together to share with a course or something like that. And then finally, we have more permissions. So we can say this collection is available to everyone or this collection is available to no one. And our assets live on top of that. So what does it mean? Oh, one more slide. The other cool thing we can do, I said originally our tool grouped together all of our content into one big bucket, which meant school of music content was mixed in with art history content and design content. And that tends to not be that useful because rarely are you coming in saying I need this, you know, painting and, oh, look, an opera recording. You know, that kind of organic discovery isn't usually helpful. It's actually detrimental. And so we design the system so that we can really easily split these apart. And the whole system behind the scenes doesn't really care. We can have 100 of these running without any additional system load. They're just different pointers, basically. And so the idea is we can really break up these sites for our different users. So what does it mean when I say that we are metadata agnostic? I'll take you back to our existing tool in FileMaker. We've got all these fields and this is really awesome. It's great to have all this metadata for this type of content. But when you think about that sort of content hosting model, if someone brings you 100 images they need online for next week, really the only thing they care about is maybe the title and then the digital asset. And all the effort you're putting into adding that other stuff, that's not effort that's being really, you're not really seeing a benefit from that any time in the foreseeable future because that person has put that content up to use in a very specific way. So with Elevator we've designed a system where we can create a metadata template that just has a title field and a file field. Or we can create a metadata template that has a folio field and a page number field and a material field and all these amazing things that we catalog content based on. And we can also have really smart metadata that understands things like location. And so if you want to have a location metadata field we're going to give you a map and you can geocode an address and drag and drop a pin. We've really smart date fields that understand the relationships between objects and time so that we can let you navigate your content with a timeline and you can say, you know, how does this object relate to this object temporally or spatially. And so we've really tried to make metadata a smart part of this curation process but also make sure that it's not getting in the way of the user. Because anytime a user sees a hundred fields and thinks, I don't have the time to fill out a hundred fields, I'm just going to put this on my Google Drive account. That's content that we're losing access to that we're not keeping under curation and that's a problem. The other big thing we're doing with Elevator is trying to challenge this idea of file format support. Anytime a user sees a dialog box like that where we're saying we're not going to accept your file, I think that that's really problematic because that's again a file that's going to go up on Google Drive or Dropbox or a USB disk sitting on a shelf and that's content that's not being backed up and that's content that's at risk. And so with Elevator what we did is we said we're going to take any file. If you upload a file, even if we don't know what it is, we're still going to store it for you and you can get back to it anytime, you can download it again. But then we wanted to build in support for adding really interesting ways to work with files as well. And I want to give you an example of how that's played out in production so far. So maybe six months ago some users were doing some beta testing for us and they started uploading files in the OBJ format, which is a 3D object format. What they were doing was they were doing something called photogrammetry where you have an object, you can take lots of photos around it and you create a 3D model. And it's a really beautiful 3D model. It's got a texture and it's really cool. And so they were uploading these. And Elevator, of course, it didn't know what they were but it wasn't rejecting them. It was saying that's fine, I'll store it, you can download it again, no problem. But they sent us an email and said, hey is there anything cool we can do with these OBJ files? And because of the amazing open source world around web technology, people had already created web viewers for these formats and there's tools like Blender for making thumbnails out of these images and all that kind of stuff. And so within about something like four hours we went from OBJ not being supported to having an interactive 3D viewer as part of Elevator, where you can go in, see one of these objects, you can grab it and spin it around, you can measure it, you can change the lighting on it. And suddenly that's a rich part of the tool. And because we were accepting all those files already, we were able to retroactively add that support to all the files the users had already uploaded. And we've seen this again and again because once you say, hey we can do cool things with lots of file formats, suddenly these come out of the weeds, all these very niche file formats that are created in specific disciplines created by for example MRI machines. I didn't know what file format MRI machines created until fairly recently but it turns out they create a format and it's pretty cool. Some of the other cool things we can do once we're having really flexible file format support is we can say, well you uploaded an OBJ file but what if we automatically convert that into an STL file? And I'm sure STL is kind of a weird format for most of you but I will say that is the format used by most 3D printers. And so now we've got this workflow where a user somewhere can photograph an object, make a 3D model of it, upload it to Elevator. Another user can come in, search, find this object, play with it, download an STL of it and print out a 3D copy of it and then hold it in their hand and look at it. And that's kind of magic. So that's kind of what we're trying to go with this tool is we really want to understand the new ways in which people are going to be using technology, not just for images and audio and video but really to start to push the boundaries of, my microphone went away. That is sad. Okay. Hello. Anyone? Anyone? Okay. Hello. Hello. Hello. Hello. It's all come back. I was too squeaky and it went away. That is my, that is my life. So that is what we're doing with file format support. We really want to understand not just where our users are at today but where they're going in the future and we want to be ready to grow with them. Another thing we can do in this maintaining connections category that I talked about, this idea of context is that we can understand the relationship between different file types. And so this is a test asset but this is a orchestra recording from our school of music where they have uploaded not just the recordings of the individual performances but they've uploaded the PDFs of the program from the event and elevator went in and scraped all the text out of the PDF and made that searchable. And so now if someone comes in and searches for a specific performer they're going to get to the record of the music being played without anyone having to go in and type in all that metadata and you can actually also go and interact with the PDF right within the browser as well. And so we're trying to understand how we can relate together different types of assets, understanding that a lot of times our users are creating content across many different formats but it all is related together under one project umbrella. So Elevator is a destination, it's a website, people can come, they can search and browse, they can see the assets with all kinds of metadata display, they can interact, they can download. We've got things like a more like this button which will use the knowledge we have of our assets to say hey here's some other pieces of art by the same artist or here's some other films that were shot at the same location or that have the same actor and so we can start to understand those relationships between objects but Elevator is also a repository in the Moodle sense and so we have a Moodle plugin that basically does everything you can do as a consumer through the Elevator website, you can do through Moodle directly and so you can go in and search and browse and you can click and add content to your Moodle site and this works through the image picker that's attached to any of the sort of whizzy wig text entry boxes but it's not just images that you're adding, you can add 3D objects in this way and videos and word documents and they stay fully interactive within your Moodle site and so this becomes a way to bring all of that rich interactive content into a Moodle lesson for example anywhere that you have that image picker box basically and you can now begin to add any of this content all on one page without your users ever having to leave your Moodle site and really importantly without your faculty area your instructional designers ever having to go and cut and paste links that then break when you upgrade a system or something like that and so there's this really tight coupling going on behind the scenes and from the user's perspective it's just this magical collection of content that lives within Moodle and then they can access and as an added benefit for our infrastructure people there's not files being copied back and forth this is all seamless behind the scenes but there's not an extra demand on our Moodle site to store all these assets. One of the other cool things is that it's not just media and so if you go to add a SCORM package our plugin says hey I know that you're trying to add a SCORM package I'm going to just show you your SCORM objects and now we're going to let Moodle download those SCORM objects and unpack them and run them right within the Moodle interface and so it becomes a way to store things like SCORM bundles as well within the elevator system but then use them seamlessly within the Moodle interface and so we really think that we can be a fairly flexible repository that can meet the needs of our users who don't want to jump into the rich metadata curation space and to meet the needs of our users who are really interested in building these rich collections that are going to have a long lifespan and might be syndicated elsewhere. So that is what I've got to talk about. We've got a website at elevatorapp.net where you can learn more. We've got a Google group you can join and we have our code up on GitHub. We're still sort of doing our convergence right now on what our final shipping code is but you can take a look at that as well and we'd love to talk to other institutions that are interested in either checking it out we can set you up with a demo site or we'd love to find some people who really want to partner for active open source development as well. So thank you and any questions I will take them. Oh, I saw the microphone. So Colin is one of your pilot sites. Thank you for an amazing app. This is really an exciting tool. So at the medical school we're doing his daikon images radiology x-ray. We're very serious about putting other assets we don't have homes for. So one of the things I was going to ask you just to talk a little bit about is if we got serious about using your metadata to flexibly annotate our video would there be management tools and if we went from a hundred videos to let's say terabytes of video that we might be able to track the load on the system and make sure that we're staying ahead of that or does Amazon web services just dynamically handle that. Yeah that's one of the really cool things about being on a cloud platform is that you know I always keep reminding myself when I start thinking boy this is getting really complicated this is like computationally intensive and then I think you know what Netflix runs on Amazon as well and if Amazon can handle Netflix I think they can handle the University of Minnesota's little software project and so things like the storage back end S3 is really designed with that in mind and so it doesn't really care if you're streaming 100 videos or 100,000 videos or 10 million videos it's designed in a very smart way to scale like that. So since you're running this in somebody else's computer in the cloud what does this cost monthly, annually whatever? So the real driver of cost is just the storage demand so the compute is $30 a month or something like that for the actual web server side and then the primary ongoing cost is the storage with S3 which works out to about a penny a gigabyte a month and so for us it's a couple hundred dollars a month and compared to what it was costing us to run physical machines plus the FTE of someone walking over to swap tapes in a data center for example it's basically an order of magnitude reduction from our existing system of the same scale and the cool thing about these cloud platforms is that the cost curve gets cheaper the more you add so and basically every six months as well Amazon cuts their prices in half which is pretty awesome. I was wondering if it's tied just to Amazon or it gives a different cloud or your own? Yeah we've tried to walk a line on that because Amazon you know they're very tempting because they have all these amazing services and it's very tempting to go fully in and we've tried to walk the line of using them smartly and so our biggest dependency in terms of what would take effort moving away is that storage side of things the S3 where you'd have to change some of the code to use Azure or to use some of the other cloud platforms but beyond that the web app itself is a fairly standard lamp stack we're using Postgres we were using MongoDB and we've just moved over to Postgres for NoSQL stuff and then we use a few other Amazon components said to be easy to swap out but most of it's all in house run by us just on EC2 so pretty easy to move. I'm going to cheat and ask a question Colin just have you ever seen tools Omega and there's some tools built on it one's called create escape do you does this have a narrative or a creation to create narratives on top of it structure tool? So that is the space that I'm probably most excited about and I really right now I'm seeing elevator as a tool to power some of those things and so we've been working with some other people on campus because elevator has a full API to do some links where elevator can help drive some of those experiences because I think our interface for managing content is stronger but I didn't want to try and cover all of that within one tool right now and so I'm really excited I mean that's a space where we've got some users who are working with things like Oculus Rift to do interactive 3D environments for that narrative experience we've got some users using the leap motion for things you can touch so it's a really cool space and I want elevator to be the behind the scenes component.