<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Process: Mapping War Logs for the Guardian</title>
	<atom:link href="http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/feed/" rel="self" type="application/rss+xml" />
	<link>http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/</link>
	<description>Strength in Numbers</description>
	<lastBuildDate>Sun, 12 Feb 2012 03:48:24 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Alastair</title>
		<link>http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/#comment-48303</link>
		<dc:creator>Alastair</dc:creator>
		<pubDate>Mon, 09 Aug 2010 13:24:55 +0000</pubDate>
		<guid isPermaLink="false">http://flowingdata.com/?p=10269#comment-48303</guid>
		<description>Matthias,

Thanks for your comments. As it happens, we considered that issue during the initial development of the piece and ended up making the compromises we did in order to satisfy all of our editorial team&#039;s requirements in the time we had available. Now that I&#039;m back from holiday, I&#039;ve had chance to review things and hopefully rectify the confusion.

i&#039;ve had a chat with the editors and agreed a richer key system that assigns enemy casualties their own colour and encodes event type in the rings surrounding each marker.  Of course, some may consider this extra visual detail a source of confusion rather than clarification... 

We&#039;ve just published a new version of the interactive featuring these changes so be interesting to hear what you have to say about it:

http://www.guardian.co.uk/world/datablog/interactive/2010/jul/26/ied-afghanistan-war-logs</description>
		<content:encoded><![CDATA[<p>Matthias,</p>
<p>Thanks for your comments. As it happens, we considered that issue during the initial development of the piece and ended up making the compromises we did in order to satisfy all of our editorial team&#8217;s requirements in the time we had available. Now that I&#8217;m back from holiday, I&#8217;ve had chance to review things and hopefully rectify the confusion.</p>
<p>i&#8217;ve had a chat with the editors and agreed a richer key system that assigns enemy casualties their own colour and encodes event type in the rings surrounding each marker.  Of course, some may consider this extra visual detail a source of confusion rather than clarification&#8230; </p>
<p>We&#8217;ve just published a new version of the interactive featuring these changes so be interesting to hear what you have to say about it:</p>
<p><a href="http://www.guardian.co.uk/world/datablog/interactive/2010/jul/26/ied-afghanistan-war-logs" rel="nofollow">http://www.guardian.co.uk/worl.....n-war-logs</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: How news organisations should prepare for data dumps at Martin Moore</title>
		<link>http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/#comment-48128</link>
		<dc:creator>How news organisations should prepare for data dumps at Martin Moore</dc:creator>
		<pubDate>Fri, 06 Aug 2010 09:26:13 +0000</pubDate>
		<guid isPermaLink="false">http://flowingdata.com/?p=10269#comment-48128</guid>
		<description>[...] Guardian handled the 92,201 rows of data and how Alastair Dant dealt with visualizing IED events at FlowingData). These skills will also help them work out what not to publish, such as data that could put people [...]</description>
		<content:encoded><![CDATA[<p>[...] Guardian handled the 92,201 rows of data and how Alastair Dant dealt with visualizing IED events at FlowingData). These skills will also help them work out what not to publish, such as data that could put people [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: How News Organizations Should Prepare for Data Dumps &#171; The Levisa Lazer</title>
		<link>http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/#comment-47901</link>
		<dc:creator>How News Organizations Should Prepare for Data Dumps &#171; The Levisa Lazer</dc:creator>
		<pubDate>Tue, 03 Aug 2010 13:26:25 +0000</pubDate>
		<guid isPermaLink="false">http://flowingdata.com/?p=10269#comment-47901</guid>
		<description>[...] Guardian handled the 92,201 rows of data and how Alastair Dant dealt with visualizing IED events at FlowingData). These skills will also help them work out what not to publish, such as data that could put people [...]</description>
		<content:encoded><![CDATA[<p>[...] Guardian handled the 92,201 rows of data and how Alastair Dant dealt with visualizing IED events at FlowingData). These skills will also help them work out what not to publish, such as data that could put people [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matthias</title>
		<link>http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/#comment-47636</link>
		<dc:creator>Matthias</dc:creator>
		<pubDate>Thu, 29 Jul 2010 20:49:04 +0000</pubDate>
		<guid isPermaLink="false">http://flowingdata.com/?p=10269#comment-47636</guid>
		<description>Thought I should provide an example of what I&#039;m talking about. If you go to the &quot;April 21, 2008&quot; date, you&#039;ll see about 30 IED incidents in the &quot;Other&quot; category. There was one IED west of Kabul that looks like all the other non-fatal &quot;Other&quot; IED incidents and yet when we click on it, we see:

APR 18 2008 - IED Found/Cleared

Insurgents killed: 3

Incident identifier:
BC917348-DFA4-32FA-C15BF26E4967B5D1

We can tell how many incidents involved all other kinds of deaths (NATO, Afghan forces, civilians), but there is absolutely no way to really tell in this visualization how many incidents involved enemy deaths.</description>
		<content:encoded><![CDATA[<p>Thought I should provide an example of what I&#8217;m talking about. If you go to the &#8220;April 21, 2008&#8243; date, you&#8217;ll see about 30 IED incidents in the &#8220;Other&#8221; category. There was one IED west of Kabul that looks like all the other non-fatal &#8220;Other&#8221; IED incidents and yet when we click on it, we see:</p>
<p>APR 18 2008 &#8211; IED Found/Cleared</p>
<p>Insurgents killed: 3</p>
<p>Incident identifier:<br />
BC917348-DFA4-32FA-C15BF26E4967B5D1</p>
<p>We can tell how many incidents involved all other kinds of deaths (NATO, Afghan forces, civilians), but there is absolutely no way to really tell in this visualization how many incidents involved enemy deaths.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matthias</title>
		<link>http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/#comment-47635</link>
		<dc:creator>Matthias</dc:creator>
		<pubDate>Thu, 29 Jul 2010 20:38:43 +0000</pubDate>
		<guid isPermaLink="false">http://flowingdata.com/?p=10269#comment-47635</guid>
		<description>Alastair, 

Can you explain the decision to not chart enemy deaths here? I can see that you have a color legend for Afghan troops, Civilians, and NATO troops (which I assume were listed in the data as &quot;Friendlies&quot;). But then, for reasons that confuse me, you lump all enemy casualties into &quot;Other&quot; when in fact there are no other &quot;Other&quot; deaths outside of enemy casualties. 

But to make matters worse, the &quot;Other&quot; deaths are further obfuscated by the fact that the light green dots don&#039;t actually chart deaths... they chart IED incidents in which may or may not have resulted in some kind of enemy death. Unless the enemy deaths were significant enough to warrant a circle large enough to stand out, we would have to click on the dot to discover if there were any deaths affiliated with that incident. 

Now, this might have been understandable if there were only a few enemy deaths... perhaps under a hundred. But there were more enemy deaths in that data set than there were friendly deaths. Could you explain your decision to visually obfuscate this (clearly important) piece of information?

(I use the term &quot;visually obfuscate&quot; because that is exactly what happened here. I brought this issue up on Twitter and had push-back from people who thought I was simply lying because they had so much trouble finding the data point I was concerned with. I had to point to specific incident dates and identification numbers to help them discover the reality of the data set.)</description>
		<content:encoded><![CDATA[<p>Alastair, </p>
<p>Can you explain the decision to not chart enemy deaths here? I can see that you have a color legend for Afghan troops, Civilians, and NATO troops (which I assume were listed in the data as &#8220;Friendlies&#8221;). But then, for reasons that confuse me, you lump all enemy casualties into &#8220;Other&#8221; when in fact there are no other &#8220;Other&#8221; deaths outside of enemy casualties. </p>
<p>But to make matters worse, the &#8220;Other&#8221; deaths are further obfuscated by the fact that the light green dots don&#8217;t actually chart deaths&#8230; they chart IED incidents in which may or may not have resulted in some kind of enemy death. Unless the enemy deaths were significant enough to warrant a circle large enough to stand out, we would have to click on the dot to discover if there were any deaths affiliated with that incident. </p>
<p>Now, this might have been understandable if there were only a few enemy deaths&#8230; perhaps under a hundred. But there were more enemy deaths in that data set than there were friendly deaths. Could you explain your decision to visually obfuscate this (clearly important) piece of information?</p>
<p>(I use the term &#8220;visually obfuscate&#8221; because that is exactly what happened here. I brought this issue up on Twitter and had push-back from people who thought I was simply lying because they had so much trouble finding the data point I was concerned with. I had to point to specific incident dates and identification numbers to help them discover the reality of the data set.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andy Cotgreave</title>
		<link>http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/#comment-47596</link>
		<dc:creator>Andy Cotgreave</dc:creator>
		<pubDate>Thu, 29 Jul 2010 08:34:15 +0000</pubDate>
		<guid isPermaLink="false">http://flowingdata.com/?p=10269#comment-47596</guid>
		<description>This is a great post, thanks for doing it. I thought the interactive on the Guardian site was excellent. Being a Tableau user, my own effort (http://bit.ly/bNVyBO) deliberately tried to do the same thing as the Guardian; it was an exercise to see how close Tableau could come to the Guardian viz.

What I really like about the Guardian viz, and is not possible to implement in Tableau, is the instant drawing update as you drag the timeline bar left and right. One could put a Slider Date filter on Tableau, but it wouldn&#039;t update live - it would only update on the MouseUp event, which is a lot less satisfying than the Guardian&#039;s viz. As a result, I chose to use the line chart at the top as the trigger to update the map. 

Keep up the great work (that&#039;s to Flowing Data and the Guardian!)

Andy</description>
		<content:encoded><![CDATA[<p>This is a great post, thanks for doing it. I thought the interactive on the Guardian site was excellent. Being a Tableau user, my own effort (<a href="http://bit.ly/bNVyBO" rel="nofollow">http://bit.ly/bNVyBO</a>) deliberately tried to do the same thing as the Guardian; it was an exercise to see how close Tableau could come to the Guardian viz.</p>
<p>What I really like about the Guardian viz, and is not possible to implement in Tableau, is the instant drawing update as you drag the timeline bar left and right. One could put a Slider Date filter on Tableau, but it wouldn&#8217;t update live &#8211; it would only update on the MouseUp event, which is a lot less satisfying than the Guardian&#8217;s viz. As a result, I chose to use the line chart at the top as the trigger to update the map. </p>
<p>Keep up the great work (that&#8217;s to Flowing Data and the Guardian!)</p>
<p>Andy</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Francis Markham</title>
		<link>http://flowingdata.com/2010/07/28/process-mapping-war-logs-for-the-guardian/#comment-47589</link>
		<dc:creator>Francis Markham</dc:creator>
		<pubDate>Thu, 29 Jul 2010 02:45:10 +0000</pubDate>
		<guid isPermaLink="false">http://flowingdata.com/?p=10269#comment-47589</guid>
		<description>Awesome, thanks for sharing!</description>
		<content:encoded><![CDATA[<p>Awesome, thanks for sharing!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

