 Hi, hello. Can you guys hear me? All right, cool. Thank you. It's great to be here. I just got here today, and I'm excited to participate with the WordCamp Europe community, and this is my first WordCamp Europe. Like Anna said, my name is Eric Lewis. You can find me on most websites on the internet with the username Eric Andrew Lewis, and I'm a web developer at the New York Times on the interactive news team. My talk today is about text editing at the New York Times, the tools that we present to our journalists for authoring articles for our website and various other platforms, specifically in a project that's ongoing about rethinking our authoring experience from one version of our article editor to another. And I'm excited about this opportunity to share what we're thinking about articles with you, and also like getting feedback through Q&A, or grab me later at the after party or anywhere at the conference to chat about like what you're thinking about articles. So when you're going to build a text editor on the web, you have two broad options. You can implement an editor from Scratch or use Content Editable, which is a browser feature. An editor from Scratch, if you're familiar with Google Docs, is a prime example. And I swear I made these slides last week and I used Dune and I guess Matt Mullenweg just finished Dune, so great coincidence, great book. When you implement an editor from Scratch, I mean that everything from the text carat will be perhaps a div in your HTML that you're blinking on and off with CSS. And when someone presses left or right, you're moving that div appropriately through the content. The selection, when a user clicks and drags to capture text, is going to also be maybe a div with a background color to show the user that they're selecting text. So it's no trivial effort to step into this game. Google Docs did it to have extreme control over the editing experience, down to the placement and alignment of page parameters like indentation, et cetera. But you run into serious technical hurdles to grapple with like, what do you do when you have bi-directional text when you're handling your own selection, such as left to right language sitting next to a right to left language and handling what the selection should be across those. You also have issues since you're not using browser input, you will not get the default keyboard maybe on mobile, which is why Google Docs itself has a mobile app. So you'll have to deal with things like composed characters and accessibility issues along the way. So the fact that Google is one of the only companies in this game that gives you an idea of the technical scale that you're looking at. The other option is to use content editable. It's an HTML attribute that when applied to an element lets the user click into that element and get a text caret, which is rendered by the browser for you. You can click and select text to drag, which is also implemented by the browser for you. Content editable was introduced in Internet Explorer 4 in the year 2000. So it's been around for a very long time. But when introduced, it was introduced unspecced and short for specification. Typically, when new features come to the web platform, we'll write a spec for them, such as CSS is a spec, HTML itself is a spec, JavaScript has a spec, to make sure that everything works correctly across different browsers. Most things we interact with in the real world are also spec, like USB and the HDMI port plugged into my computer right now to make sure that everything just works for us. But content editable kind of went out the gate without a spec, which led to varying implementations across browsers. You might have one browser, when you select text and bold that text, putting a strong tag, HTML around that element, whereas another might put a span with CSS inline declaration to make that content look like it was bolded. And this is problematic because as a developer, we want a structured, predictable data in our document. And Nick Santos, who works on the medium.com editor, has a great article called why content editable is terrible, which is a magnificent and aptly titled article that dives deep into these issues and how they influenced the medium WYSIWYG editor. And an irony here is that medium uses content editable. So the fact that content editable was unspecced leads us to these libraries that handle these browser inconsistencies for us, like TinyMCE and CK editor. And you may be familiar with TinyMCE because it was introduced over 10 years ago to WordPress in 2.0 Duke named after Duke Ellington, the legendary jazz pianist. So at the New York Times, we have a CMS for article editing called scoop. In the past, we've also used TinyMCE for editing content. And on top of that build custom features, one of the most popular in the newsroom is track changes. So say you're working on an article with your editor as a journalist. At different points in the editing workflow, this article might go through the copy desk who is going to look at grammatical errors or just clean up the content to read in the New York Times style for us. And when those changes are made to the content, we're going to see the changes visually when they come back to us so that we can accept those changes and know what is happening at different stages in the article creation. And we get the visual green for added text and red with a little bit of a strike through if you're familiar with diffs in Git, it's the same kind of look. One of the reasons that we wanted to rethink our article interface is because this project has been a serious technical investment for us. And fun fact, Andrew Oz, who works for automatic on the WordPress dot org team, who works with TinyMCE and the WordPress open source software also worked on track changes implementation for TinyMCE that we've open sourced called ICE. So like I said, we're we have our old article interface and we're trying to iterate and see what we can do. What would it be like if we were going to start this project anew? One part of the editing experience is that placing media, whether it be just images or YouTube videos, happens in a completely separate pane in the CMS, which is related to like historical workflows. But in the future, we would just rather have that in line in the editor to have that contextual thought process when an author is creating a story, because things like caption and are integral to fit the context where that image is placed in the story. So why not give that to the editor and journalist in line? Another major question we have here is HTML, our desired document format to be working with. Most CMSs, including WordPress store the body content of an article as HTML, which makes a lot of sense because most CMSs are one to one where you're publishing your content and you're serving your content to your users on the same website, which makes sense. But we also have different target platforms where we have a native app that we have on iOS and Android, Facebook Instant Articles, and the plethora of other Apple news, etc. that require different document formats to be sent to each. So is HTML what we want to offer to all of those platforms to be working with? It might be a non-trivial task for, say, an Objective-C or Swift developer writing the iOS app to say, can you parse this HTML and intelligently tell us, like, how to structure that into the layout mechanisms that are offered to end that system? We also have this current workflow of field-level locking, where if I have the body that I'm editing right now, you can't edit it. Similar to WordPress's locking, that we, in a climate of breaking news and trying to serve the report as quickly as possible and gather news and put it together as quickly as possible, can we offer multi-user support, collaborative editing in our editor as well? So we started using a new editor that came out last year called Prozmir, which also relies on content editable, but a bit of a twist, which comes out of some of the thoughts from Medium.com's editor. If TinyMCE says the content structure is your HTML and your DOM, then the mutation flow in TinyMCE is such that a user presses a key, the DOM in the browser is going to update that content itself, and then TinyMCE comes in afterwards to say, oh, we're going to fix up all those browser inconsistencies that exist because content editable is not completely specced. Prozmir comes in and says there's going to be a separate entity that we're going to call our document, and we're going to have complete control over that as an object in JavaScript, which is what Prozmir is written in. And the mutation flow is a bit different, where a user presses a key, Prozmir is going to override all the DOM events attached to that, so the DOM won't update itself at all. And Prozmir is going to edit its internal document structure first and then draw that to the DOM with respect to what's already there, similar to DOM diffing the things like React put in place, so that you're only using the DOM as an input output device and avoiding the browser inconsistencies that content editable produces. Prozmir also models the document as structured data because it is separate from the DOM. This is what your source of truth looks like, roughly in Prozmir boiled down, where you have object level content blocks that we have a heading that says hello, WordCamp Europe, and notice that the WordCamp Europe is formatted in bold text. And it's very similar to HTML in the entity structure. A major point where it breaks is the fact that in line formatting on a node such as a paragraph is not doubly nested and continually nested in itself, where you have a more linear access to it, which is easier to manipulate and use rather than looking through all the logic of the nested components. Also, document changes are JSON as well, so if we have a document that starts with the letter H and I press the letter I on my keyboard, we're going to have a change that is a replace type of change from position two to position two with the content of that letter I. So a collection of changes looks like this boiled down. And if you're a developer, you might be familiar with Git commits that these more or less roughly map to such that that makes things like collaborative editing not a tricky thing to implement because your document changes are already structured in that way to give you the need for just a central authority to manage if multiple users are in the document at the same time to track the history of which commit comes in first and if any others come in afterwards either rebasing those commits internally, sorry, changes not commits, and then sending them back to the user. Also in Prozmer, you have this idea of a controlled document schema where you establish that a document may contain paragraph elements or headers or block quotes and limit the user to just input anything you might do in a HTML full on whizzy wig. This is really useful if you say wanted to just offer users I only want paragraph text and they can only add bolded text in here and they can't even include links. And this also allows for custom node types. It's built to be an extensible editor. So we have things like custom elements, like our New York Times video element that we can put in our data model as well as the rendered editor that the user would see when editing the document. So this is what we've more or less come to. And this is the editor as it stands today. We've published a few articles on it and we like where we're headed. So yeah, thank you. That's my talk and I'd love to hear some questions you have.