 Good afternoon Vienna. Thank you very much for having me and thank you Sarah for the introduction again. I'm catam I'm really really honored to be here particularly to follow someone like Nathan on this stage And I'm here to talk today about interfaces, and I didn't pluck the sense. Let me do that now Yes, we'll just do this way But before diving into code, let's start by asking a question. Why do we use WordPress? Because it was there because when we started doing what we do it was the choice that was available to us or Because it did something better than the other options. We were presented Was it the devil we knew when we came back to it for more? Was it just the only thing we felt comfortable using or was it that it solves that problem that we had again perhaps? Or was it perhaps that it was flexible that WordPress is a tool which we can use to build Whatever we want that we can adapt to various purposes I think that this is it that if we sat down and talk about why we stick with a 13-year-old piece of software It is the power of flexibility and the power of ownership and Customizability on top of a stable foundation With permissive licensing a practically limitless array of themes and plugins and this goes without saying in a room like this an amazing international always growing community WordPress is something that we can use as a platform for whatever we can imagine and That breadth is not accidental WordPress is a core product as we've been hearing this week is designed with focus yesterday and Mike Schroeder shared the development Philosophy that stated on wordpress.org WordPress should work out of the box It's designed for the majority and the core product strives for lean simplicity and my personal favorite precept is to favor decisions over options Every time you give a user an option the statement goes you're asking them to make a decision and decisions take cognitive energy away From what they came to WordPress to accomplish Nobody installs a piece of software to customize it They install it to get through the customization that has been forced upon them into be able to achieve the goal that they set out to do Those decisions that focus the ways that we can make those flows easier for The authors and the content creators that depend on WordPress for their voice is what makes WordPress so focused and so stable Plugins and themes can stand on top of this platform and can take it in every direction that we have heard today And that we know from our own development practice and from the greater community as a whole It's decisions of the platform level that enable the kind of choice a user needs Which is to be able to say I want to use this thing for my bands my blog my cat photos To publish their content in any format they want and We're gonna talk today about the different layers of interface that stands between a user and us and as us as developers and WordPress focusing on the API The three layers are the API itself the user interface what the user is going to be interacting with whether that user is a Writer or a reader and then the glue the user and the client libraries that hold them together as You heard who was in Joe Hoyle's talk this morning by the way Awesome, probably the majority if not I strongly encourage you to sit down and take the time to sit through it He gives a tremendously good overview of how the API is structured and the history of the project It is a reductive project it strips WordPress down to its barest essentials Which is data WordPress is a tool for personal publishing which means that it is a tool for storing and retrieving content That content is what unifies the two interfaces of WordPress the public facing Website the reading interface and the authoring interface the WP admin The API exposes that data really without a lot of preconception about how it's used beyond these Concepts that there are these different modes of authoring and consuming The API was designed to become a core component of the WordPress platform But I think it's actually going one farther and what I'm going to be talking about today Is how the API makes WordPress a component itself something that can be integrated into other systems WordPress is a platform, but that platform doesn't have to sustain your applications full weight You can leverage other technologies and other tools now that you can flow data more regularly between the two I Work for Boku. We are a semi-distributed technology and design consultancy with offices in Boston in New York City over in the States And as Sarah said we focus our mission is to advance the open web as a platform for technology and collaboration We build open-source projects like grunt and the node robotics library Johnny five My colleagues are on committees like the responsive issues community group and TC 39 the group that's responsible for the future of the ECMAScript JavaScript language specification We take this open-source experience and then we use it to help our clients solve problems And those range from we have data and we need to understand how to visualize it and how to make decisions based upon it all the way to What we do have a greenfield project. We're not dealing with legacy software anymore What technology should we use and that's an interesting one because and I stole this slide from Helen because it's by my co-worker Sue and it was way better than what I had when I put my slides together this morning For all of the different ways that we can successfully build a web application Wordpress is not something we find ourselves recommending a lot and that's not because we don't love it We think it's fantastic. We use it for our own site I have contributed to it in the past a number of my colleagues have as well But it's because frequently our clients are coming to us with an existing platform Wordpress has become a platform, but two platforms tends to be a recipe for interoperability issues silos and fiefdoms and I see the API is changing this because when I first started using it in the winter early winter of 2014 I was able to confidently recommend to one of our beggar clients that they considered using WordPress for a Big project that they had and I was able to suggest that they do it not because it would be the platform But because it would be something else We were building a not complex node.js application that pulled together a number of different services and data sources and Several months into the project we uncovered this requirement for a blog and for some fairly complex editorial workflow This was spring in 2014 and the editorial capabilities our client needed exceeded those of the node options that were available the node content management systems however as a Interested member of the WordPress community and as a front-end developer anything that gave me Jason access to WordPress was exciting So I've been following Ryan McHugh's Google summer of code project the summer before and we pitched our client this idea that maybe The best node CMS for their application was in fact an 11 year old piece of PHP blogging software For a project like this using WordPress as the base platform would have been a very hard sell There would have been a lot of opposition to it at the organizational level on their side because of preconceptions about what it's capable of I have no doubt that we could have built the system that way, but it also would frankly have been very hard There's a lot of legacy code in WordPress There's a lot of things that make it difficult to integrate with certain types of external system We had picked node because it was good at aggregating content from a number of different sources WordPress became just one more of those it became a drop-in and as a drop-in as a free battle-tested usable accessible content authoring interface Just dropped right in perfect place in our application. I was told they had to include a mention of this Most of the work I've done with the API has been in this mode taking content from WordPress that was authored in the admin and flowing it into other systems this link on the screen is Demo that I put together for the day of rest back in London in January Which uses that same architecture that we used on this project to actually let you author content in WordPress and display it in a ghost theme The node CMS so if that's interesting check it out and this is a long way of saying that I really love this thing WP admin is accessible. It is battle-tested as I said for some applications. It's definitely the best thing going it works If you turn JavaScript off That is really really awesome That's something that we need to keep in mind as we're building robust JavaScript interfaces is that these things will fail What's our fallback? But because we are familiar with WP admin and because we were familiar with our frustrations with it I do think that it biases are thinking about what might come next This has been a good conference to think through both within and without the admin since the API gives us this idea that WordPress is The content without these constraints of these existing systems So let's think past our preconceptions and think about Maybe briefly what types of authoring interface might be enabled if we start thinking about WordPress as the data and not as a Legacy interface that we are customizing. That's not to say that any of the things I'm going to be showing are not possible I was really impressed yesterday with the readability score real-time updating thing that Yoast showed from the Yoast SEO's plugin You can do a lot within WordPress admin and I know that a lot of the people in the room here do But I think that we can all agree that there is a certain friction in using that old system And so other things like taking that same idea about how could we build a journalistic interface that Let's us do content sentiment analysis. Maybe scan for biased language These things can be built in WP admin, but they can be prototyped as external interfaces Maybe you could use some of the awesome front-end editor technology that Eric Lewis was showing yesterday This is a project from the University of Ontario Institute of Technology by Chris Kim and Christopher Collins Which has been a research project to categorize in English language the color connotations of words So that finally when a client comes to us and says I just wanted to feel more blue that we finally have an answer for them Because we can just use blue words WordPress is a tool for putting words on a web page, but not all types of words benefit from a Unified interface what would a WordPress interface for poets look like what types of poetry would be enabled by an interface that aren't possible On a sheet of paper. I've been really inspired by the work of a poet in New York an experimental computer product named Allison Parrish She's done a lot of really fantastic stuff both in the work of interfaces This is from a project she did called the new interfaces for poetic expression both also in Twitter bots and things like that This is the entropic text editor It has a foot pedal that as you press down the keyboard gets less and less reliable And what you're typing gets less and less like what ends up on the screen. So it's a playable poetic interface Or maybe we can do away with the creative part of creative writing at all and we can just let it Regurgitate our past writings to us I've been really excited and some of the energy recently around machine learning and artificial intelligence wired magazine did a great Article about it's a little sensationalist, but a great article about machine learning and AI recently I spoke alongside Wired's director of engineering Kathleen Vigno at the day of rest and I knew that they use the WordPress REST API So thinking about what can we do if we look at the content in our system as data? I pulled all of that out and I fed it to a recurrent neural network If you're new to machine learning a neural network is just a fancy pattern recognition tool But it can be reversed Rather than saying detect text like this you can actually say generate text like this So this is how Google's deep dream works in a nutshell I wrote a quick script to generate headlines from the sample input text which was a corpus of a couple years of wired headlines and Gave it an interface where I could type a couple words and it would fill them in for me And it talks about the sorts of things you'd expect wired to talk about surveillance Android luxury email I love this last one Here's some more headlines. I don't know what they all mean, but they're in the mode of wired and This is a little bit silly, but I think particularly the Giant what's what's it go the Turning great will drive action video as an American in 2016 that one's particularly frightening Content theft is a definite fear people have about having an API in core And I will Disclaim that I think this falls under fair use and I ask Kathleen's permission to present this use good judgment Obey authors licensing terms and throttle your mass downloads so that you don't DDOS yourself and others if you are taking content from WordPress sites This is basically the same as when we had RSS. There was a lot of uncertainty and doubt around that technology, too It proved to be beneficial in the long term, but there is responsible use and it's on us to be good web citizens and good collaborators So generative or destructive textual interfaces are probably not going to get someone to switch back to WordPress from medium But I think that this is the right time for this type of experimentation saying like what if my text editor actually destroys what I put into it I don't know. Maybe it could be interesting Experimentation is important it gets us thinking beyond our preconceptions around the sorts of users and use cases that we've been accommodating and I hope you all saw Matias's talk on Calypso yesterday and you see David's presentation this afternoon on their team's working methods Because Calypso is designed to be a framework for this type of prototyping and what I'd like to ask you to do is to go and build Not just one Calypso, but two or three or seventy specific Calypso's niche Calypso's Calypso's for your partner And then take the lessons you learn from those experience and keep iterating on what an admin might look like We have the simplicity of data access that enables us to do this very quickly As has been mentioned a few times this week WordPress is a teenager now And we need to give it some room to grow to experiment and to make mistakes Things are going to be very awkward and very messy for a little while But I think we will all come out of it stronger and more mature and more capable of dealing with the world that is ahead of us I don't like that metaphor anymore So digress quickly the difference in API based UI development is that it lets you pick your battles There's this thing learn JS deeply But you can bring your own tools to this fight and you can build a competent AI powered Sorry API powered interface with whatever technology you're comfortable with you can do it in pure PHP You can do it in any JavaScript library. There is no one perfect solution to this problem and As Sarah said, I didn't study computer science. I learned to develop through this community I think that a value of this community is in helping people get into this stuff more easily So I'm gonna blaze through some work that we've been doing around Making intuitive interfaces for the rest API as a way to make it easier to get involved as a new developer On that project I described we wrote a lot of code to make this transition between node and the API work Boku we value open source. We value contributing back So I released this as a module on npm of the WordPress rest API and excuse me This is a code interface the next layer between the UI and the API something that will let me Focus on the problems that I care about when I'm building that user interface that is going to be leveraging this data And it does this by being a query builder If we think about WordPress as a remote database that we're communicating to you through the internet This type of interface this chaining interface fluent interface is something that's frequently used to describe a resource You want to get from a database. We're doing the same thing We build up a URL using query parameters so that we don't have to deal with the nuances of particular query parameters and array bracket notation, etc And then we can request that or create new material or update content in the system and do it all asynchronously through JavaScript over the web But where do these base resource methods come from the posts and comments and such Originally, they were hard-coded each as their own separate constructor But as Joe showed earlier today the API is built to enable discovery it describes its own capabilities Over the winter I met with the API team at the day of rest events in London and Adam Silverstein And I met with a group of people who are talking about challenges for API clients not the API itself But the libraries that consume it and the things we determined were two most major needs were tackling authentication Which is a pain and you will note I'm cleverly avoiding any further mention of in this talk and discovery How can you create a client library for the API which permits users to specify their own arbitrary endpoints and use them fluidly? And to do this we can take this treat this list of routes that the API exposes and we can decompose it into a tree structure And then we can walk through that tree structure and infer Setter methods from it and this is what we've done the entire API that this library exposes to talk with the rest API say API too much I think is Inferred dynamically from the description of itself that the rest API gives us which means that any new Resources that you add to it Can be added in in the same mode the same way that you would register a rest route you can register a route handler in this Paradigm by specifying the path at which it would be found and then you can query against it But we can do one better because we can actually go out and we can dynamically download the capabilities of our sites and Generate in real time the interfaces for them based on what they expose so in this case I've added a wp.discover method, which will go in it'll download the endpoint URL of the site It'll pull down all of the routes for it And then it will generate these Interfaces so that I can get both the default and also any custom routes that are registered if I don't want to make that round trip HTTP request I can save that JSON locally and use it to bootstrap right there on my page and This was released today the final auto discovery code was written during this conference and Try it out see if there's anything we missed or any like late-night conference coding that let bugs into it but I would like to give this to this community so that we have a way to Hopefully make it easier to say like I just want to get something from the API to see where this is going and in that regard We're also looking for Assistance because there's a lot left to do I'm hoping to move this over to the WordPress API Organization on GitHub soon possibly as soon as I can find Ryan after this talk But we're also interested in people to use this to try it out to see whether it works I would not claim that this is the perfect interface for WordPress But it is my effort at putting something out there that will make it easier for us to interface with the API so that we can build better interfaces for our clients An interface is a choice. It's a decision about what to expose and what to hide and I Would never imply as I said that this is the perfect interface, but it isn't really about User interface or even the API interface It's about how easy it is for us to get started and use it and build it to make things that are real that actually benefit our users the uncertainty about when these end points are going to merge into core is Miscommunication which is common in open source projects, but they're very close We've got v2 coming up soon for the plug-in I think the end points themselves are very solid authentication is almost there and What I'm hearing is that the barrier emerges the lack of usage and that's the one thing where I will say I think that it's hard Enough to get someone to install one plug-in getting them to install two saying you have to install this other thing for this to work I do think that's a bigger barrier to entry than we make it out to be and so I'd like to see this merge sooner Rather than later, but I think we're on our way there and I'm really excited about it because once this data Once these end points are in core that is when our platform is not just a unified platform that we can install with literally one button on Many hosts, but it is a way for all of our data to flow out into the other seventy four percent of the web and Make WordPress a core component of the entire web platform The line of what is WordPress and it's not blurs the number of interfaces and experiences built around it proliferate Some of them are gonna work some of them will not But what does work is going to be what defines what WordPress looks like in ten years Leaving the API end points as separate I do think we should merge them as soon as possible because at the moment it's another thing to force users to install It's another checkbox another option. I think merging them will be a decision. I think it is the right decision I think we're at a time where it makes sense to move forward but This is a robust and solid approach for development for WordPress and the one thing I've not heard anyone say at this event is that the API centric model of WordPress is fundamentally wrong It's just a matter of detail. I am really excited about that I think we can build awesome tools for it and I can't wait to see what we all do with it Thank you