FastCharts — Changing the FT Newsroom, One Tool at a Time
By Amanda Gordon & Ashoor Namrood
At the Financial Times, many of our articles contain simple charts to help tell the story. However, until recently getting those charts created and into an article was painful.
We have had a tool to create simple charts — Nightingale — in our newsroom since 2015, which enabled Journalists to create their own charts and simplify their workflow. However, there was no opportunity to collaborate effectively and, without a save function, once you closed the tab, all the work was lost.
Here’s an example of the type of conversation that took place as we were planning to rebuild Nightingale:
Alice: “Please use the Acme Inc’s data going back 3 months.”
Bob: “I need help from Carol to sort out the data. Is this for Web (chart theme) only?”
Alice: “It’s for Web and Print.”
Carol: “I’m going to see if I can get these from the data terminal — I wasn’t able to log-in last time.”
Alice: “If you are unable to, I can send you the data from here.”
Carol: “I’m afraid I can’t log-in from here. If you send me the data you want in the chart in a spreadsheet, I can do the rest.”
Carol (after creating the chart): “Here is the Web version. Let me know if this is OK. Please find attached the SVG. I will also save the data in the shared folder.”
Bob: “Thanks. Please provide the size for the Print version and the [Team in] Manila will handle.”
Diane: “We just need the web version for now thanks.”
Diane: “The chart looks good, but there’s a typo…”
Carol: (recreates the chart from scratch) “I’ve fixed the typo, here it is again”
Ed: “We need this chart for the newspaper after all — [Team in] Manila can you reproduce?”
Bob: “Ok can do this now Ed, can you re-send the data please?”
(Bob waits for the data to be sent over in order to recreate the chart for the third time)
Alice: “The sooner Nightingale transfers data, the better!”
This conversation in December 2017 involved 5 people and took 22 hours to create a simple chart for just one Web story and its Print equivalent.
Houston, we had a problem. Several actually.
As well as losing your chart if you needed to rework it, and the inability to share, the brand guidelines were outdated and inconsistent with other FT graphics. Due to the time it would take to add or update a theme, charts could have incorrect themes for weeks or months at a time while our development team were focused on other initiatives.
To add to this, the technology used for the charting tool was either obsolete or no longer supported. We were having to go through old documentation to learn how to make relatively small changes. Updates took ages to implement and there were features available to the user on the UI that no longer worked, such as the option to have Stacked Charts. Upon inspection of the code, we found “TODO” in comments around where the functionality should have been!
The tool did get created as a proof of concept that then was rapidly rolled out, hence the “TODO’s” — however this meant users didn’t trust or use Nightingale as much as we’d have liked, meaning that the Graphics desk would spend time manually churning out simple charts instead of intelligent and complex graphics.
Then, during stand-up one morning, we decided — whilst sounding out how long it would take to update the Web theme in Nightingale — “Why don’t we just rebuild the whole thing?”
So we did.
We mocked up some wireframes and had a conversation with the Graphics Desk about how we could visualise these as a proof-of-concept and showcase what we could achieve if we took this forward.
Then we got coding. We had an idea about what technologies we wanted to use for the real thing, so we set a project up in React (with MobX) and Victory Charts, and timeboxed ourselves for 2 days to come up with a rough-and-ready solution to demonstrate.
Showing the POC to the Senior Graphics Editors was a great way to show the potential of what could be built, and how easily, including lots of features that had been requested but as yet unimplemented.
From here we proceeded to the build phase of the project.
We wanted to keep the Graphics desk involved from the beginning. Although the tool ultimately is for journalists, the Graphics Editors are the ones who understand visual communication and storytelling, and had the ultimate say on how a chart should be styled.
During the build phase we would sit with an editor, so feedback was immediate. We would also have larger ‘check-in’ sessions where we would present the work done so far, and get more thoughts and feedback in that way. Some extra nice features came out of these conversations, for example being able to have basic editing of data available within the tool.
We organised a user testing workshop when we felt the tool was close to being ready for the newsroom outside of the Graphics desk: we contacted 5 or 6 editors, and asked them to use it. We wanted to see how easy the new tool was to use, and how they felt about it compared with the old one. Feedback was very positive, and scores for the new tool went up to 8 or 9 out of 10 (from a lowly 3/10 for the old tool).
Finally, our product was good enough to be used. Our first users were the Graphics Editors themselves — they became our evangelists and supported our journalists as they got to grips with FastCharts. Feedback was quick and positive:
“We have gone from driving a Pacer to driving a Ferrari — Thank you!”
And
“Night-and-day better than the old [tool]. Functionality is wonderful and I managed to work out most of the things I needed to do pretty quickly.”
And people started providing us with other ideas. For example, as the Print theme wasn’t going to be part of the initial 3 themes included (those 3 being Web, Social and Video), one suggestion included adding attributes to elements in the SVG file the tool would output, so that the Graphics Desk could open a chart in illustrator, and run a script that quickly converted the chart to the Print style. Another huge time saver and improved workflow for the team.
One of the main features which gives FastCharts more depth is the Chart Library. This allows users to save, share and retrieve charts and data, and it works with the separate API we created as part of the rebuild. The API has taken on a life of its own and we now see it as a completely separate product, allowing developers to create a custom UI in other projects which access the Chart Library. A recent example was on a CMS discovery project we’re currently working on. We are now able to connect to the API and use it to search for and insert charts straight into articles.
The introduction of a Chart Library has also produced a change in workflow: now that a chart has its own ID, we have noticed that more collaboration is happening, and it’s all organic.
This is the conversation people now have (on Slack), typically involving 2–3 people and a turnaround time of minutes:
Alice: “Hi all — I’d like to post this chart (Web graphic attached) on Social media.”
Bob: “@Carol created that.”
Carol: “Sure — here is the link: https://fastchartsurl.com/edit/[FastChartsId] — the data’s all there.”
Alice: “Thanks!”
(Alice opens the link, changes the Theme to Social, and is good to go!)
At the time of writing, the first group of super-users has been given access to FastCharts — just over 100 unique users so far — prior to training. The feedback from the newsroom has been excellent. We have been active in working with users to fix bugs and make basic improvements, as the product is allowed to mature.
FastCharts is also gaining a reputation in other parts of the business as they create charts for presentations — this is a simpler tool than Excel or Google Sheets and provides users with a more professional looking chart with FT branding. We are exploring ideas to take the tool beyond the newsroom, and plan to revisit FastCharts later in the year to implement even more features and make it even better!
— -
Amanda Gordon
www.linkedin.com/in/amandagordon-ba
Ashoor Namrood
https://www.linkedin.com/in/namroodinc/
https://twitter.com/namroodinc
