Handle Targeted Threats sub-types

[peterjaric]

At the moment there are "sub-types" to the Targeted Threats package (Activist, Journalist, Lawyer, Opposition, NGO, Tibetan). When clicking one of these the targeted threads tab will open in the dialog displaying all targeted threats.

Ideally the resulting list of threats should be filtered on the sub-type. I've added a TODO in the code here: https://github.com/digitalfreedom/website/blob/master/js/app/modules/map.js#L125 but that's probably not the only place the code needs to be changed.

[kkleemola]

Sub-types were my doing so I can fix this. The code needs some cleaning that can be done at the same time anyway.

[peterjaric]

In https://github.com/digitalfreedom/website/issues/16 @botherder writes that we want "Country pages instead of just modals". Maybe we should do that first, and then fix this? To avoid having to redo work because of a different architecture.

[botherder]

My idea is having pages for all countries (perhaps with a jekyll markdown basis so it is easy to add some static content if we'd like) which contain then JS code to pull the relevant data from all datapackages. On the map I would then display a count of the records on the country and then a link to the country page, or something like that. Thoughts?

[kkleemola]

@peterjaric Agreed.

@botherder That sounds good.

So particularly for TT, we could have something like: x reported targeted attacks x of which are against x of which are against etc

Might be nice to have a nice plea for help and a link to the contribute page for on the map for countries we have no data on.

I like the idea of being able to add some static content with an overview or something to add a more human touch (instead of just a lifeless data dump). But I imagine this would have to be deferred as it would take some time to put together.

As far as implementation for country pages go: Jekyll's collections seem to be designed for this kind of use? The feature is still experimental though. I can play around with it and see if its usable if you guys think it would be halpful.

[botherder]

Cool. I was honestly just thinking of creating markdown files for each country code.

[bnvk]

If the data is going to be rendered via JS + AJAX like the map, this should be doable with just a URL segment digitalfreedom.io/country/SY or query string value ?country=SY So all we would need is a country.md file that is a different layout than the rest of the site and the JS logic that parses the URL. With either approach we could also do #target-IR style hash values to change visualizations that retains share-ableness of URL as well. Unless i'm missing something, seems simplest route to me!

One caveat is of course our site is not as easily scrape-able / readable by bots. Is that something we care about?

[kkleemola]

@bnvk I imagine that could work... so in my mind (and I can't speak for @botherder on this although I have a nagging suspicion his thought process might be similar to mine) when I try to figure out the "best" way to do something, I'm actually trying to figure out how to do something with as little javascript as possible.

So if we have static content like an overview for the country pages, which I am very much in strong favour of then I think the site is easier to follow/maintain if there's separate md's, even if it does seem a bit silly. But again I'm strongly averse to js. At the very least we need to start breaking out some stuff like the data tables code, etc from the map.js file I think so it can be a bit more organized.

Regardless I do think that maybe it's time to think of what the site should look like later on before rushing in and deciding how to do things. I think it would be super neat to have little blog posts that pretty much just give an overview of an event and then a link to more resources on it. You can then tag the posts with what country its relevant, etc

So then on a country page you could have an overview, raw data, a preview of the "spotlight" story of a particularly current event (+ read more link to blog post) and index of relevant posts.

As an example: We have a little blog post that's a brief (can just be one paragraph) description of Ethiopia vs Kidane. The post can then be tagged "Ethiopia", "United States", "FinFisher". Then just have link(s) to EFF page(s) on the case. And the post will appear either as a spotlight story if most recent relevant article or in the index of related stories.

-Hopefully- by being able to zoom in (for lack of a better term) from the big picture (of whats happening where) to a single event, which would give some context to the human side of things to complement the raw data and do more to interest researchers. Also this would be able to portray how many different "actors" can be involved in a case. In the example: an American citizen is being spied on by the govt of Ethiopia using technology from a company based in Western Europe. Obviously this requires on going work with content creation, but I don't think it would wind up being too much.

TL;DR: javascript makes katie sad and we should make sure any design decisions take into account future development plans

(And yes, anchor links everywhere including map. I did mean to put them there but didn't get around to it cos every little thing I do does require me to learn new things so it can be a bit time consuming.)

[peterjaric]

Being just a minor contributor to this project, I'm all for following the design decisions you (the "founders", for lack of a better word) make, but I want to ask, nevertheless:

Is there a reason you want to minimize the amount of JavaScript?

If it concerns support for JS, I think that many, many sites use JS to a great extent, and my impression is that the absolute majority of all users use browsers with excellent support for JS, even in "developing countries".

Or is it that NoScript users, and other users with JavaScript turned off should be able to use the site? That might be a good reason, considering the subjects this project concerns. On the other hand, how many are they?

Also, the impression I got from the site, with the map and all, when I first visited it, was that there was a explicit aim to use JS to visualize the data.

This became longer than I thought, but I think I am trying to say that JavaScript is just a language, and I think it helps making a web site easier to use and more compelling.

[kkleemola]

@peterjaric Heh, sorry, the comment wasn't clear.

Brennan suggested a perfectly reasonable approach that was simple to him.

My remarks about avoiding JS was intended to point out the difference in thought process between the web dev and those of us who haven't written a line of html since they deprecated marquee. My desire to avoid JS is purely selfish.