 Today's talk is called Mad Scientist Roadshow and we'll explain why in a bit, but my name is Brian Olandike. I'm BTO Pro on Twitter, Drupal.org and everywhere else, and I've been in the community for like 12 years now. And I'm Mike Potter, AMP on P.O.O. I've been doing Drupal for immediately in front of you. So we get into weird stuff and why, right, and so why this talk. So if you go to elmsln.org, you can find out more about the work that we do. So we don't envision Drupal as like this thing that you use to build a marketing website, if you will. We view it more as this organic platform that we're able to build out lots of different sites and lots of different configurations to better meet the needs of education and educators. So whenever someone has a crazy idea, then out comes part of the snowflake, right? In Drupal, we think it's really great at fragmenting from its base, but still being maintainable via things like features, drush. And so as a result of that, we don't really build Drupal websites in the traditional sense. We more so use Drupal as almost an application development framework to build a distributed learning network. And so what is elms in a one-slide elevator pitch? Any time we get a new idea or a faculty member has a cool idea, we stuff that in a new domain. It's not really that different from Google if you think about the way that they do application rollouts, right? YouTube as a video service goes in its own domain, right? But I can still log in with my Google account, docs, Google Plus, all of these, right? So if we just kept deploying these new ideas and new functionality using a federated login system, we can keep expanding and innovating. And so in education speak, this is referred to as NGDLE or Next Generation Distributed Learning Ecosystem, because we like acronyms for no reason, but it's so that you end up forming, you know, kind of patterns like this, right, where all these different pieces of functionality are stitched together via web services and single sign-on systems. So for the end user, it doesn't feel that way. And so our courses, because primarily we do this for education purposes, will be something like this, right? Hey, I'm learning about math. But it's at a courses address, and we have kind of a course path there. That would be a Drupal site, which we would then network together via RESTful web services with this other Drupal site, right? But a common look and feel, common usability patterns, common login, you don't know that you're skipping around if we get the UX patterns the right way. Studio has another example, a place where students interact with each other, post-images, it's a headless, angular app. And so this is all only possible because of the architecture and because of Drupal and the fact that we basically have a self-federated ecosystem. So all of our Drupal sites have knowledge of where all of our other Drupal sites are, and faculty requesting new course spaces are kind of organically building this out, right? So why do you care? Because we get into really weird stuff as a result of all of those slides I just burned through really quickly there. And so what we're going to talk about today is some of that weird stuff that has emerged because of those requirements, because of just the architecture of Elms and the way at which we go about design. So the first one of these little lightning talks in here is called accessible empathy. And so the desired outcomes of this experiment, if you will, is to increase accessibility options through user preference. And so if end users can select their own accessibility options, that we not only improve outcomes, but we also can help improve empathy. So if we not only allow people to check, hey, change the contrast ratio, but we allow them to check, hey, let me see what this site would look like if you had dyslexia. We can start to produce empathy with people that have different conditions as a result. So in looking through this and through a lot of these, we had to get off the island, right? There isn't a Drupal module that does that. And so one of the things we found in getting off the island through these needs was open dyslexic. Open dyslexic is an open source font created that manipulates all the fonts on your website to be more easily readable by people with dyslexia. So guess what? Now there's a module for that. So there's the A11Y module. If you get it, it gives you a lot of access to these plugins. They're gonna show here in a second. And so I have this little canned video, I'll talk through what's going on. But the way we implement the A11Y module is you get this panel over here. So you can make your interface bigger, smaller. You can do high contrast mode, which uses CSS and JavaScript to tweak the contrast. You can invert the colors, right? Which is better for people with certain ocular conditions. Disable interface animations, which can help people not get as disoriented. There's the open dyslexic font applied, which then is just check the box and rewrites all the fonts to load that, then we get into simulations. So this is able to simulate every form of color blindness through SVG filtering. And so it's SVG filtering the entire interface. We can simulate field loss, which is something in the W3C spec to account for. And then if I refresh the page and I don't click the keyboard shortcuts button, simulating dyslexia. Now I've been told that this is not what dyslexia is like, get it. But this was a JavaScript simulator that just said, it was like, hey, my friend told me that he had dyslexia. And then all of a sudden the words start doing that. So trying to create these ways in which we can get users to not only say, like yes, okay, I have to put alt tags. But actually empathize with the conditions of people that really need these things. So it isn't just alt tag info. So if you wanna learn more about this, you can find out A11y project. There's gonna be a lot of links throughout this entire thing, because these slides will be posted later. So you don't need to furiously scribble. A11y module, ElmZellen.org has blog posts as well as Drupal.psu.edu. It has a lot of blog posts that we do through Penn State. Next one of these little talks is called Track All The Things. And so our desired outcome with Track All The Things, because we wanna know what students are doing with our course material, right? I kinda like Google Analytics type of stuff. Are you getting to these different goals? But for us it could be, are your students bothering to watch video? I don't know, you spent a month producing a really high quality lecture. It would be great to know if people actually bothered to look at it. So again, didn't wanna use a Drupal-based solution for this. Yes, there's stuff that can do tracking. You can just write PHP and JavaScript and do it. But we found a platform called Learning Locker, which is a open source PHP. It's called a learning record store or LRS. And it uses a standard called Experience API. An Experience API to unpack what that is is basically that events are happening all the time everywhere. And so if you view the world as just emitting data at all times, like me moving my fingers is emitting data, that how would you track that activity statement? And so that you can track any activity, boil it back to a verb, a person, where it happened, and what they did kind of, maybe some contextualized information, right? And so in this case, the verb is that I viewed something, I could mix in some extra context info, and that this is, the agent is, hey, the admin did this type of a thing. It's a glorified JSON array. It's totally changing the training and education space, but it's a glorified JSON array. So of course, there's a Drupal module for glorified JSON arrays called the TinCan API, which is an alternate name for Experience API, it's like a talk of its own. You can actually go to ExperienceAPI.com, and then it'll say like, I say TinCan, and you can click TinCan, and it just rewrites all the words to say TinCan instead and goes to a different domain. But when implementing the TinCan API, what we can do through Drupal is jump in at the point at which a message is about to be sent to our LRS, and we can mix in our context data. So in this case, we're mixing in the course a student is a part of, and what their role is, the fact that they're a student. Obviously, XAPI doesn't really have this connotation of what a course in ELMS is. And so we can use the Drupal hook system in this case, mix that data in, sprinkle it along, and then it goes out the door. So to see what this ends up producing, when you wire the world up for XAPI, is we've actually got this public ELMS site about XAPI. And so click around to things. We do this talk at some education events. We don't actually tell people, it's like, hey, you're learning about XAPI, but what's happening here is everything I'm doing is generating XAPI statements. And so then we unlock the visualization of that aspect later for people to see like, oh, that's what it means when I'm tracking everything going on. And so even down to the granular level of clicking these things and dropping them in that order is tracked. And so then it's sent back to, this is a learning locker. And so then learning locker, you can unpack and here's the statements, right? So the fact that I clicked on that YouTube video and monitored and sent a, hey, the user played from this point in the video to this point. This doesn't have to do with education. You can do, a lot of people use Tincan and XAPI for like analytics for user tracking in any system. If you wanna learn more about it, there's ExperienceAPI.com or TincanAPI.com, depending on which word you like to use. The TincanAPI module is out there and then there's actually a little open course about XAPI if you wanna learn more about it. So next talk here is, I say flat file. You say CMS, flat file. Oh, thank you. Flat file, yay! Audience Engagement Participation scores through the roof. So, track it, yeah, XAPI for that. So what's the desired outcome of this? We have faculty members who don't wanna work with us. One of them who was supposed to be on this thing. He was gonna give this talk so I can make fun of him. But so, they want to not use Drupal. Can't imagine why it's got such a great user experience, right? But part of it is just ownership of the material. The institution owns the deployment of the technology and so if he's funneling all of his knowledge into that, it's in our database systems and not something that five years from now he's gonna be like, oh, you know, where's that course file on my desktop? It doesn't exist. He shoveled all of his efforts into this third party thing. So, the solution that he came to and then we worked on a pathway to integrating is a tool called Gitbook. Gitbook is this pretty sweet little service that if you write books out in the open, they get published openly. And so, it's all in markdown. It's basically, which is flat file then, right? You just got lots of hashtags and things. And then you can publish it out to GitHub. Well, then we went, okay, well, how do we get it from GitHub into Drupal now? Because I wanna take all of this flat file static material and then put it into a dynamic system because that dynamic system is how we deliver it to our students. So, in the process of getting off the island, I found this library called just Git.php, which seemed way too good to be true. I don't understand how it works, to be pretty honest. Because it doesn't involve exeC or any security implications that typically would come with running a command line task in this way. But it lets you have things like this where you say, hey, you require Git.php. And then you can just say like repo add, and that's gonna add everything that's in version control on the system, right? So, it gives you an interface between php and Git to easily run commands in Git, but from php. So, now there's modules for this. There's Git.php module, which encapsulates the library, right? So, you could use it for whatever. And then we wrote the Git.book module. And Git.book is different from the actual Git.book website. What the Git.book module does is it gives you the ability to invoke a parser, which would be like, hey, in this case, I'm parsing something called Git.book. But so that way you could target a different data structure to import. So, for example, is anyone familiar with read.docs? Okay, so read.docs is a documentation thing. You do your documentation and mark down, and then it publishes out to this nice little mini site. There's a parser for it in the Git.book module, so you could point a Drupal site at the VAT and ingest the whole thing and turn it into nodes in a Drupal book, which at that point, do whatever you want with it. So, showing this workflow, let's lay it out. Someone not using Drupal at all, this is a Git.book interface. And so this is what you end up getting, right? You've got this content outline. These are all markdown files, very simple navigation. And then we want to go from that to GitHub, so links it up there. So now you can see the flat files that were generated and all these MD files. All right, so the folders help with the nesting to imply like, okay, well this is down hierarchically under here. Then on the Drupal side with the module, you get a content type called Git.book. And so you plug in, just point at the repo, it ingests the repo onto the server, and then uses the parser to run through and convert all of those into nodes. You can pick the branch or tag to use. And there's also some early work on two-way syncing so that you could theoretically edit in Drupal and push back to a flat file system. And so now this outline has entirely been built based on the work that's going on on GitHub. And then we've even got a little markdown editor provided by an editor called Epic Editor. And so then you could just keep writing and markdown in Drupal, save, have it ripped back to the file system, and then sync it back over to the other side. This is just showing at the end, hey, that's on the private files directory. This is the Git repo that we pulled in, in that case. So it's pretty cool workflow. I really like the workflows that that actually opens up. We've been talking about taking content that we have in Drupal and doing this to all of our courses so that we would funnel them out into flat file, even just as a backup mechanism, quite honestly, or version control, beyond having to go through and do diffs, right, and use the diff module to visualize everything, which is great, but still database-driven. So these are a bunch of links to that. Every incarnation of Git hyphen and Git period and Git. Okay, so last one of mine is Jarvis make me a coffee. Jarvis make me a coffee. Has anyone seen me do this before? Okay, good. Would ruin it, otherwise. Okay, so the desired outcome is have a conversation using native browser technology. Has everyone seen Dries talk to Alexa before? Okay, I don't want people to have to own an Alexa to talk to something. Okay, that's the idea. So let's make Drupal into Jarvis. So like that. And so how would we go about doing this? Well, we need two different modes of communication. I need to talk to the browser and it'll understand me, and the browser needs to talk back to me. And so can I use .com to the rescue? There's the speech recognition API, it is actually in development for the browser as a way of brokering, okay, you can accept media input as someone talking in recorded text, and then funnel it to whatever service you want. So obviously Google has one of these. And then return confidence scores and things like that, right? So that you could build these types of Siri-esque interfaces in the browser. And so this side of the spec is really obviously low priority for a lot of people. This demo only works in Chrome, unfortunately, on that side with the speech recognition and Opera, because they're pretty much the same at this point. Firefox, you can enable a flag to do it. But speech synthesis is actually really easy now. And so there's a lot higher browser coverage for that, for having the website talk, because if you think just native operating systems already have a lot of that voiceover support built into them, it's really not a logical leap to then wired into core browser tech. So again, getting off the island to the rescue, there's a library called Anyang. Anyang is this neat little wrapper on top of speech synthesis API that lets you just basically invoke like thing.speak and then type a word kind of a thing that you're listening for. And then if it matches that word, then it fires a JavaScript handler. And so there's a module for that, obviously. There actually already was a module for this before I started exploring this. It was called voice commander. So then I just, I made a 2x version of it that takes it a little further than it did before. But the way that you can then integrate with voice-based commands then is, so this uses hook voice command. And so you see I have kind of this array of the phrase that we're gonna listen for. And phrase could be like almost a trigger word, kind of like Alexa or Siri or Google, right? That trigger to invoke listening or paying attention. So you can include one of those. And then anything in the brackets is, or parentheses rather is like optional, right? So if I said like Hey Elm's play would be the equivalent of Hey Elm's play video, in that case. And you can do other tokenized input like that. Then it's just tapping a JavaScript function on the other side. And so that you can see, dribble not voice commit dot say, and then whatever you want it to say. So that's the talk back to me. The other side is the hey, whenever you match this word, I need you to invoke this. So wiring this up to a whole interface then. Scroll. Next page. Next page. Previous page. Back. Forward. Hey Elm's. Anything I can do for you Admin? Open preferences. Alternate formats. Open speed reader. Speed reader play. Close. Next page. Scroll. Read to me. Since this week will likely involve a fair amount of waiting for people to. Elm's, what is lecture? From Wikipedia Colonia lecture from the French lecture, meaning reading process is an oral presentation intended to present information or teach people about a particular subject. For example, by a university or college teacher. So that last part, there's a blog post for it says making okay Google. That last part is then tapping into another project called Puzzler, which taps into the Wikipedia web API. So then I have a trigger word for, hey, define what is, right? What is is the key phrase it's listening for? I also, because the question would come up anyway, there is a way of putting this into continuous listening mode, which is how I'm not invoked. So you're just talking, right? It's also affectionately known as letting the NSA listen in on literally everything you do on a webpage. So yes, both, and yeah, we're aware of that. So normally you hit two keys to invoke that to happen, right? As opposed to just letting it run all the time. But I do usually just let it run all the time because I'm really lazy. But that last part is tapping Puzzler and Puzzler is hitting the Wikipedia API, finding that word as the query, returning if there's any result and then using speech to then say the thing at the end. But the problem is that the name of this was make me a coffee. Make coffee. Why don't you get me a coffee? I do all the hard work anyway. I'll have a venti americano with six shots of espresso. It was a rough night last night, processing all those rosters. So you can do, obviously there's lots of Easter eggs in there. I'm not gonna put one in for Konami code because you know, saying up, up, down, down, left, right. That'd be a little extreme. But if you wanna learn more about those technologies, that's the voice commander module and Ann Yang. And then there's the turn your site into Google Home, which is wiring a whole bunch of different things together. It's a neat little case study. Now I'm gonna turn it over to Michael Potter. Yeah, I'll try to fall that one out. So all right, so now the really cool stuff is why you're all here, obviously. So how many front end developers out there? How many people implementing headless stuff? Thinking about implementing headless stuff. So I'm gonna take you through a little journey. So as we said, we run ELMS as an amazing system self-federated system that talks to one another. So naturally what we do is we get these crazy ideas that come across our plate. In the College of Science we get a ton of crazy ideas. But that's what we love. And over the course of these ideas coming to us, I'm saying to Brian, we should just make apps. We're taking Drupal to the absolute limit. What these people have in mind are applications. So I think we need to start making applications that layer on top of Drupal. And so Brian said no, obviously. And then I begged him and okay, he conceded. So here are our desired outcomes. So what we wanted to do was change up the workflow a little bit. So we wanted to use a headless development workflow. So that's the big word, the buzz word, right? But it really is a really cool workflow. It will really change your approach to developing web applications. So we knew that that's what we wanted to try out. And the reason was obviously to create a better user end user experience. So again, what these people really want are Google products that are sitting in their courses. So. Made by one person. Made by one person, the team of one, right? All right, so what we decided to do was obviously we needed to get off the island a little bit and explore some frameworks out there. We were pretty familiar with AngularJS, which in layman's terms is Angular 1. Don't say AngularJS anymore to an Angular developer. It's a touchy subject. So I did a lot of research and I really liked what Angular 2 was doing. It's a very opinionated framework. And I think that to get ramped up, going from not having done any of this to doing a full application, we needed some guidance there. So we picked Angular 2 and we went with it. And within a few weeks, we had a pretty good working demo. So this was an idea to build on top of an existing profile in our system, which is the assignment studio. So the instructor would have a place to go and easily create projects, easily create assignments within those projects where the students could go there and have a really slick interface to add blog posts and comment on each other's work and share files. Obviously this brought in state management issues. So went with Redux, which is horrendously complicated, but works very well. So this is what you get whenever we're talking about improving the developer experience. Look how cool this is. I can then upload my Redux file here and then I can fly through the, I can time travel back in time. And it's cool. So this gave us a really good win. We were easily able to crank out this demo for the instructor pretty quickly. Everybody is really excited about it. We go and we implement a custom API because for headless applications, you need a really good API. So we spent countless hours debating and designing and what format to go into. But we got that all figured out. Angular has a really good CLI. So naturally we started using that, has webpack, it does all your bundling and everything. Tree shaking, which is a thing. So then naturally we learned TypeScript then to make everything a lot easier. So we learned that whole new language. So this is our assignment and I see all of the properties and they're very well-defined and my application knows exactly what's going on. I have a services file. So this is where I'm telling Angular how to connect with Drupal. And it's in one place, so this is assignments.service. So I know what to do there. So then we had to use Redux, which Angular has a specific version for this. So this is NGRX, that is Redux built in Angular. It gets better. So you set up, you learn Redux, and you set up your reducers. So this is assignments.reducer. Okay, and then you create your reusable components. And this is the cool part. So these frameworks, you can create reusable components and you can build components on each other and reuse them. It's super awesome. So this is assignment-list.component.html, where every time I use assignment-list, it will render this template really easily. Naturally, since we're using Redux, I have to tell Redux, I have to tell my application that Redux noticed a change and it needs to tell Drupal because they need to be communicating. So naturally you do that through Redux effects. So that's assignments-effects and you put all your effects in there. And then you compile it with the CLI. CLI is really nice, it takes care of all that. So you get a disk file. You get about 25 files. They're all minified and bundled and stuff like that. It's really slick. And then you import that into Drupal. So you create a module and you loop through the disk directory. You find all the files, you have to put them in the right order. But you import the files and then you create your... Oh, we have to add the app, that's right. So hook menu at CLI, you give it a path and then you put app-root and then you reload the page and you have an Angular application running inside Drupal. Yes! So... So let's cover the pros of this approach. Can I see my water, please? You can applause too. So we did that over the course of four months. So the pros, we can definitely create the app experience. Angular knows what it's doing. It's built for that. It's perfect. Clear separation of concerns. Drupal as an API is a pretty cool concept. It makes keeping your logic separated so you don't have logic leading over into the front end and vice versa. You can create the well-designed API that you're looking for since you had to spend that time. And Angular 2 is really awesome. It's a lot to learn, but TypeScript is pretty useful. The CLI is definitely very useful. So this workflow is obviously not ideal, right? You have to maintain two different frameworks. Angular is a beast and it takes a long time to grok. So Drupal is the same way. So you have to deal with that. Going mostly headless is difficult. So as you see, we had an application running inside of Drupal. That brings a lot of workflow issues, as you saw. But going completely headless is also very difficult. So as soon as you start dealing with dynamic forms for the first time in your headless application, you're going to rethink everything. And so obviously you need to create a new development workflow that fits what you are trying to do. So what did we like? So we had a lot of lessons learned from this. So separation of concerns, as I said, Drupal is an API, we really like that. Headless theming, it's so awesome. It's really cool. Unidirectional data flow, whenever you get into component architecture, you'll pretty quickly figure this out. That managing state is ridiculously hard for some reason. Component architecture being able to reuse components and be able to design components specifically for one thing and knowing that they're going to be reused in other components. Documentation, so whatever you choose, make sure that you can rely on documentation. Angular has really, really good documentation. Like I said, I got ramped up with Angular 2 in like three weeks. I was building the first prototype, which with everything that has changed in Angular is pretty cool. So this is the end of the web as we knew it. This is the new design paradigm that we knew that we had to figure out how to do. So our desired outcomes for this. Create a headless authoring environment, streamline theme workflows, make content modeling design first, eliminate as much Drupal theming as possible, eliminate the theme from blocking upgrades, which was also very big for us. So in other words, save Drupal, right, cliche. Yeah, but how? All right, so this is where you guys start cheering too. And inside this is like, this is so happy. So we think that this is the solution. So web components. How many people are familiar with web components? Awesome, cool. Before I dive into web components, I want to sort of lay out some groundwork here. So whenever I say web component, I'm not talking about Pattern Lab. I'm sort of talking about Pattern Lab, but I'm not talking about Pattern Lab, and I'll explain. So what Pattern Lab does is, first of all, Pattern Lab is amazing. It's awesome. If you're building in Pattern Lab, two thumbs up. What it's doing is it's forcing you to build components the right way. So building components down to their absolute, what are they called? Adams? Oh, it's on the screen. Okay, yeah, it looks like this tiny. So the smallest point you design for that, and you keep building, you keep building, you keep building that, I think that that's the perfect way of going about it. What Pattern Lab doesn't give you is it doesn't give you a predictable API. There's no API in that. You're designing it the correct way, but these components aren't smart. They're just markup, right? Web Components is a spec. It's going to be a standard. It's already here. So what Web Components are, they're a set of APIs that allow you to create new customer-usable encapsulated HTML tags in the use of web pages and web apps. Sounds like Pattern Lab, right? But the API is the key point. It's the key difference. So let's take an example. So awesome explosion. So let's say that you wanted to create this awesome explosion on your website. So if we were to construct this in Web Components, we'd want to use a new tag, like a div or a span. We wanted to create our own awesome-explosion. Anywhere we use this, this explosion shows up. So now picture that we want to manipulate it a little bit. So we want to say you can change your size, too. So you can say size tiny, your size small. What if you wanted to change the color? What if you wanted to put HTML content inside of it? And really importantly, what if you wanted to notify your website that things were happening inside the component? So this is what we mean by an API. It will have you can define properties on your components and you can emit events from your component. So a parent can communicate with a child through properties and a child can communicate with its parent through events. And that's the unidirectional data flow that I was talking about. So the Web Components spec, it's made up of four things. Templates, custom elements, Shadow DOM, and HTML imports. So as you can see, Chrome and Opera, they've already implemented it. So you can use these without any polyfills right now today. So the rest of the vendors are still working through it. They have, to my understanding, they're all on board with this concept. They're still working through the minutiae, like HTML imports. Some of them aren't sure moving forward that that's the best move, so they're still discussing it. But we can use Web Components right now. So there's a project called Polymer, and it's by the Google team. And the purpose of the Polymer project is to get people familiar with building websites with components, with Web Components. So it's polyfills to make sure it can run in every browser right now, so you can use them today. It has things like lifecycle hooks to make them easier to work with. And some syntactical sugar stuff built on top, sort of like how jQuery is to JavaScript. So as an example of something that was just built, the new Google Earth was just launched, built entirely with Web Components. So if you go there and check it out, right-click on it, and you'll see a whole bunch of Web Components in there. So let's walk through an example of what this might look like and how we can fit this into our workflow. Oh, I'm sorry. So in February, was anyone at Drupal Camp, New Jersey? In February? So during the sprint, we had talked about this concept. We were seeing how the Angular app was getting, and we were trying to come up with some alternatives. And we took a look at Polymer and we said, you know what? I think this might work. Let's see if we can try to get some prototypes working. So within about three hours, Brian just wrote the module. So thank you, Brian. So the Web Components module on D.o., and the Web Components module is pretty slick. It does a couple of things. So it tells Drupal how to import these Web Components. But then what it also does is it reads the properties that you define on your Web Components, and it creates them as entities in Drupal, which should get everybody very happy. Thank you, Brian, again. So let's look at an example. So this is our Drupal site, and we have an article, and this is being rendered by a view. And right now it's just rendering the teaser view mode, I think. So how would we get this rendered through our Web Components? So first we would create the ElmZellLand-hero Web Component. You can really easily do this with Polymer. They have like a little tiny CLI that scaffolds a bunch of stuff for you. So inside of that one file, we had those four things that we talked about. We had the HTML imports. We had the template. We had the instantiation, the custom Web Component spec. And then we have some Scoped CSS. And what that will give you is through the magic of Polymer and its CLI, it will take that file and it will create some documentation for you and some demos for you, which is pretty cool. And again, this is just in one folder. So what Polymer will do is it will create a folder for you. It will create the ElmZellLand-hero file as well as some tests and a demo file for you so that you can really easily communicate and share this Web Component. So the second thing that you'd do is you would turn on the Web Components module, obviously, that has a couple sub-modules, like interacting with Display, Suite, and Polymer, as well as setting up some Display modes. So what I would do is if I didn't want to touch the template files or anything, I just wanted to go... I just wanted to really easily wire up my article content type to my ElmZellLand-hero Web Component, just in the interface. This is what I'd do. I'd go to Manage Display. You can see a bunch of view modes. Those are all Web Components. So these are the Web Components that it found in the Web Components module found in the Web Components directory. One of them is ElmZellLand-hero. And if you notice, it automatically picked up on those properties that we defined in the HTML file. So we can read those properties. Since it uses that really well-defined API, the Web Components API, it knows that we can read off properties. So what you do is, for each one of those, like any other site would display suite, you just drag your fields into place. So the image goes into the image field, and the title goes into the title field, etc. From there, like we said, we were displaying that article through views. You would just change the view mode to ElmZellLand-hero, and bam, there you go. So what we did was we completely bypassed the Drupal theme layer. Without coding, or without doing anything in the templates or anything. We just told Drupal, these are the properties. Here's the fields you should send into those properties. The Web Component will handle the rest. What do you think? Very cool. Which method would you rather do, the angular version or that version? All right, so the pros of this approach. Separation of concerns. Yep, headless theming, absolutely. Unidirectional data flow, yep. Component architecture, of course. Documentation, of course. And the big one. This is the game changer. Framework interoperability. This component is currently being used, could potentially be used in all of these frameworks at the same time. So if you wanted to update the ElmZellLand-hero across your entire portfolio, you could change it one time and it would update. Pretty cool. So the cons of this approach. Obviously browser support. So if you are doing anything under IE11, it's not going to work. So you have to make that decision. So that brings us to what we were talking with Save Drupal. So what are we saving Drupal from? So has anyone seen this? This is Gutenberg. The Gutenberg demo from WordPress. Pretty slick, huh? So this is like an in-place editor. You can create different stuff. You can change the heading. You can push this wide and off to the side here. This is pretty cool. So it's just a demo. But this is what we're going to have to compete against in the near future. So whatever you're selling, Drupal, your clients are going to show you this and be like, well, can we do this? So can you? So we definitely can. We think that if we adopt web components and we learn from the other communities that are also contributing to web components outside of Drupal, we can bring it together and come up with some really cool solutions. We started a Git repo called LRN Web Components for their Stanford Learning Web Components. And what we did is for these web components, what we said is they're going to have a design and they're also going to know how to edit themselves. So let's take a look at the panel card. So this is just a card that you could throw on your website. But what if this were inside the body of your website and you could hover over it and you could, let me put that up a little bit, you can hover over a little edit thing and you could in place edit that and you could change the color. Oh, that looks good. Change the elevation. Oh, that looks perfect. I'll go ahead and hit save. So this is what we have in mind. So each of these would have their own edit state. The Drupal website would only be in charge of putting these components into their edit state. You would edit them whenever you click save. These components would, through events, notify Drupal, hey, I just updated. I need you to go ahead and update the content that I'm on via RESTful Web Services. We can take a look at, here's a block quote. So again, changing properties, like that outset, yeah, that looks really good, okay. We can show like a little off-screen canvas thing. Yeah, that looks really good. I'll go ahead and save that. So this is what we're thinking. I think we can build our Drupal sites, including these web components, so that we can start giving our users these really slick interfaces. Oh, the icon didn't show up. So Drupal doesn't have to know about this. This can all be off-loaded on the browser, which is really, really cool. So forget about like the plugin architecture of this one JavaScript library has to have a plugin for Drupal and for WordPress. If it goes through web components, it will be interoperable. Presentation. So here's some relevant links, webcomponents.org. It's a library of web components and open source developers and huge companies contributing their libraries to web components that you can use right now, and we are using right now. Polymer project is definitely, if you want to get started with web components, I highly recommend that. We have some posts on Drupal.org and Drupal.phu.ddu and ElmsLn.org about how we might, how we're thinking about using those. And really important, I hope that if you're interested, please come to our bot tomorrow because there's a lot of things to think about. There's a lot of things to consider and talk through, and we definitely want to hear your thoughts. So, and maybe build some web components. So that, that's what we have. Any questions? That guy. Yes. So great presentation, great job, both of you. We saw at the end there a couple of components where the focus seemed to be on the editing process. Yes. So I kind of, okay there's people behind me now. Two questions actually. Have you looked into creating components that dealt directly with Drupal's API-first stuff? And have you looked at more administrative side components? Actually hooked those edit states up to a back end of any kind yet because we're just trying to focus on what would the UX patterns be if we had just a totally native experience for them. I would see the plug in, the hook up to Drupal being similar almost to the edit module from Drupal 7 land that got port, that is in DA core with the in place editing as far as, you know, find something, put it in that quick edit mode, make the change and hit those API endpoints or something like that. What was the second question? Other administrative side components. Oh, administrative, we haven't, haven't really. For example, the settings paint. So. But they're adding in a Drupal 8.4. So no, we haven't looked into the, into those, but I mean. This is the application that works perfectly for us. I mean, they are, so another thing that was in show, I had to add, last week before we were leaving, I had to add an administrative dashboard to that angular app and I tried to do it the angular way and it just wasn't going to happen or flow. I didn't want to touch it. So, I created a polymer component that retreated the list of stuff, added some, retreated the list of submissions, added some settings and some administrative functionality and I implemented that in a few hours. And that, I think if we can, the administrative panels in Drupal, I think it's perfect for. I just, I think it's way better than going with another framework. Another, you know, large framework to solve that problem. I think it's perfect for that. I was just wondering, do you have the web component module ready for D8 already? So, that was why I said, oh, yay, you talked to the microphone. So, he's been working on porting it to D8, which I, have you used it yet in any regard or? No, still need to work on it. So, we're sprinting on it. Yeah, there's a D8 dev branch for it, but yeah, I mean, then if really all that that module's doing is bridging, is scanning it and bridging the entity, skimming it off and turning it into entities, as opposed to doing any real deep design integration. That's the goal. Great job with your presentation. I just wanted to ask a question about the hero component. Was that a new field type or just like a template for the image field type? So, the image specifically was in the hero. It was just an image field and I changed the formatter to output it as just the URL because the web component itself was just looking for the image URL. Okay, so the hero component was just a formatter for the image field type. So, the hero, what the web components module did was it recognized that we had a web component named hero and created a view mode for it. So, within that view mode we specified what fields should render through which properties in the web component. So, think of it like view mode. So, each view mode is a web component. Wonderful, thank you guys. Sorry. Going back, Brian, to XAPI and you gave the example of video. Yeah. Video triggering actions to XAPI are using like a the video player's JavaScript API or how do you detect start, stop, pause, jump ahead? So, there is a... I don't actually know if there's the TinCan API underscore media or video... I think they support media module natively and so that then it's wired up to the player, to the HTML5 player and it's listening to the HTML5 events on the website. The example shown in that little demo that's from YouTube. So, it's using the YouTube API and basically the workflow is replicate, mirror the event and then reroute it through a like TinCan submission type of thing. The H5P module works that way as well because the H5P module is it's going, I have an event and then the TinCan thing is like but then what it does is it sends it back into Drupal via a system Ajax call and then that callback sends it on the back end over to the LRS. So, using that work, we've basically been doing that with everything that we integrated with. That also starts to play into the web components side of things because we could we're talking about making a like X-API tag. Literally all it does is like, hey property who did it, right? And if we pass that stuff in now we start integrating X-API even easier than it already is it's already pretty easy to integrate X-API. There's so many libraries for it but... Where can we find the presentations or the material? So, almost all of these have blog posts of some form associated with them on either drupal.psu.edu or this website that elmsln.org in the blog section. The presentation is a whole, we have to it's too big to upload to the website directly but we will put it up there probably putting these on YouTube or something. So, the presentation will be up there, yeah. And it's recorded too? Yeah, this is recorded.