45. Illuminating Poetry with Technology
Hosted by Casey, with guests Devyn Gasparini and Justin Kestler.
Literature gets a bad rap for being too complicated, but it doesn't have to be. Over the years, various websites have sprung up to connect the confused with the clever. LitCharts aims to help by providing source text in one column, and a list of annotations, references, and explanations in another. We sat down with two members of the LitChart to discuss the technical challenges involved in building up a repertoire of literary knowledge.
Casey Faist, Heroru's Python Buildpack Maintainer, sits down with Justin Kestler, the co-founder of LitCharts, and Devyn Gasperini, one of its full stack web developers. They discuss the genesis of the project, and how it's really an evolution of Web 2.0 sites such as SparkNotes. LitCharts differentiates itself by providing modern English translations of well-known literary works, as well as color highlighting and annotating content word by word. Through a clever use of hyperlinks, they can also cite intrareferential and interreferential materials. This has the end result of producing thorough analyses between 8,000 and 10,000 words.
Much of the work developing LitCharts has centered around user experience and user feedback. The LitCharts team strives to not only provide a pleasing experience for the end user, but also a feature-rich interface for the writers providing annotations. Their end goal is to represent works of literature in unique ways, as well as literature that nobody else has covered.
Links from this episode
Casey: Welcome to Code[ish]. I am Casey Faist your host. I'm the Heroku Python Buildpack Maintainer here at Heroku. And joining me today is Justin and Devyn from LitCharts. Justin and Devyn, would you like to introduce yourselves?
Justin: Sure. Hi, I'm Justin Kestler. I was the original editor-in-chief of SparkNotes and the product lead for SparkNotes in its first five years or so. I'm also the co-founder of LitCharts.
Devyn: Hello, I'm Devyn Gasperini. I am a full stack web developer at LitCharts. I've been working in web development and primarily in the ed tech sphere for about eight years now and I've been working with LitCharts for the past year or so.
Casey: I'm excited to have you both on today. This is a topic that I find very exciting. It's the intersection between poetry and technology. So today we're going to talk about LitCharts. Can you tell me a little bit about what LitCharts is?
Justin: We endeavored to make LitCharts something new and something better than any other literary resource that had been created on the web. And today we have millions of people using LitCharts every month. We have an audience far beyond just students that also includes teachers, librarians, general interest readers, book club goers, and really anyone who cares about books, cares about poetry and wants to learn more about literature.
Casey: For those listeners who have not been to the site, when I first went, I was blown away by the amount of context per poem. It is really overwhelming and very cool. You know, some of the hardest parts of kind of reading poetry for me is to make sure I have all the context and all that background. So you all have done an impressive job of gathering that.
Casey: So, can you talk about how you approached this problem? How did you approach this complexity? What were you thinking about as you started to build this?
Justin: Sure. So, I think that also relates to the history of the product itself, right? So meaning all of LitCharts. When we created SparkNotes, it was very much like a port from CliffsNotes, which had been the dominant literature guide for over 50 years.
Justin: And SparkNotes was kind of like a web-based free version of a literature guide that at the time, you know, in the early days of the internet was really ... it was a viable business model, right, to take something that was present in real life that was, you know, sold in stores, which of course CliffsNotes were interpreted for the web and offered for free. Right? And that's really what SparkNotes did.
Justin: So SparkNotes was very much like CliffsNotes in some ways. It was static text with links. And really to this day it is, right? With LitCharts, our problem was how do we take subjects like literature, poetry, of course as a subset of literature, and use technology in a way that hadn't been done before, right?
Justin: So that we're not just doing it for the sake of using technology, but because we thought we could make it more helpful, we thought we could make the product illuminate what's behind all the layers that are in really almost any poem, right? So we were thinking about how to do that, right?
Justin: And with the literature guide, we had the same process, right? We wanted to recreate how you might interpret a book like The Great Gatsby or to Kill a Mockingbird. But here it was how are you going to take a look at a poem that everybody knows, let's say like The Road Not Taken, probably one of the most famous poems of the 20th century. And how can you do something new with it in a way that helps people get at what's there.
Justin: So, for a bunch of years we thought about it, we had a ton of requests for poetry, but we just didn't yet have the time to really figure out how to solve that problem in the way that we think we had solved the problem for the literature guides.
Justin: And then we came up with this idea that the poem itself could be a map to its analysis, right? So, if we used the poem and we used technology like you know, hyperlinks and highlighting and color and emphasis, bolds and italics and so on. And we explained what was happening in the poem on the right column and on the left column we actually showed in the poem itself where that was happening.
Justin: We thought suddenly that would be a way into the poem that hadn't really been tried before and certainly not on a scale that we intend to do it right with, you know, analyzing hundreds or even thousands of poems. So, once we had that idea, we got really excited about doing it because we knew for a long time that poetry was a void, that you know, any literary resource of course had to include. All right?
Justin: So once we got really excited about that approach and that we were convinced it would do justice to each poem that we covered. We went for it and we tried it and we now think we have a model that really can work with any poem. So you know, that goes back to you know, poems from you know Shakespeare's time or all the way up through Frost or even poems that are being written today.
Justin: It's a totally new way of putting a lens on every aspect of a poem from rhyme scheme, to meter, to form, to vocabulary. It's a way in that we think hasn't really been there previously.
Casey: Now you talked about a form that can apply to all these different types of poetry, all these different formats and styles. How did you accomplish that from a technological standpoint? Like how did that ... what did that look like?
Justin: We have a set framework that really, like I said, works with any poem. The first thing we do is we actually translate the poem into plain English. We had done this before with Shakespeare on the No Fear Shakespeare Project back at SparkNotes and through the Shakespeare project that we've done for LitCharts.
Justin: But with poems what we're doing is something similar, which is on the left side you have the poems text itself and the right side, and this is on desktop, of course it's different on mobile since you don't really have columns, as you hover over the poem itself, you see the translation into plain English of every single line of the poem, right?
Justin: And that lets you quickly see what's happening in the poem. You know the big ideas but not really on any kind of level of depth. And once you get through the summary, we have a whole long list of other foundational aspects of the poem that we analyze, right?
Justin: So that's the themes, that's symbols, poetic devices like alliteration and so on, vocabulary that's in the poem, the form, the meter, the rhyme scheme, how the speaker is present in the poem, the setting of the poem, the context of the poem.
Justin: Like you said Casey, there's a ton there. Most of our guides are 8,000 to 10,000 words on a single poem. So we found with those aspects in addition to a line by line analysis, which is where we actually go through every single line in the poem and do our best to explain what's happening in those lines, you end up with a complete picture of the poem that so far has worked for a 110 plus that we've done and we think would work really for any poem.
Casey: I imagine quite a bit of UX planning went into designing this because it is a ton of information, but it's also approachable and pleasing to look at, which I think really ties in well to the idea of you're enjoying the poems that you're reading too. It's bringing a joy to it as well as all of this excellent context and information.
Casey: Can you talk a little bit about how that UX process, like what do you think about when you think about presenting this information in a clear way?
Justin: Sure. I think the first thing we thought about was how to make it intuitive, right? We didn't want to have a long list of instructions on how to use the product. You have to make it obvious that you know you have the poem on the left, you have the explanation on the right and as you scroll you see the aspects of the poem like I was mentioning symbols, pointed devices and so on. You see them light up on the left.
Justin: And so far it seems like people just get that and it just works and is intuitive and once we hit on that it's not so complex. We're not using any kind of super-intense technology to do that. It's mostly highlighting and links, but it's a way that you can almost annotate the poem visually and make it clear what's happening on every one of those levels in a way that we hadn't been able to do before.
Casey: Yeah, I would definitely agree with your statement on its intuitive. It really is. I wasn't looking for any guides on how to read this. I was just reading the guide on the poem, which was really fun.
Casey: You have a lot of poems in this framework now. How do you choose new poems to add? Is it a manual process? Did they go through some sort of review? Is it request-based? How do you grow your repertoire?
Justin: Sure. So, so much of what we do is driven by users, right? We believe in user-centered design. We have always from the first day had a requests form on our site because we of course believe that giving users and readers what they need most really makes the most sense in terms of a business, in terms of a product.
Justin: And so we had gotten many requests for poetry over the years for specific poems. And until we actually had this approach, of course we couldn't fulfill them. But now we found that after we added the poetry feature to LitCharts, we're getting 10 times as many requests for poetry than we did before.
Casey: That's so exciting.
Justin: Yeah, it's great. And it makes it easier for us to make those decisions about which works to cover because we can see exactly what people need help with the most, right? And sometimes there's, you know, the obvious candidates like you know, a Keats poem or Shakespeare sonnets.
Justin: But also we're really interested in is covering poems that nobody else has covered perhaps or not in this way, right? In this type of depth before. So, of course we pay attention to SEO, we pay attention to keywords and so on. But really it's about user-driven requests, sometimes about our own hunch. We feel like of course we have to have The Road Not Taken. That's obvious for example.
Justin: But also we're interested in poems that may not be so obvious and that's, we might be the first to cover in a way like this.
Casey: Yeah. That's very cool. Very selfishly I would love to see some e e cummings on the website.
Justin: Yeah, that's a really great candidate. I don't think we've done any yet, but I have to check. I'm not 100% sure.
Casey: All right. I'm curious about this. The e e cummings is a form of poetry where the spacing of the words is actually important as well. Do you have ideas about how you would present something like that?
Justin: Yeah, that's interesting. Of course e e cummings is a challenge in various ways, even visually. So we think it's very, very important to represent the poem as, you know, the poet intended in the original text. So, we would definitely make sure that the poem looked exactly as it did, as e e cummings Intended when it was published.
Justin: Now one catch there is I'm not sure exactly when e e cummings, all of his poetry was published, but of course if it's a public domain poem, we can reproduce it in its entirety. If it's not a public domain poem, we can't. So we'd have to address it in a different way visually if it weren't.
Casey: Now, I'm so curious as to what this looks like from a technology standpoint. Are you doing any natural language processing on these poems, or how did you achieve this smooth experience on the website from a reader's perspective? Can you talk a little bit about how this was built? What did it look like to build this?
Devyn: Sure. Yeah, so there's kind of two parts to think about, right? There's the user facing side that you saw where we're showing a poetry guide with its analysis side by side with the poem text, right?
Devyn: There's also another side that you don't see, which is the admin side, and that's where our writers are going in and actually writing these poetry guides.
Devyn: We had to implement a HTML editor, like a WYSIWYG editor for them to write these guides. And then we used like a prior feature that we built highlighting, which you know, we might know from using in your Kindle or you know, on paper.
Devyn: Yeah. We had to build the admin side to allow writers to build poetry guides and then we had to come in and build the user facing side so we can display those poetry guides to the end user.
Devyn: And so we needed to handle all these different kinds of analysis that are going on, whether it's the themes of the poem, the summary, the form, the structure, that kind of thing.
Devyn: And we needed to store them in a way that we can display them on the fly. Right? So, as the user scrolls, we are showing them and we're showing where they're appearing in the poem. And so to that end we split all of the different types of analysis into different components.
Devyn: And then we're saving a copy of the text with each component so that we know, for example, where this theme would appear in the poem. And then we are constantly rendering different copies as you're scrolling.
Casey: Wow. That is cool. It is a very smooth experience. That is very cool. So, what's then next for LitCharts? Is there some new feature or is it more poems? What's on the horizon for LitCharts?
Justin: Well, over the past few months we hit 1,000 literature guides. So, for us, that's always felt like the start. We think really there's no reason why we couldn't have 10,000 guides to not just to books and short stories and so on, but also to poems as well.
Justin: So one obvious answer of course is to just continue building our collection, continue covering literary works that haven't been covered before. Filling in the gaps where of course we should be covering canonical texts as well.
Justin: And beyond that we have you know, a very long list of ideas related to how we can possibly improve on this entire process of helping people access and understand literature. We intend to continue to build it out beyond just fiction, nonfiction, poetry and so on.
Casey: I look forward to whatever comes next. Any last words.
Justin: We always love feedback from people and we'd love to hear any reactions, suggestions for improvements to the poetry product, to anything we do on the charts. We have a contact form at the bottom of ... a link to it at the bottom of every page and we love hearing from people and would welcome any kind of feedback.
Casey: Thank you both for making the time and coming to talk about this really exciting project. I encourage everybody to go and check it out right now. Stop what you're doing and go find your favorite poem. Thank you so much for taking the time.
Justin: Thanks Casey.
Devyn: Thanks for having us.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
← Previous episode
44. GraphQL's Benefits and Costs
Next episode →
46. Go at Heroku
December 10th, 47. Working with an Event-Driven Architecture
Python Buildpack Maintainer and Queen Pythonista, Heroku
Casey Faist keeps the snakes fed at Heroku.
Full-stack web developer, LitCharts
Devyn is the primary developer behind the poetry project. She has been working in web development with a focus on ed-tech for the past 8 years.
Justin is a cofounder of LitCharts and was the original editor in chief of SparkNotes. He graduated from Harvard with a degree in English literature.
More episodes from Code[ish]
Edward Muller, Rishabh Wason, and Johnny Boursiquot
Many organizations and teams have adopted Go for its focus on concurrency and efficiency, and Heroku is no different. Although it's no longer a "new" language, diving into Go can be intimidating, whether you're a seasoned programmer or a new... →
Tanmai Gopal and Owen Ou
GraphQL is a querying language with the aim of increasing the productivity of frontend and backend developers. It can make working with React easier, be used as an API for third-party clients, and allow for feature-rich applications to... →
Anupam Dagar and Joe Kutner
The GitHub Student Developer Pack is a collection of free offers and discounts from dozens of tech companies including Heroku, SendGrid, Sentry, and TravisCI. Anupam Dagar is a final-year undergraduate student at Indian Institute of... →