At the Truthiness in Digital Media conference, co-hosted by the Berkman Center for the Internet & Society and MIT’s Center for Civic Media, one fact was eminent — there are a lot of innovative people out there putting together technical resources to make it easier to combat Truthiness and misinformation, in media digital or otherwise. We heard from Sunlight labs, who makes use of open data and APIs to dig into the nitty-gritty details about organizations and entities in applications such as Influence Explorer and ClearSpending, and provides grants to similar projects such as Little Sis, while also discussing the rise in political fact-checking done by third-party organizations such as Politifact and Factcheck.org dedicated to breaking down intentional and unintentional inaccuracies in campaign speeches, news articles, and viral rumors.
And yet, with all of this information, it still seemed to us that there needs to be an easier, more practical way to integrate this into our daily experience of the media, to have these factual interventions reach us before the dark untruths had time to take root. We wondered: how might one design a tool that lived in our browser that pulled information from all of these sources, and decreased the friction in fact-checking the things we read (even the most diligent of us can’t always triple-check every fact-checking website for every article we read), or show us the hidden connections behind the people and organizations we read about?
This was the idea that a group of us attempted to work through at the post-conference hack day. What qualities might we take away to apply two this sort of application? What sorts of data should it try to pull in? What pitfalls should it avoid?
Caveats, of course:
– We humbly realized it wasn’t a profoundly new and unexplored idea, and there are a lot of actors in the space — for example, one of the participants of the hack day, Dan Schultz, is working on a very similar browser-based project (TruthGoggles), and another, Matt Stempeck, on an inbox-focused tool (LazyTruth). Beyond, that, Hypothes.is and rbutr attempt to do similar functionality in a crowd-sourced manner, and PoliGraft does a similar thing in presenting a “report” on a page. However, in the spirit of hack days, we explored the idea as if it was a revolutionary new concept that we could fully solve in 2-3 hours.
– Knowing that another group was working on thinking through the questions of how the backend API for this sort of thing would work, we considered all backend server work outside of the scope of what we discussed / black magic.
What we came up with was the following, ripe for a power-point to be presented to those who wish to massively fund the endeavor…
What is it?
The application is a browser tool which automatically analyzes and annotates news articles you are reading, giving you visibility into the hidden context and background on the people, organizations, and claims contained within.
Who is this For?
The primary audience is private citizens who are interested in expanding. Secondarily, journalists or fact-checkers could themselves use this to expand their view on material they were looking at as sources.
What sort of data or context should this application present?
– Basic Summary or Biographical data abut people or entities
– Links Fact-checking Sources confirming or refuting assertions, with some sort of pullquote of what it has to say about it
– Link back to primary sources, such as Congressional Bills, or Cited articles or research papers
– Public records data on people or organizations, such as Financial Records, Campaign Finance Records, EPA infractions, Legal actions, or Sponsored legislation
– Relational data indicating some sort of coefficients of relationships between different entities, such as positions in different corporations, Board interlock data, or Research funding — to allow some sort of networked relationship view
Challenges / Considerations:
– This idea is not without precedent; do due diligence on what’s been done before to see what works and what hasn’t
– Apply “Do No Harm” Best practices, to counter-act psychological effects that would tend to make people reject the factual citations. Avoid backfire effects by avoiding using ideological cues; when checking claims focusing on assertions rather than person or political context; attempting to prime people to be in the mode mode of objectivity / skepticism.
– While there is a wealth of data to present, one must limit visual complexity: too many moving parts would make it distracting and overwhelming and counteract the goals
– Importance of Brand / Citing sources as motivating or legitimizing factor — citing sources (Wikipedia, Politifact, etc.)
Attempt to make use of Ben Schneiderman‘s Visual Information-Seeking Mantra of “Overview first, zoom and filter, then details-on-demand”:
– Some sort of way to display a count on how much content / how many bits of data are accessible on a given entity
– Represent some sort of “Heat Map” for disputed text
– Claim – Back highlighting color or visual color cue, how much information
– Grade of How Polarizing is the language in article
– Select what kind of entities
– Select what kind of information of details user wants to know about
– Advanced Option: Automatically Figure out the most important sort of information to display contextually based on the type of article
Choose what organization, assertion, or person to get more details on…
Details on demand
Show verbose data points or ferences described above
How to visually implement?
– Overlay / re-write of HTML to provide links on names or text, with mouseover- or clickable links to expanded information
– Sidebar hyperlinked from text
– Separate analysis page — click to bring up dashboard or report on a given page
These were some of the thoughts that myself, Becky Hogge, Michael Conover, Chi-Chu Tschang, and numerous others talked through over the course of a half-day’s worth of idea-hacking. (Much thanks to Dan Schultz for helping us frame the topic with what he had learned in his work on Truth Goggles.)
The next steps? The API end is probably the part that needs to be proven out first — if we could synthesize the concepts between the different sorts of projects out there to design a centralized, reusable API of which a browser-based application or an email application could be but two specific implementations, plus figure out how to merge all the data together from disparate sources into something that looked like one unified interface, we’d be quite a few steps along the way…