POST: dropchop and the community

[mapsam]

I want to turn my slides at https://bit.ly/gisforthepeople into a post

[mapsam]

From the slide notes: http://bit.ly/gisforthepeople

---

SLIDE 2

Late one night with a buddy during the foss4g-na conference in the Bay, we started playing around with click and dragging geojson files into the browser.

It wasn’t anything terribly special, but we were curious what the lift was like.

SLIDE 3

We spent a good amount of time learning about the FileReader javascript spec and running back and forth with file blobs.

SLIDE 4

Eventually, we had this. You could drag a GeoJSON from your desktop and read it as JSON in the browser.

SLIDE 5

We just got a spatial data file from a computer, into the browser, with just a little bit of javascript and no server.

Then the ideas came swarming in.

This was a small step in what could be a much larger thing. No time for sleep.

SLIDE 6

If we could get geojson in the browser, we could put it on a map right?

SLIDE 7 - 10

So the natural next step was to load it into a mapping library and see what happens.

Well, it worked! We could click and drag anything and show it on a map. Boom!

If we could get geojson in the browser, we could put it on a map right? So the natural next step was to load it into a mapping library and see what happens.

Well, it worked! We could click and drag anything and show it on a map. Boom!

Then we started thinking bigger. This hot new tool called Turf was relatively new. Turfjs made a lot of spatial operations available in javascript, executing on the geojson spec. If we were dragging spatial data into the browser, couldn’t we start manipulating spatial data in the browser? Could we …

SLIDE 11

could we drop files into the browser

SLIDE 12 & 13

and chop them up with Turf.js?

Thus, dropchop was born.

SLIDE 14

So we forged ahead under this hypothesis.

GIS doesn’t always require a server.

Sure there are some gigantic operations that browsers just won’t be able process, but what about all the little things? The quick buffers, the polygon simplifications, and the beziers? Could we start decoupling some of the more modular GIS operations away from larger software?

SLIDE 15

We reached this point. Buffer was working, on an incredibly fast rate (not as fast as this gif), that wasn’t affected by the browser’s limitations.

SLIDE 16

We pushed it further by looking at a number of geometric operations, statistics, simplifications, and unions available in Turf. There are a lot. So many that sometimes you have no idea what you’re able to execute. We didn’t like this. And any person coming into a small tool, without a background in GIS wouldn’t like this either.

SLIDE 17

What if we could show which operations were available based on the data uploaded, rather than giving them every possible operation?

SLIDE 18

This leads us to our second driving hypothesis.

GIS can be data-first, not operation-first.

SLIDE 19 & 20

It’s possible! We got to this point and started cruising after some in depth looks at the Turf source and GeoJSON spec.

Caveat: dropchop isn’t really good at this yet. We need help!

SLIDE 21

To get things moving we needed help. Not just developer help. This led us to a third operational perspective (less so a hypothesis)

GIS is open.

Not just open sourced, but open for interpretation and welcoming to those wanting to get involved.

The best way to get this thing rolling was to make the project accessible, and assess where contributions could come from.

SLIDE 22

In the spring we had a fling with nearly 100 people talking about open source geo tools in Seattle

Broke into working groups and had about 40 people on their computers all installing dropchop

This took time, and honestly having 40 people installing Grunt and npm dependencies and anything javascript turns into a nightmare. But this was just step one.

SLIDE 23

Over the course of four hours we had split into three different groups comprised of GIS technicians, coders, designers, and everything in between and started making progress.

People discussed implementing new features, manipulating turf functions to work more effectively within the app, and helped each other break through some really difficult barriers.

SLIDE 24

My partner in crime in Seattle, Andrew Powers, remembers planning and executing a 4 hour working session on a single javascript application.

QUOTE

I think the last part of this is really powerful, and it has made me think hard on what contributing to a project means, especially a project that is largely centered around code.

I’ve come to this...

SLIDE 25

Contributions are so much more. Putting a project on github is super beneficial for a lot of reasons: version control, getting help from experts, issue tracking, feature implementation, and conversation. But it throws up a barrier really quickly to those not only unfamiliar with code, but those who have no interest in writing code. And GIS is much more than writing code.

Andrew hit it home by understanding the audience we were working with. People who want to write code will write code - and you can make any number of changes to a project to make that happen for even the most novice of programmers. But if your project is centered around code, hosted on github, and tracked in issues - you instantly throw in a level of hazy complexity to those who want to help in other ways, for those who have no need to install npm and all of the project’s dependencies.

So I leave you with a few takeaways from working on dropchop thus far, and what we hope to keep in the front of our minds as interest grows.

SLIDE 26

A lot of people don't want to be a part of the whole path of contributing to a project. Sure, installing all of your insane javascript dependencies is necessary for someone who wants to commit code changes, but is it necessary for someone wanting to rethink UI? What about someone who wants to just ask a question or submit an idea or play around with the color scheme?

Projects and project maintainers should be open to contributions small and large. Let people bite of however much they want to chew. Don’t push them to be more involved if they aren’t expressing interest, and don’t contain contributors who are wanting to raise the ceiling.

SLIDE 27

To continue with the path metaphor…

let people step onto the path and off the path at different points.

Avoid exiting the path because of barriers. It’s important to build the stepping stones for a project for anybody interested in participating, but almost more importantly, make sure that each contribution, no matter the size, concludes effectively and gives your lovely contributor a sense of accomplishment.

Something about post-user experience?

SLIDE 28

Finally…

Empower those who might be using your tool. Get to the point where feature prioritization comes from the ground users up, rather than the maintainers down.

One of the most rewarding and productive things working at Code for America this year has been sticking to a strict user testing regiment. Put the tool in front of someone and ask them to complete a task, you’ll quickly realize how many of your assumptions dictate decision-making. Assumptions are really powerful (and sometimes in the wrong way), I urge you to question and test them.

CONCLUDE: A GIS, or any tool for that matter, built by developers and spatial analysts is only going to work well for developers and spatial analysts.

SLIDE 29

Quote from a guy

SLIDE 30

Whammo.