DesignGoals.md

MapRoulette 4 Design Goals

draft

Why does MapRoulette exist?

OpenStreetMap, being a crowdsourced map project, requires constant maintenance: map data becomes out of date, mappers make mistakes, mapping conventions are refined over time. While there are tools that allow anyone to inspect the quality of the map data through a variety of lenses, the mapping community also needs a tool that exposes mapping defects as actionable tasks for the crowd to resolve in a organized, systemic manner.

Because no such tool existed at the time, I created MapRoulette in 2012. (Mailing list announcement.)

Even though other tools with similar purpose exist today, MapRoulette remains unique in its purpose, which is:

To give volunteer OSM mappers of all countries, abilities and interests, individual or as a community, small but meaningful mapping tasks that are created by their peers

Before we dive into design goals for the next stage of MapRoulette, it is important to set a strict baseline: what defines MapRoulette at its core? What is the minimal needed feature set to support its purpose as defined above? We will measure any design and architectural decisions against this baseline.

The MapRoulette Core Feature Set

Discovery

MapRoulette wants to cater to mappers of all countries, abilities and interests, and the diversity and volume of tasks represents this. It is imperative that a mapper can quickly discover tasks that meets their interests and skill level. This implies the MapRoulette website must have:

• Relevant, fast, additive task filters to narrow down the task list by topic, skill level and geography
• Natural language text search
• Persistent search / filter results
• A friendly & effective onboarding funnel

Solving tasks

Small, Meaningful tasks are the beating heart of MapRoulette. Mappers have solved millions of them in the past using a straightforward flow: inspect task, edit OSM, confirm, repeat. It is imperative that we retain the simplicity of this highly effective design. Anything that stands in the way of the mapper making progress understanding and solving a task is to be avoided:

• A visual layout that guides the mapper towards completing the task
• Clear, concise task instructions
• Editing tools relevant to the task at hand
• Optional advanced inspection and contextual tools for advanced mappers

Creating Tasks

MapRoulette is a democratic platform; everyone can help make OSM better by solving tasks but also by creating tasks for the community to solve. This is what sets MapRoulette apart from other task-oriented tools, but with the power to create tasks comes great responsibility. Poorly designed tasks can confuse mappers. lead to bad edits and erode trust in MapRoulette. It is imperative that MapRoulette creates the conditions for mappers to create high quality tasks. We need to provide:

• Great onboarding for new task creators
• Technical safety barriers
• Active feedback for creators
• Opportunity for mappers to give feedback
• A Staging environment to test and dry-run task ideas

Interoperability

MapRoulette has always had an open API that lets external applications interact with the data underlying the MapRoulette application with few restrictions. We designed it that way to encourage developers to use MapRoulette to display MapRoulette tasks in other applications. The Rapid editor, OSMAnd and JOSM are examples of applications that make use of this capability to enrich their applications with MapRoulette tasks their users can view and interact with. We see API use expand to include different types of usage, such as analytics or external editing orchestration tools that organizations may already have. Important enabling work includes:

• Excellent API documentation
• Review of existing SDKs (Java, Python) and supporting community efforts to maintain / expand
• Support developers looking to implement integrations to the best of our ability

Community

MapRoulette wants to support individual mappers as well as global communities. Communities can consist of volunteer mapping groups, school classes, groups supporting a cause, to give a few examples. We are cognizant of existing tools and channels through which mappers can communicate and form groups. We will aim not to duplicate functionality that exists elsewhere. We will only build features that directly support global communities and collaboration and provide integration points with existing tools where appropriate. For example, we will not implement a live chat or internal messaging, because third party platforms exist that global OSM communities already use. That said, important enabling features for global communities are

• Crowdsourced Localization
• Social sharing and invitation
• Projects and appropriate user levels (admin, manager)

Help

MapRoulette wants to provide a 'first contact' surface for aspiring OSM mappers. This ambition carries with it a heavy responsibility to educate and guide mappers not only in their first steps in MapRoulette, but in mapping in general as well. We want to use the best available onboarding tools and documentation out there, for example the iD editor walkthrough, and supplement it with beginner-friendly documentation and inline help.

Non-functional

Sustainability

MapRoulette is maintained and developed by a small team. Sometimes there will be paid help, other times there won't. It is imperative that we design the MapRoulette architecture in such a way that we can manage the application with these constraints. That means:

• We choose Boring Technology, key quote: "consider how you would solve your immediate problem without adding anything new"
• We create an inviting developer experience through architectural choices and human connection
• We create the conditions to be able to outlive any current contributors
• We avoid platform / systems vendor lock-in

Trust

First-party editing tools, those maintained by the OSM Foundation, have the highest level of trust from the community. Some third party tools have gained a similar level of trust: Overpass, StreetComplete, and Pascal Neis' tools, to give a few examples. That trust is hard-won—and easily squandered. MapRoulette has gained a fair amount of trust, judged by its continued active use in many communities and the community contributions the project receives. To keep and continue earning that trust, we must make sure that

• We take every effort to minimize bad edits caused by MR tasks
  • This has functional components as covered earlier (UX design, help, documentation) as well as non-functional ones (communication, advocacy)

Potentially Out of Scope

Considering this core feature set, a number of features currently available in MapRoulette may potentially be out of scope. This does not mean that we won't consider keeping them, but we will have to make deliberate choices to ensure we can effectively support the application in the longer term.

• Leaderboards
• Peer Review
• Internal Messaging
• Metrics / Achievements
• Teams