typing innovation in BBC News — James Dooley
Yeah, good morning, everyone.
Thanks for joining me.
I guess there's only one track, so you didn'thave a choice.
But, yeah.
My name is James Dooley.
And if you can tell from my voice, yeah, I'vecome here in London.
My first time.
And, yeah.
Really enjoying Australia so far.
I didn't know this, but it turns out thatmy name, Dooley, is kind of like an Australian phrase that some people use for increduloussurprise.
Like, holy Dooley.
So, I was superstoked to find that out andI'm going to try to make that a thing back home.
I'm going to make that, thanks, guys.
And Australia is home to a rocking band, theHooley Dooley.
If you don't recognise them, check it out.
It's an absolute bangers.
But I'm to the here to plug the Hooley Dooleys.
But I work for the BBC in London, News Labs.
We have an interesting challenge.
Labs is about trying to futureproof news.
So, that it stays relevant and sustainableas media needs evolve and change.
And we're seeing that happen over time rightnow.
And we drive innovation in the newsroom byexperimenting with new tools and ideas that fuel cutting edge journalism.
We do this with a small team of engineers, designers and journalists.
And we try to research, ideate and cook upprototypes in six weeks.
We have two main strands of what we do.
So, the first is improving production workflows.
We build a lot of internalfacing tools.
And we often use React for the journalistsand try to do the heavy lifting for them to empower them to be more productive.
So, things like translation for our worldservice teams.
The BBC outputs in I think 42 different languagesaround the world.
And there's a lot we can do around reuse andreversioning content for different audiences.
We also do a lot with creating faster workflowsfor our video producers.
And on the other side of that is the audience.
So, we experiment with new formats and newways to tell stories to them.
Things like conversational chatbots on messenger, WhatsApp, and also inside of our articles as well.
And we've done some really big stuff in thepast with Amazon Alexa and delivering interactive news via voice.
And I just wanted to explore that one reallyquickly.
Because for Alexa, we built a prototype calledSkippy.
It was appropriate being in Australia.
But it was our first time using React.
It's an example of how we glue things togetherand why we love it.
So, Skippy was about creating a skippablenews experience on Alexa.
And it started on a hack day.
One of our awesome teammates basically gotAlexa to give us the top BBC articles and allow you to skip through them.
It was pretty basic.
But people liked it.
And, so we wanted to it forward.
It's all well and good having synthetic voicereading you the noise.
But people to want hear real voices.
Who knew? The BBC has heaps that have.
I'm not kidding, for every hour of the day, we're producing about 57 hours of content.
For huge.
For Skippy, it seemed like a waste not touse that.
But when these voice platforms were firstlaunching, there wasn't a clear way for journalists to get content out on Alexa.
We said, can we make a tool to help createcompelling and interactive programs for voice? I don't know! Like, sure.
We kind of just kicked off.
And kicked off with a little create Reactapp.
And I said, what is React? I had no idea.
And we've all had this feeling now as partof the JavaScript community where you find that someone has made exactly what you need.
And this is happening time and time againand it's amazing, right? We needed a way to chop up our radio broadcastcontent.
And with the library of BBC UI componentsand a tool were wave forms, we could start cooking something up.
All right.
I was starting to understand why people likeReact.
I was not a UI developer.
I wasn't a frontend developer.
Maybe you could tell.
It made sense and pretty quickly we couldget something up on the frontend and ingesting radio content and letting producers carveout highlights.
But we ran into a problem because Skippy wasmore than just skipping through programs.
It was about creating interactive storiesand journeys for users pieced together with different bits of content.
And speaking with audio producers, they wereused to the workflow of having assets and dragging them on to that timeline.
This was really important for them.
As a prototyping team, our first instinctwas to say, no.
No way.
Not for an MVP.
We don't have time.
But we actually found it was pretty simple.
So, we turned to React drag and drop.
And I'm sure a lot of you have used it.
It's a superintuitive tool.
And really excited for the dnd talk lateras well.
And in order to order our assets, we usedReact sortable tree.
And shoutout to both of these, because withthem we were able to do some pretty fun and functional things.
So, we can drag in our audio clips and designhow an interactive program would flow exactly on Alexa.
And we could create nested journeys.
You can ask Alexa to skip say the whole sectionof business news or the sport.
Or you can get a personal deep dive, ask Alexa, tell me more.
And then get a human deepdive on Brexit orwhatever you wanted to hear.
This is big.
Looking back, it looked wild for sure.
But we were able to make a novel interfacefor content users.
And it was an interactive medium.
There was a lot more, but to skip to the end, from a hack day idea it a prototype to getting it productionized.
And Skippy gave birth to a whole new departmentin the BBC with hundreds of people creating content every day for voice.
So, we were able to kick start some beautifulthings in Labs.
And we love React because reusable componentslet us move quickly and not reinvent the wheel.
We wanted to make more of what we do reusableand help others.
And we thought we could do this in an areathat we have trouble with, transcription.
Taking an audio and video and turning it intotext.
This is the heart of content production fora lot of places at the BBC.
Why is transcript useful? Very quickly, journalists have to pull outkey quotes and bits of information really quickly.
On a larger scale, researchers have to collatehours and hours of interviews and then analyse these indepth to create stories and documentaries.
And then down the line from that, video producersuse transcripts to navigate footage and start building up a catalogue of shots.
And then they use these to edit footage andstart building up programs.
Often in post-production they use transcriptsto create captions for our videos and make them more accessible.
And also, transcripts are just datarich.
You can perform entity extraction on them.
Pull out topics and tags and use these andadd them to your pages and make them more searchable.
But the kicker is this: Just one hour of mediatakes three to four hours to transcribe manually.
And if you're a journalist, this could behalf of your working day spent doing something laborious and not creative.
As engineers in the room, you're probablythinking, there's no way people do this themselves in 2020.
But shockingly, they do.
And they have done for years.
Which is nuts.
So, there are alternatives.
You know? There are basically agencies where you canoutsource it to another human.
It costs at least a dollar a minute, 60 USdollars an hour and it's not a lot more and you're waiting for someone on the other end, usually over a few days.
But there's sweet transcription apps, basicallyusing speech to text.
These are obviously a lot cheaper.
But we start entering that world of voicerecognition mishaps.
We have all seen the Siri and Alexa errors.
And, you know, regardless of either one, wehave investigative journalists at the BBC who deal with very sensitive content.
They can't send it out to random people orrandom service.
So, with time, cost and security in mind, news labs a couple years ago made a tool called OCTO.
It generates transcripts for journalists.
It uses an open source speech to text engine, and we trained it with thousands of hours of content from the BBC archives and ableto bring the cost down dramatically.
If you're in a bureau in Delhi or Jakartaand you're dealing with 30 hours of interview footage, or if you're one of the archive teamsand you have 30 years of TV output, this is huge, right? So, OCTO was pretty simple.
You select your media and it gives you backa transcript.
But naturally, it wasn't perfect.
There would be, you know, spelling or formattingerrors you need to deal with.
Sometimes maybe you would deal with, you know, struggle with background noise.
What users would typically do, copy that email, stick it into Microsoft Word and carry on.
But we were losing so much data at the editingstep.
And it seemed like a shame.
So, what we wanted to do was make a plug andplay editor to navigate and correct these transcripts and keep all of this timing informationthat we have.
And record at React transcript editor, whichwas very creative.
But we were able to be from an email to somethinglike this.
This is what our editor looks like.
Oh.
This is what our editor looks like.
It's all this is what our editor looks like.
And it's all powered by Wordlevel timingsthat we get from our transcript.
And it lets us do so much.
You can see clearly on the video using thetext, you can click on any word to jump to that point.
And it makes navigating and analysing yourown content so much easier.
So, we spoke to lots of journalists.
And we found out how they work and what theywould really want in a text editor that would allow you to navigate transcripts.
So, we've added in some really simple butreally effective features.
Some really simple things that made it somuch better.
So, easy keyboard shortcuts to navigate around.
Changing the playback speed so you can dropit down.
Sometimes it's too hard to keep up.
Would this be better? Or how about this? And by adding this I'm just going to say abunch much words because I can't think of it, but it's going to be really, really, reallyfast.
And also features like pausing while you'retyping.
So.
.
.
the play doesn't run away from you.
Making the whole experience of Editing mucheasier, more effective, and more ergonomic.
Then battery died, which is classic.
But I know what some of you are thinking.
And the answer is, yes.
We can use this for karaoke as well.
[ Laughter ]So, I muted this for everyone's sake.
But as we follow long to Smash Mouth and startadding new words and deleting mistakes, our time code data is going to start to degrade.
It gets patchy.
An important thing that we do is fill in thesegaps.
And we estimate based on the surrounding wordsthat don't have times.
And we interpolate between them.
So, we can keep this data in sync and preservevaluable timing information, right? Because ultimately journalists can still justcopy this into Microsoft Word if they want.
I don't know what they would be doing withthe Shrek sound track.
But we can do so much more, create files, or even take the corrected JSON and build upon it in other apps.
And this data was all powered by Draft.
JS.
So, who s developed with draft before? Anyone? Well, that's quite a lot of you.
Has anyone used like a different editor maybelike Quill or Slate? Okay.
You know more than me.
But, you know, actually I'll correct myself.
Draft isn't an editor.
It defines itself as a framework to buildeditors, right? And for the people who put their hands up, they'll know.
The learning curve is pretty steep.
And, you know, it seemed like a really powerfultool with a really solid community behind it, so we dove in.
And inside of a Draftpowered editor is a soliddata representation.
So, it's a single source of truth.
And if you change that data, Draft handlesall the DOM information for you.
It abstracts away from contenteditable whichis really finicky, fiddley, and inconsistent across browsers.
And that's powered by immutable JS.
Does everyone know immutable JS? Yeah.
Okay.
A couple of heads nodding.
What this basically means is when we changeour draft data, we get back a whole new copy.
That sounds a bit intense.
But actually, the new copy is just a referenceto the old data.
And only the reference and the change occupynew memory.
So, the overhead is less than you would actuallythink.
And this gives us some things for free.
The undo stacks are really just copies thatwe can keep track of, useful in a text editor.
There's a great talk by Nick that goes intoit more.
We can dive in.
We can get a text editor in ten lines.
I'm totally lying.
This is really more of a controlled input.
To do anything complicated in Draft takesa lot of work.
And we need to dig into editor state.
We have to manage our focus and the paragraphsplitting and how we deal with that time data.
So, it's like our engine for Draft.
JS andexposes the APIs of the building blocks of how we build this.
This content state, deals with everythingin the editor, selection state, handles your focus, selection cursor or that.
There's a cool thing called decorators whereyou can substitute in custom components in certain situations.
For example, if you wanted to do hashtagsor to complete them or@ mentions.
There's decorators behind it.
Entities allow you to have ranges of textwith the metadata.
And there's the content state.
And they're a serious of blocks.
And a block is a paragraph.
And we're looking at it in the side.
We've serialized it to JSON.
When we start typing.
Is that okay.
Cool.
It actually took me like ten goes to writethis without any mistakes.
But there we go.
And our state's changing.
But we want richtext, right? So, we can use a rich utils function.
We can make that bold.
Yep.
And make that italic.
Cool.
Now, this is nice.
Draft lets us use ranges to hold metadata.
So, if you look on the righthand side, we'vegot inline style ranges.
And if we take the first, it's actually prettydescriptive and it makes sense.
So, it just says that eight characters yeaheight characters in for the next 11 characters make it bold.
And that makes sense.
So, when we start typing, I'm making correctionsto our transcript, the offsets are gonna keep this data in sync.
Right? But we don't care about styling.
Well, not at this conference.
But we want timing information, right? We all want time.
So, if you remember OCTO, before the email, we actually had all of that transcript data.
And it looked like it this underneath.
It's a giant JSON file with data on each wordthat speechtotext picked up.
And it goes on forever.
So, like a 30minute transcript is tens ofthousands of lines.
All we were using were the display strings.
But now we have, you know, a framework touse the extra metadata.
This really powerful timing information thatwe have.
So, we've got our transcripts.
And we want to get it into draft.
So, draft exposes an entity map which is basicallylike a data store.
And we can stick all of our metadata in.
All of our fragments and all of our timinginformation and we get back a key.
So, if we remember back to our blocklevelparagraph data, it might look something like this.
And then in order to associate the timinginformation underneath, we need to add some entity ranges.
And so, give it a key, which associates tothe one that we stuck in the data store.
And then we do this when we first serialiseand import the transcript data.
And, yes.
It's a bit finicky, it's a bit fiddley, butafterwards, you know, the offsets and the lengths can basically adjust when we startadding our timings, our adjustments to our transcripts, sorry.
But oh yeah.
But.
.
.
when we start adding new words, orwords deleting words, it gets patchy, right? So, if we add in things in between, we won'thave time information for that.
And what we do is we also take a diff usingthe DiffWith, a Python library that we wrap around.
And then we do some linear interpolation andwe start to calculate timings for all of these.
And, yeah.
So, that's how we keep track of time datain Draft.
JS.
And yeah.
And power something like a transcript editor.
Excuse me.
So, we made it for journalists, but we packagedit for developers.
Because if you're using BBC OCTO or somethingoff the shelf like Amazon transcribe, you can do that.
No matter what you have, we can serialiseit to a draft format and we have a bunch of adapters for that which is really nice.
We also made it an open source component library.
So, you can get the whole app in just a coupleof props.
Or if you just want the timed text editorand you want to hook it up to your own video player, for example, you can do that too.
Yep.
That's how you use it.
We use it as well.
We've used it in a bunch of digital apps andprototypes down the line.
One lately is digital paper editor.
The one that I described before of recording, transcribing, analysing and piecing it together, it's paper editing.
It's common in paper making, but it's painfuland takes a long, long time.
We automated this process.
We used editor and get correct and accuratetranscripts with spoton timings.
And afterwards, we build another layer ontop.
We have taken the paper editor and built itin React.
We can start to highlight and analyse ourtranscripts.
Build up a corpus of good bits of information, good clips to use in a program.
And then we can start to assemble a programscript of our highlights on the righthand side.
Which is a little bit like Skippy, right? And because of the transcript, and we havethe timing information on the timing information on every word, we can then just assemble avideo editor edit just like that.
So, we click preview and everything is cuttogether automatically which is superhandy.
Obviously, you're not going to do all of yourediting in a React app for a program.
So, afterwards we can export and edit decisionlist and then pass on to whatever program for your final touches.
So, we're really scrappy in Labs.
And just like Skippy, components help us buildquickly.
And it's been adapted in other newsrooms likeThe Guardian and times and others in South America.
They have feedback and contribute and innovatein their own spaces as well.
Just a couple things, yep, I've said it afew times, we're a prototyping team.
And making something reusable is hard.
And if anyone is a newsroom developer here, you'll know that journalists are very challenging to design for.
You know, we sat and talked to a lot of them, and found out how they work.
But it's an old school industry and everyonedoes things differently.
Importantly, to get adoption for your toolsin a big organisation, you have to solve a lot of problems and solve them really wellbefore people are going to change how they work.
We targeted techsavvy journos as the earlyadopters.
But we had toggles and settings for otheruse cases, and the props were out of school.
We saw if this was possible in Draft.
JS.
Instead of getting everything perfect, wewent deeper and deeper.
We wrote this a good while ago before we wereusing Hooks and Context.
While we see eliminations in the prototypeycode that we can address, there are ways to handle this in large quantities.
And it seems like active development on Drafthas stopped which is worrying.
We would love to have different approacheswith frameworks like Quill or Slate.
If you're doing anything complex, build anabstraction layer for it.
Never know when you have to change it outfor a different engine and that's a lot of work.
That's currently where we are.
Don't do what we did.
And if what you're doing isn't too complex, then get what you can for free.
Because like I said, Draft provides you thebuilding blocks, but you still have to piece together everything yourself.
Other frameworks might be more complete outof the box.
Or you can use some plugin frameworks.
For us, under the hood, having to deal withstyling, changing entities and shifting all this styling and data, it was needlessly complexin Draft.
And I didn't get on to the headaches of splittingparagraphs and controlling focus.
It wasn't particularly interesting.
But it was just a lot of code and a lot ofhead scratching.
But if you've worked on text editors, yes, please come chat to us because we would love learn from you.
And yeah, the last thing is the communityis here to help.
The crosssection of like a transcription headsand text editor framework in React heads is pretty small.
It's a niche area and most things in the spaceare commercial.
So, being in such a specific domain has meantthat our contributors in all these different newsrooms around the world are superenthusiastic.
That's helped keep things moving.
We work on different projects every six weeksand it's really hard.
Jed's talked about the first sort of phasesof open source.
And, yeah, it's superexciting.
People are contributing.
You're learning lots.
But it's starting to get into that next phasewhere it's a bit overwhelming and every new feature adds more core complexity.
So, we're trying to find out how to deal withthat.
But ultimately, helping other newsrooms waswhat we wanted to do.
And so, we're really happy with that.
So, yeah, just finally, you know, we're hereto keep BBC News and all public service journalism relevant.
We need to find ways to reinvent news so itcan be sustainable in this new era as audience behaviours and needs change and evolve withtechnology.
One way we can do this is by reevaluatinghow we create content and doing more with the data that we have.
Making it more reusable.
Preserving it and making it more discoverablefor content creators.
This way we can equip journalists with toolsto easily construct new stories and experiences which are scalable and adaptable to our audienceneeds.
And React is helping us on this journey.
So, thank you.
Nhận xét
Đăng nhận xét