An API for open educational resources – WPCampus 2018 – WordPress in Higher Education


– [Ned] Thanks everyone. I’m Ned Zimmerman, I’m the
Lead Developer at Pressbooks. We’re a small team based
in Montreal, Canada. This is the group as it exists right now. I actually work remotely
from Halifax, Canada, and we have some other
remote team members as well. So I’m gonna divide today’s session into three overarching groups or sections. First of all, an
introduction to Pressbooks and some acronyms. It’s kind of a bit of an
acronym-heavy presentation but I want to define some of those for anyone who’s not
familiar with all of them. So we’ll be talking about application
programming interfaces, APIs, we’ll be talking about open
education resources, OER, and in the second session,
will be a deep dive into the Pressbooks REST API, and then in my final session I’ll come back to some
of the more practical interfacing applications with that API and some of the challenges
we faced working on it and some of our future goals. So just before we start out, to get a sense of what your acronyms are. So, do we have any
instructional designers here? No, okay. Oh one, okay great. Do we have anyone who is
faculty or working in? Great. Anyone working in creating
content for educational? And developers? Okay, a lot of developers, awesome. Alright, so a little bit about branding this whole conversation. We’re talking about books and so, when we were setting
out to develop an API for books you have to start by defining
what you’re working with. Structure, content, context, and so, the first question I want to ask, not to be silly, but, what’s a book? Anyone?
(man laughing) Go for it. Yes? – [Man] A sequence of pages. – [Ned] A sequence of pages, okay great. Anyone else? – [Man] Content that people want to read. – [Ned] Content that
people want to read, okay. So we’ve got content and structure
so far we can talk about. Anything else? (man talking off mic) Okay, so we have a definition
that is our working definition within Pressbooks. And so we describe a book a
discrete collection of text, and other media, designed
by an an author, or authors, as an internally complete representation of an idea or a set of ideas and/or an emotion or set of emotions, that is transmitted to
readers in various formats. So this is our source code. But basically, what we have here is, we’ve got content that’s
structured and that has authorship and authorship is a kind of metadata. We’ll be talking a lot
about metadata here. So the attribution of the
content within the book is a really important
part of books as a whole, but particularly open content. So, Pressbooks, what is Pressbooks? We are a plugin for
WordPress, open source GPL. More specifically, we’re a
plugin for WordPress Multisite and many of your here I’m sure
are familiar with Multisite in the higher ed context. Basically, we’ve got the
ability to create a network of multiple sites. In Pressbooks, what we do
is we take that feature and then transform the multiple sites in a conventional Multisite
network, into books. So instead of a network of sites, you have a catalog of books. Each book has an administrator, it can have authors and editors. All the permissions that you get in a Multisite context apply. So you could have read
access to some books, write access to other books. Some of them may be public,
some of them may be private. What the adaptation of
WordPress for this means, that we have an interface
that’s hopefully familiar to people who are working with it. There’s obviously some changes. So I’ll walk through a few of those. So this is what the dashboard of a book in Pressbooks looks like. You can see some familiar
menu items there, there’s some different ones. You know, we talked a bit about structure. So, we’ve got a structure of chapters here and then we have an organized section, which I’ll like to in a second. But we also talked about the metadata. So one of the key areas of the interface is this book information page, and this is where you input
all the metadata for your book. You’ll have an author,
you may have subtitles, you may have multiple authors,
contributors, editors, translators, reviewers. You will have publication
dates, publisher information. You might have an ISBN
if your book has an ISBN, and you’ll have, very
importantly for open content, licensing information. So, Creative Commons licenses,
public domain and so forth. So that’s the book information. Then you’ve got the organized area and so within this organized area, you have the ability to take
the content in your book and structure it. So you’ll have the front
matter in your book, you’ve got the main body here of chapters and there’s also the back matter. Now, the last piece of
interface I’ll show you before moving on to talking
about the data model is of course the editor which is fairly familiar
to most people for now. So you’ve probably picked up on the fact that these are custom post types. The custom post types that
we have are front matter, so this is in the book
you’ll have your preface, your introduction and your foreword, those sorts of things. Parts are the structuring
elements of the book. So they may not actually
have the content in them but they’re used to
group chapters together and provide overall structure and sometimes you may not
have more than one part, you just have all of your
chapters in a single part. Chapters is a common concept and then back matter you’ve
got afterwords, appendices, glossary of terms, indexes,
that sort of thing. We have one other
(drowned out by coughing) type of book type information,
which is post type. There’s only ever one of those and we just attach to the
metadata for that book, it’s that simple. So that’s the data model in short. We also have custom, whoops. We also have a custom theme structure. Now, the reason for this is two-fold. So, we’re looking at books on the web, and we’re looking at
books in other formats. So for books on the web, we’re gonna need to handle the navigation, than a typical WordPress site. I want to talk about that
in terms of the structure, the structure piece. So I’m just gonna switch over to the (drowned out by echo) for a second. If we look at websites we have, I think you can kind of divide them into two loose categories. So this site here, it’s got pages, right. So if you’re navigating this, you’ll go to where you want to go and the information
they’re trying to find. There’s not a reading
order attached to it, it’s entirely based on what
the user is trying to get from that website. And then if we go over
to the WordPress blog, it’s reverse chronological, and if you get to the bottom you’ll be able to go back in
time and read older posts. So both of those are loose categories that regular websites fall into. Books are sort of half way in-between because you’ve got a reading order but it’s not a chronological order, it’s not a reverse chronological order. So we sort of need to hijack some of the typical WordPress navigation and make it work for that use case. So we have a webbook that includes a cover page, first of all. I’ll go through and show you a live one. So this has got a cover page with the ability to download
the book in various formats. You’ve got your table of contents here. You’ve got some metadata. And so then you can click
through to the read interface, and you’ll get your foreword here, and you can drop down and see thee other contents of the book and navigate throughout it. And this is all responsive, it works really well on small devices and then there’s other
features that I won’t get into like searching things in the
book and that sort of thing. So that’s the webbook and I just mentioned, export formats. So this is the readable
core contents in Pressbooks. It would have been sort of
the problem we wanted to solve when we first created the project. One is the ability to keep
author in a single place and then have a single source
for a variety of formats. So we’ve got the webbooks
which I just showed you and then we have a bunch of other things. We’ve got PDF, for print on demand, we’ve got PDF for digital distribution. We have EPUB 2 and 3, we’ve got MOBI for Kindle devices, and then we have some other formats. XHTML, HTMLBook, OpenDocument, WXR and we also export Common Cartridge files. So, exports in webbooks. The first five years of Pressbooks our real user base was primarily
self-published authors. So we have a software as a service at Pressbooks.com, which I sill run, and that’s where most of our users were and then we started to get a
lot of people taking notice of this plugin and setting it
up for open content creation and asking us to set it up so them so they could run
open publication projects for various institutions. So we’ve got the BC
Open Textbooks project. We have Rebus Press, we’ve got UC Berkeley’s Open
Book Publishing project, Alabama Publishing House at Troy, and eCampusOntario in Ontario, Canada. Let’s talk about open content
and educational resources. I’m sure some of you at
least are familiar with this but basically we’re talking about teaching and learning materials that are available at no cost with attribution, materials and licensing, so that they can be
adapted and repurposed, and reused in different contexts. There are five principles here that are outlined in a document that I’ll link to in the notes, but they’re identified as the
5R Activities of open content. David Wiley was one of the people who was instrumental in
defining these principles. The right to retain, so this
is managing your own content, managing the way it’s used,
stored, retrieved, et cetera. You’ve got the right of reuse. So, the right to use
content you’ve co-created in a variety of contexts. The right to revise, so this
is adaptation, adjusting, and modifying content. So you might translate an open content piece
into a different language or adapt it for different purposes. Remixing is pretty interesting, where you take content
from different sources and you combine it to
create something new. So you might create a course reader as book with open content,
where you’re drawing chapters from different openly licensed materials and combining them into
a new piece of content. And then lastly, then redistribution. So this is where those
download formats on the web will come into play. Our content is available
to be redistributed and reproduced by anyone free of charge. Based on the original
writing by David Wiley, attribution license. Wanted to make sure I put that in there. With open content, this
is where the necessity for an API comes into play and this is where we
became interested in this, as we saw this use case being taken up by various users of Pressbooks and we were seeing demand
for it from our clients. In 2013, Hugh McGuire,
the founder of Pressbooks, gave a talk and he contended
that a publisher’s job is to provide good APIs for their books, which is an interesting claim
and basically the idea is, if you’re creating a
book in the digital world that we’re in nowadays, that book, if it has a
robust API attached to it, is gonna be much more useful. Even if it’s not openly licensed. If a book has an API where you can read the
metadata about that book, it’s much easier to pull it into different cataloging systems, online stores, libraries and so forth. But if you’re dealing with open content, it becomes really interesting, and we’ll get into some of
those possibilities in a moment. So, APIs. Who here wants to give me
the definition of an API? I’m sure a lot of you can. No? – [Man] A way to
programmatically send commands to other applications or
get information from them. – [Ned] Yep, so a way to
programmatically send commands to another application or
get information from it. So that’s a great definition. The way I like to expand this is, if we look at this webbook on Pressbooks, this is what it looks
like for me as a person who’s visiting the browser
and reading it in the browser. If I was writing in something
like Curl or whatever it’s gonna look like this, and there’s information in here. You know if you look in here you can see there’s a Schema.org blob
up there with some metadata. Up in the header you’ll
find the title of the book, you’ll find other information there but you kind of have to work to get that extracted by a computer if you’re trying to pull that information to another service or application. So that’s where I having
an API can come in. You can expose that information in a way that’s structured and readable and so we’re an open source project and we have one of our, oh yeah, I want to mention this also. I realized after I’d been
working on this project for most of last year, that I didn’t actually
know what REST stood for. I was, at some point
I saw that. (laughing) It stands for Representational
State Transfer. So when you hear of REST API, what that means is it’s
talking about an application program you need this
specifically for web applications talking with each other, as opposed to other APIs
which may be in an application in PHP or something like that. We’re an open source
project, as I mentioned. Getting into the deep dive here. Our first REST API was
actually contributed by one of our open source contributors, Brad Payne who works at BCcampus. He read Hugh’s article, saw Hugh’s talk, and responded to that idea and imported Pressbooks in 2014 and built a version of
our REST API for us, which was awesome. So props to Brad Payne, who set up the technical livestream. So we want to take a look at Brad’s API which was really foundation for us when we were looking at building
the next iteration of it. Endpoints, there’s two real endpoints I want to talk about here, an endpoint being sort of analogous to a part of an application that you as a user might access. So you’ve got a books endpoint here. This gets information about the collection
of books in a network. If I look at this catalog
page on this network that’s what I would see. That’s sort of the equivalent
of that collection data that you get from that book’s endpoint. Then if you pass the book ID, so this is the WordPress
site ID of a particular book, to the end of that endpoint, you’ll get information
about that specific book. You can also pass search parameters to (drowned out by echo). Sort of zero in on specific pieces of the content within the book. Here’s an example of an open
textbook on Pressbooks network. I want to look at actually just look live at the API results from this book here. So let’s pull it up. This is, again this is
the version one API. I’ll zoom in so that everyone can see it. So we’ve got the book ID and a link. We have a lot of metadata here. So we’ve got a title, there’s two authors, we have blank fields for
other types of contributors. Got a link to the cover image, we’ve got a language, we
have a publication date which some of you may
recognize as a Unix time stamp. We’ve got a publication year,
that’s a little more readable and then we have a license
and brief description. One thing I’ll point out
about the use of metadata is that they’re pulled
directly from our database. So they’re interfaced with
PB through Pressbooks. This isn’t an interoperable
metadata standard by any means and that’s something we wanted to change in the version two API,
so I’ll talk about that when we get to the version two API. If we scroll down further here, you’ll get to the table of contents. So again, this is structured with everything that
I’ve described in here, where you have a group of front matter, you have a group of parts. Within each part there’s chapters here and then if I collapse these parts here, we’ll see the back matter. So that’s the general structure of that version one book API. And so that’s where we were until 2016, and then it 2016, after many years of work by the REST API team, we
had WordPress 4.7 Vaughan which came out, and included
core content endpoints for post pages, custom
post types and taxonomies, and that was for us a need to take the work that Brad had done and expand on it and build the second generation of
the Pressbooks REST API and I think this is, I want
to highlight the fact that that version of the API was
built completely from scratch. There was no infrastructure
to build it on, so Brad wrote that all from the ground up, which is pretty awesome. So credit where due for that. We got some funding from The University of
Ontario and Ryerson University to work on this open
publishing project in 2017 and that’s when we really started to dive into this version two REST API and some applications for it and we had three key goals that I will describe, when
we started this project. So the first of which was
to just leverage the work of the WordPress REST API team because building from nothing and building from many years of research, thought processes, design decisions, and the thing was that, we though there was a lot of potential to get a lot from what
they’d already identified by building on top of their work. Our second thing was
interoperability of the metadata, as I mentioned. So we have our own metadata database but it’s not really useful
to other applications unless it’s committed to
a standardized readable or interoperable standards and so for this we settled on Schema.org. It’s very comprehensive,
it’s very widely used and recognized on the web
and within other contexts, and it also has an extension
for bibliographic purposes so the bibliographic
extension gives you chapters, other types of authorship
that are unique to books and literary materials, and so it seemed like a good fit for what we were trying to do with this. So if you look at, just as a comparison, we had that original version one REST API, which took the data we
had in our databases and exposed it over at the endpoint. We have PB title and PB authors here. So in the version two REST API, what we do we transform that
into a blob of Schema data and this gives us the ability,
you can actually take this and put it right into the
web as JSON linked data and it’s readable by Google search engines with no extra effort. So that was our second goal, was that interoperability piece. And then our third goal was to support full-content
CRUD operations, create, read, update and destroy, on all of our custom content types, and so when we’re talking about CRUD, just for anyone who’s
unfamiliar, it’s a funny acronym, we’re talking about reading,
so we have this webbook here, we can read this book, then if we go into the editor interface I can go up here and I can
add a new part or chapter that’s create. I can change this one and save it, which is the update piece, or I can move it to the
trash, which is destroy. So having CRUD capability in the API means that you can use the
API as an authenticated user, to keep all of those same operations by a piece of software. So this could mean you
build an editing interface, outside of the WordPress dashboard, that can create chapters
and edit them and so forth. So with that one, didn’t
quite get all the way. And the main reason for this is because, without additional tools installed the WordPress REST API doesn’t support mode authenticated access. You have to install basic
Basic_Auth or JSON tokens or other solutions to enable that. It does work within a network so we’re able to do some
interesting stuff there which I’ll talk about later on. But we were able to get a full
content read API for the web which is really exciting, and that’s something I’ll
also touch on a little bit. Planning our endpoints. When we really looked back
to our version one API when we were trying to
approach this project, where we have network level
endpoints across all the books. So we’ve got a collection. This is our new API endpoint for that. And then, instead of
having all of that data for each book only available
at the network level by adding a book ID and then
getting the table of contents of that and everything, we also added endpoints at the book level. So now, if you’re at a particular book you can get the table
of contents endpoint, which gives you that same
structure too with your contents. You can get metadata from
that endpoint as well which gives people basically
just a JSON-LD block with all the Schema data, and you can get content
for the front matter, parts, chapters and back matter. Technical approach. For our projects we used
human-made coding standards. We like this because it’s based on WordPress coding standards but uses some other modern features, things like namespacing, and it has an opinionated file layout that makes organizing a
really complex problem like Pressbooks really
straightforward and clear So that’s the system that
we used for building this which defines this file layout. So getting really into
the nitty gritty here. We have an API namespace with endpoints, controller classes and a library of (drowned
out by echo) functions. So I wanted to look at
the posts controller and talk a little bit about that, and then we can see some live
data from a post’s API call. When you’re working with the REST API, there’s a lot of documentation
in the REST API Handbook and one of the things that they say is that you really should not try to override methods of parent classes when you’re inheriting them. If you need to inherit a
class and work with it, your best bet is to
use filters and actions to override the data that’s
coming out of that class instead of changing methods because if you change methods and then the parent class needs
to change for some reason, then you’re gonna be in a bad backwards compatibility hell situation. So when we were building
our posts controller class we kind of got into it that
it needs four different, there’s the time controller, and there was these four content types. We extend that post
controller, construct it, and then we set our namespace,
Pressbooks version two, and then we call this override
using filters and actions which within it contains different filters to handle different pieces. So we’ll look at them one-by-one and feel free to stop me if
you have questions about this. The first pice is query arguments. So, if we’re listing all the
chapters in the book order that you need for the content types. I talked about that read order, and the importance of the
reading order in a book context. The default order that you get from a WordPress REST API
call, is not the reading order. We use the menu order property
to define the reading order of chapters of the content types. So we just use this filter
here to switch that argument and make sure that the chapters and all the other contents are being listed in their reading order. So that’s the first one. Then a find and response. We’re talking about content
that uses, it’s hierarchical, so when you have a chapter
it’s always gonna be associated with a parent part, and it has a part ID that it’s referring back to. So what we wanted to make sure with this is that if you call the
endpoint and you get a chapter, can identify from that
response what the parent part of that chapter is. So this method here, it adds
a link to the parent part, within the API response of that chapter. Then also, we have chapter level, and the front matter and back matter that I’ll call metadata. So if you’re talking about a
book that has multiple authors for example, a compilation of chapters from different sources, you can have different authorship data for each of those chapters and it’s important that that
be exposed to the API as well. So we added the metadata endpoints. So this is sort of the
sub-endpoint for each chapter. It gives you that, will
give you a metadata blob for that chapter as well. So that’s linked from the API
response for a chapter too. So let’s look at one. That’s probably a good place to go now. If we load this up, this is
the first piece of front matter in that context. Okay, so I’m gonna show you over there. As you can see, if we go back to the version one API, let’s compare the two because
it’s interesting to see what we were able to add, just by using the core REST API structure. So this is the original response for that content right here. Version four. And then if we, oh, not that one. ID 157. So then if we go and look at
the version two API response where you’ve got some more things, we’ve got the date created, modified. We have the status, we’ve got a raw app under full content for it, and we have the ID of
the user who created it and we also have contextual
links to other API endpoints which is really interesting. So you get a link to a
collection of all front matter, a link to the author file,
as much as the REST API for the author about this content. You get revision history and you get that metadata
that we talked about as well as any media attached to it. So just by being able to build
on that WordPress REST API you get all this extra
contextual information about the content we’re looking at. That’s the front matter
endpoint, as an example. Let’s look at table of contents. With table of contents, again
it’s in the TOC class here. If we go back to version one REST API, we have these post objects here. If we go to the table of
contents for this book, we’re gonna get, again, the same structure so building on this that was
done in the version one API, we just got a whole bunch more data and then we again have
links to the full content and a bunch of pieces
of content in the book. So you can load that and
then hit the different ones that you want to get the full content. Not a huge change structurally but there’s a lot more context, a lot more information there. And then last I’ll talk
about the metadata endpoint. With the data, basically, we just wanted to get at that metadata from
our core database storage into this Schema.org format. So we built that function that did that. I’ll show you a couple more
functions to do with that. And, this is what we get. So now we’ve got a
Schema.org metadata output with, this is a Thema subject code. We’ve got authors, you
have the publication date that’s actually readable now. And this will continue the book. We’ve got a license and
some custom license text, so that’s definitely our
licensing and attribution, that’s (drowned out by echo) specific information for your institution or publication or publishing company. And again we’ve got, just
moving back to that endpoint. So that’s the ability to, that gives us the ability
to use this metadata in very interesting
and interoperable ways. Putting it all together. If we hit this endpoint to
the get the full information on the version two API, we now have metadata
coming into our format. We’ve got a table of contents with a great deal of additional context, based on the WordPress REST API defaults, and then we have links to
the full content endpoints for every piece of content in the book, structured in the same way
the contents is structured. So just by building on the
REST API infrastructure, we were able to take
the word that Brad did, and expand it and give us new and really exciting capabilities. So again, just looking
at the structure here. You hit the book’s endpoint, you get an individual book with metadata and table of contents, and then you can drill down
though the different levels to get full content and
metadata for each piece. Practical applications,
what can it actually do? We have all this information,
what can we do with it? Well, let’s go back to those
5R activities from earlier. One of the key features
that we wanted to develop as part of this project with
eCampusOntario and Ryerson, was the ability to reuse,
remix or relicense books from a Pressbooks network. So with that in mind,
we built a cloning tool. So if you’re running
Pressbooks 4.1 or later, so anything from last fall, late last fall until the present, you can hit the URL for a Pressbooks book. Give it a new site URL on your network, and if it’s licensed
properly, you can clone it. You get extra attribution
data added to the new book that says this book was cloned from an originally
created book at this URL, licensed under this attribution license. So as an open content creator or if you’re working with open content, you can use this tool
to pull other open works into your own Pressbooks network, add them, change them for your context, and do that sort of reuse and remixing, (drowned out by echo) So the other thing that we
were able to do with this API, was that catalog I
mentioned to you earlier. This was actually just built
by using the books endpoint on the new REST API to build a catalog, and build the outputs with
metadata attached to them. So you can filter by subject
and license, you can sort. And so that’s an application, and there’s only a few things
that we’ve done with them, but we’re really excited
about what this will enable other people that are
working with Pressbooks and working with open content to do. And we have some goals that we
want to work towards as well. And some of those have to
do with a few challenges that we encountered while
working with this project. I’ll say the first one is,
as I mentioned earlier, no built-in authentication system. Right now, you can only
clone private books within your own network. You can’t do any of the CRUD activities on the remote network. We’d like to enable that functionality. It’s not necessarily
relevant for open content, cloning private books, probably
not an open license book, but there are workflows
where you might might want to move something from say
an in-production server to a live public server when
it’s done being written. So we’d like to be able to
enable that functionality and that’s something we are
exploring a best practice for. For authentication flow. It can be built ideally
into Pressbooks itself. The second one. Anyone who’s worked with Multisite
knows that switch to blog is the function that
really hits your database in a very painful way, and that has not been fixed yet. I say yet, not in any
shipping for WordPress, but the Multisite team
have been working on this, so props to Jeremy Felt and the others. We’ve got a couple of new
things that have landed. There’s now a central
table to block metadata, which will power a new site’s
endpoint in the REST API. I believe that should be
shipping in WordPress 5, and when it does, that
will let us do a lot more with the book collections because we won’t be having to
switch to each individual book to retrieve the metadata about them. We will be able to hit one table, hopefully we’ll be able to
add the metadata that we want to be exposed to that table, and retrieve it all in
one database created, instead of a bunch of really
expensive switching content. So that’s very exciting. This is another one that was unfortunate. We namespaced our REST route under the Pressbooks
version two namespace, and then we found out that
Gutenberg doesn’t support namespaced REST routes
for editing content yet. There’s an open ticket about it. We’re trying to look at
ways to approach that and I think there’s a
solution that’s been indicated by some of the core people
are working on Gutenberg, that they feel happy with. So our hope is that that
that will be resolved and we’re engaged on that problem. But obviously that’s held us back from working with Gutenberg a little bit, editing their content with it. So that’s one other thing. But we do have some really
exciting future plans which I’ll just touch on briefly and then I’ll take your questions. We want to enhance our cloning process. So right now, we don’t have
any attachment metadata so images don’t have
licenses attached to them but for open content that’s
obviously really important. So Brad Payne, who I mentioned earlier, who did our version one REST API, he’s actually working on that in that future Pressbooks right now, and then once that happens, we’ll be able to expand
the cloning features so that it pulls in
attachment metadata as well and preserves that attribution
across the cloning operation in that version. We want to just generally
elevate the cloning process. I think because of the way WA on IP works, sometimes we get weird whitespace changes that are a little confusing and so we’re trying to clean that up and make sure that the content
is literally, it’s the same. And then again, we also
have a really interesting and important use case, which is trying to
figure out how we handle third-party content within Pressbooks. A lot of people in the educational space use things like H5P, which some
of you may be familiar with to add interactive quizzes
and other content like that to their Pressbooks books and we just want to
develop a good strategy for how to hook into, hook
those kinds of content into the cloning operations. So if you’re cloning a
book you got everything that’s part of that book. Or you have a good system
for gracefully falling back and indicating the content
couldn’t be cloned, so it’s not just missing. So that’s an important feature
that we want to work on. And then from the catalogs, when that site’s endpoint future lands, we’re gonna look at improving
performance drastically and we’re gonna look at
progressively improving it to filter and search
and load more books live which right now we aren’t doing
with the database instance. So that’s a few things. I also just want to mention, right now this is a weird
coincidence of timing. Stephanie Leary is giving a
talk on WordPress plugin choices for higher education. So was an early contributor to Pressbooks, she built our import feature, and so we couldn’t see each other’s talk, which is sort of sad,
but she’s been working on a really interesting integration with 10up’s distributor plugin, which some of you may have heard about. Basically it contexts the
communication over the REST API, and so we had a really interesting
chat about that yesterday and basically linking that
into that endpoint content, Pressbooks would allow you
to have a syndicated chapter that updates itself from the original book when changes are made
in the original book. So those are the kinds of things, we’re keeping with the
REST API for open content, are pretty exciting, and that’s really all I have to say. Oh yeah, one other thing. Well that’s unrelated, but content discovery and aggregation. Finding the content is something
that we’d like to enable with this REST API as well, so we can build tools to list it publicly and make it available for
others to come and discover and do things with it. That’s another use case
we’re really interested in. So thank you, and I’m happy
to take any questions. Yes? – [Man] You were talking about, it’s not really about
the API with Pressbooks, you were talking about
the export capabilities. Are those all built
in, or do they have to, do you need extensions? – [Ned] So they’re all
built in with the caveat that you have to install
some software dependencies, that can be a bit of a pain. – [Man] Okay. – [Ned] Particularly EPUB creation and Kindle creation, are fun. Kindle gem is required
for bundling Kindles, and you have to create an EPUB 2 file and then validate it, and then
turn it into a Kindle file. So you need to install
some libraries for that. For PDF, our default PDF
exporter uses PrinceXML, which some of you may be familiar with. It’s quite pricey. A single license is $1000, but there’s a service called DocRaptor which is basically Prince as a service and we have an integration for that where you can just drop an API key in and it’s quite affordable
and you can get PDF supports by hitting that service and
then calling the PDF backup. But yes, all of those formats I mentioned are all built into the core plugin. You just have to install and configure the server dependencies. With one exception, that would be LTI Common
Cartridge exports. It’s another plugin that we
build and need to use well and others also created LTI
Common Cartridges for Pressbooks but we have our own and it’s
just not built into core because we still do have
that core, that user base of self-publishing authors
who don’t need LTI integration so we just have it as an
add-on for educational users rather than being in the core framework. Anything else? Yeah? – [Man] So, say somebody wanted
to start creating an API. Where would you recommend that they start? Like, from step one. – [Ned] Step one? – [Man] They’ve never done it before, where would they start? – [Ned] Well, I mean I
think where I sort of start is with the top bit. In terms of really trying
to understand the content you’re working with,
at a really high level. So with a book, it would be premature to
start touching code at all until you really know
all the considerations of how text, content, structure, metadata, how all of these things
that give you a full picture of what API content that
you’re trying to expose over the API. And so I think we have had, a number of years, working with books and trying to understand them and work with the content in those ways, so we already have a pretty
good understanding of them to begin with. But yeah, I think that’s what I would say is the absolute first step, is make sure you really know
your content inside and out. How it works. If it is missing something,
what does it need to not be broken? You know. Because if you have a book, and you have all the
chapters in the wrong order, it’s no good to anyone, right. So, knowing that kind of thing. That’s gonna really inform
all of the decisions that you make around the API. Anything else? Yes? – [Man] Could you go back,
I’m a little confused on when we stand on Gutenberg. Especially ’cause, I literally
just installed Pressbooks, for this– – [Ned] Yeah, yeah. – [Man] Within the last week or two, and I need to try and find a way around, and we’ve got parallel efforts going and I haven’t yet turned faculty loose on trying to create stuff. But I’ve also got, and it’s
many of the same faculty, just about starting up on
other WordPress projects with Gutenberg. Well, they’re not on Gutenberg yet, but I’m looking forward
to the fall semester and what happens. So am I looking at possibly
in the near future, I’ve got a bunch of people
that are learning how to edit using Gutenberg in WordPress and then in Pressbooks
we’re still in TinyMCE? – [Ned] Yeah. So I’ll be frank with you. Because of this namespace issue we haven’t been able work
with with them at all. I think the other thing is, our use case is one that will take a lot of speaking with Gutenberg
to get it working properly. When you’re creating a
book, just as an example, when you’re creating a book you don’t want people
putting in background colors. So there’s a lot of the
core Gutenberg technology that we have to kind of lock down. We have custom content types
that will be really well served by blocks. So that’s pretty exciting,
like in textbooks– – [Man] Any custom Gutenberg blocks? – [Ned] Oh, yeah. Yeah, well, I mean, some of the core (drowned out by echo) and things but just as one example, in the textbooks you often will have, a key takeaways box with a few key points. Then we have, TinyMCE menus and buttons that insert those kind of things, but those will be way easier for people to work with
as blocks, I think. So I’m pretty excited about that but the reality is, we’re
a really small team. There’s two full-time developers
and one part-time developer in our team of seven or eight people, and so we’re not gonna be
ready for it when it launches, and we really want to make
sure that we take the time to get it right before users, because we’ve got lots of
existing content in Pressbooks and we don’t want to do anything that disrupts or disturbs that, because if you have a book that’s in print and something changes about
it, that’s really bad. So you know, there’s, we
really want to make sure that we get it right. So I would say, work
through it internally, considering that we’re probably, certainly won’t be enabling
Gutenberg from day one. Even just hoping we get
this API in a situation (drowned out by echo) with that. – [Man] So probably,
one strategy then is– – [Ned] Is enabling the classic editor. – [Man] And that will be built in? – [Ned] Oh yeah. So you have to install that– – [Man] It’s not like Pressbooks
is gonna hang onto 4.9. – [Ned] Oh no, no no. What we’ll be doing is we’ll
be building the same codes that enables Gutenberg– – [Man] Just still the classic editor. – [Ned] Into Pressbooks, so that until it’s ready to go, there won’t be any configuration needed. – [Man] Great. – [Ned] ‘Cause there’s also things, as I mentioned in WordPress
5, we really want. We want that site’s endpoint,
that’s gonna be a case that’s gonna enable us to do a lot. So, we’re just gonna prevent
Gutenberg from being activated until it’s ready and the upgrade process, well the upgrade to five will be seamless, and then the upgrade to
Gutenberg will be a process and we’ll obviously be working with users to figure out how to make
that work really well. Other questions? Okay. Thanks everyone. (audience applauding)

Leave a Reply

Your email address will not be published. Required fields are marked *