If I had 60 minutes to save the world, I would spend 55 minutes defining the problem and 5 mins solving it - Albert Einstein
If I had 60 minutes to save the world, I would spend 55 minutes defining the problem and 5 mins solving it - Albert Einstein
Whichever version you have heard of the quote above, be it Einstein, Lincoln or others, they speak to a very critical aspect of tech development. Being clear about a problem (or six), will more likely lead to a useful solution. It is for this reason, that before the team at hot_tech starts ‘solutioning’, we must deeply understand the pains and problems that plague our space.
Further boiling down our findings from our Design Sprintathon posted last week and sharing more of our learnings over the last year as we engage deeper with the HOT and OSM collectives, the following post is a reduction of many conversations into what hot_tech sees as the most rich and flavourful version, from the source.
The list below is a summary of the full list here for comment. It is by no means an exhasitive list of all problems that exist, nor it is a hierarchy of which problems are more important than others. Rather, it is a list compiled of the voices we heard and what they told us was important to them. It is a list of causes and effects of pains and problems that our team desires to explore further and contribute to easing. By seeking relievers for these pains and problems, hot_tech feels we can either enable or amplify the work of those that choose to use our products as a means to meet their ends. We don’t expect our solutions to be silver bullets, nor do we feel we are the only group who can do it, but these are the problems we feel we can make both valuable and meaningful contributions toward resolving.
After reading this list, we encourage two things:
We will keep this feedback open for aound a month (end of May) and then we will collect the feedback into a ‘problem statement backlog’, which will be open to our collectives to collectively prioritise and guide hot_tech on what to tackle, when and in which order.
The summary list below contains:
A short summary of why this problem is a priority
Map inequity is a statement that recognises multiple conversations currently happening around us. We see this as a result of a countless lower level manifestations. In fact, in one way or another all our problem statements interact with map inequity at some level. We feel this is an important problem that goes far beyond the borders of technology, however, we also feel technology can play a critical role in contributing a more equitable and representative map in the future.
Accessibility is a resounding pain point for many users in HOT and OSM ecosystems. The statements collected below reflect the challenge many face identifying what they need, which tool will help them meet their need and then how to navigate open source software reliability. This process costs users time and often turns people away from wanting to contribute.
Most know the ‘QIQO (Quality In, Quality Out)’ principle. Without an objective standard of quality, anything that follows is likely unreliable or redundant. As the number of mappers grows, so too will variability in quality. Developing tools that prioritise and promote quality mappers, quality mapping and quality maps, will help to manage and mitigate the future influx of data and possible quality issues.
We know that knowledge is power, so when data is accessible and used by anyone its power is amplified. It is therefore critical that once high quality data is contributed, it can then be equally accessible and used to maximise the value of the data to individuals, communities and stakeholders to improve agency and equitable societies.
For some mapping is a lifelong journey of learning and discovery, for others, it is a short trip motivated by a single event. Often ‘mapping’ is promoted or perceived as a quick and easy way to ‘do good’, without full recognition of what it takes to create reliable data. If learning is overlooked, people often miss out on opportunities for growth and improvement and quick edits rarely lead to quality endpoints.
Historically there has been a critical disconnect between remote and local groups of mappers. This disconnect, while spanning geographic locations, also spans culture, values and most importantly identity. We recognise a shift in the HOT and OSM ecosystem and a need for closer connections and improved communication between those who are there and those who are somewhere else. While we don’t expect to resolve some of these issues by throwing a message feature at the problem, we do aim to improve the communication between local and remote groups, so local collectives can drive the direction, needs and priorities that impact them directly.
We look forward to hearing more from more of you.
Comment from SomeoneElse on 19 April 2021 at 14:31
Are you perhaps trying to enter a competition for the Plain English Campaign’s “Golden Bull Award”? Come on - “solutioning” - really! Even better, the links are to Google Docs files so many of the people that it’d be great to get feedback from simply won’t be able to read them.
If I was to make one suggestion it would be this:
HOT as an organisation should take more responsibility for users of platforms such as https://tasks.hotosm.org , and especially for ensuring that people posting projects there are educated about what they need to do, and if people fail to do what they should HOT should take action to ensure that (a) existing tasks are taken down ad they don’t create new tasks and (b) any problems with existing data are sorted out. With a DWG hat on I’m currently tidying up some of the mess left around the world by the company that Pete Masters talked about here. Unfortunately, poor-quality contributions where there isn’t a significant local OSM community won’t often be seen - the DWG are still getting reports in dribs and drabs as locals try and communicate with the problem mappers, nothing happens, and they come to us instead. In his reply, Pierre Béland summed up the sitation very well - this is not an isolated problem.
We (the DWG) were requested by HOT to delete everything that these contributors had added (in practice we’re only doing that where the quality is so bad that starting from scratch is less work than amending what’s there; but unfortunately that’s true in most cases). At a rough guess** I’d say 10-15% of these problem edits had been detected by other OSM users in the 15-20 or so days since these edits were made, suggesting that 85-90% were not.
Andy, from the DWG
** difficult, because changeset sizes vary
Comment from bo_hot on 19 April 2021 at 14:47
Thanks for the response!
The tongue in my cheek when mentioning ‘solutioning’ (implied by the inverted commas) may have been removed in the markdown ;) .
Comment from redsteakraw on 20 April 2021 at 02:23
I would say that the process has gotten a whole lot better over the years. iD is making it a whole lot easier for many to edit, they can even edit on a cheap chromebook which makes that tool accessible to many. Adding data from editors can be localized so memorizing or learning the technical side isn’t really needed as much. What I have noticed irregardless of what group or what mapper is that OSM allows anyone to map pretty much what they are interested in. If you like churches you add churches if you like movie theaters you add movie theaters if you like hiking trails and walking shortcuts you add them.
OSM is open the data is open and yes the contributor still technically owns their edit and can re-license their edits and place them in the public domain if they wish. OSM I feel has done more than any other project to expand it’s reach to as many communities as possible but again this is based on contributors so if there is no local community editing tourists and couch mappers will be the ones adding to the map. I see this as a marketing problem rather than inequality, as no community or even a person will ever achieve equality in anything there will always be variability. You can market to communities and try to attract and grow a community if there is a void but that is it’s own problem.
As someone who has contributed to HOT I can say I tried my best and didn’t try to do a low quality edit but I know without having at least some understanding of local architecture and landscape there will be mistakes. I also know that there are simple things that can make a big difference like charting major roads that connect towns and cities, having accurate place names with the local names and having at least some of the important infrastructure mapped such as hospitals and health care facilities. I know that I was able to download the maps offline onto my garmin and was able to navigate at least from city to city and knew if I took a wrong turn off a main road and that helped greatly in getting around. Even if I didn’t know every road in town or any road names.
I would also say that remote mappers aren’t the be all and end all. They are best done when paired with on the ground mappers so buildings can be added and roads. Then a team on the ground adds names and POIs from the street level. I like to call that the double tap, as having even a sloppy edit but real roads and buildings roughly in place it gives you something to print out or utilize on the ground. I have done some edits this way to great effect.
What I would like to see is a vector map standard that is picked up and used by all of the online maps and apps so every app isn’t rolling their own maps or having to create the infrastructure for them from scratch. You could have dynamic theming or rendering highlighting features you want to emphasize or not . Which could make it easier for people to make the maps that matter to them
The other thing I would say is what is the target method of consumption. Are people using budget android phones, iphones, chrome books, desktops, printouts on paper or posters, atlases? Like anything you need to know the audience so you can cater to them. If you want people using the data you need to know what data is important to them and how they most likely can or will consume said data. So here is where I say marketing may be the real issue. Without know these we can’t sell the idea or show the importance easily of the project.
OSM like many international projects Unicode being another face unique issues in dealing with multiple cultures, languages and communities and making things easier for the whole world to make use of it. I don’t think diversity is an issue especially when you are dealing with data now attracting a community and marketing to them so you have sustainable high quality local data is where you will naturally get to more usability and more equity. We have to know what people need and how to provide or help make it easy for them to provide for themselves.
We have the tools getting better and making things more accessible but yes there is always room for improvement. Knowing what more people expect or need or how to provide the right tools for their uses cases can be important. Having better communication between different communities also can help as well. But at the end of the day if we don’t know the intended audience and their needs no real solution can be had and this is true for more than just OSM or maps.
Comment from bo_hot on 20 April 2021 at 14:50
I really appreciate the thoughtfulness and time you took to craft this response. The feedback is really well recieved. I equally appreciate both the problem identification and the solution proposals. I’m going to go through it a few times just to make sure I understand all the pieces, but I will definitely be integrating this into the core doc.
Comment from philippec on 21 April 2021 at 16:35
I have not read the texts.
What I know is that some people invent problems for a living.
Comment from redsteakraw on 22 April 2021 at 11:38
to simplify you need to identify
Comment from bo_hot on 22 April 2021 at 11:50
Thanks for the feedback @resteakraw,
So linking that response to the initial question, ‘which problem resonates with you’, it would probably seem like you are referring to the problem statement related to ‘Technical Barriers to Entry’.
From what I interpret your response as, you may also be pointing to another significant problem which we may not have stated above. Perhaps relating to a lack of user prioritisation in product development?
Comment from redsteakraw on 22 April 2021 at 12:20
This isn’t a lack of prioritization, without a knowledge of a local language you can’t localize the tools, and without the knowledge of peoples needs and how they interact and use maps and what data is important you can’t tailor anything for that. Without any information you wouldn’t even know there is a lack of priority. Everyone is doing their best and doing their own thing there has been great progress that has been made already and excellent tools that have been created. Like any product or service you need to know the audience but in this case the audience is the entire planet so you have to try to zoom in on a given population as an example. Right now there are many use cases and the basics of street navigation and tagging place names and other infrastructure is all there. I have mapped using everything from a handheld GPS + camera and walking papers to a modern smart phone the barriers are shrinking given the amount of cheap tech and cheap consumer devices with GPS. I can’t say what the situation is on the ground but with walking papers just a printer and a clipboard and pencil is all you need if you already have remote tracing and edits to work off of and a single computer can compile the data and add in the information from the walking papers. I have done this so I know it works. I have made edits off of a cheap consumer netbook for years now and can say yes it is possible to edit and work on OSM with less powerful and cheaper hardware. I think you may need to see what are the things on the ground in the various locals and what resources or tools do they have then have the information and tools tailored to those communities that match their situations. Basically without the information of a given community you can’t adequately meet their needs.
Comment from bo_hot on 22 April 2021 at 12:43
I very much agree with what you’re saying. In fact, so much so, that we dedicated the last 4 months specifically doing exactly what you are suggesting. If you have a read back through of my previous diaries, you may see the approach we took is similar to what you are suggesting.
The problem statements in this post are the outcomes of exactly the process you mention, so it would be great to maybe hear some feedback from you on the previous process we undertook to understand what local mappers need.
I think you make good points, but I’m still a bit unclear, do any of these problems resonate with you?