Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Adding location to SMS/Email datasources. #3534
Which user group(s) are the primary audience for this feature/enhancement.
Include deployment names if possible
Specify key workflows (e.g. crisis, elections)
Specify key use cases (program/data workers, incident management, advocacy/storytelling)
Incident management IMO, but would love people to chime in here and let us know if there's a need for this.
Is your feature request related to a problem? Please describe.
Describe the solution you'd like
I have some concerns on how usable this would be, but I think it's worth exploring/spec'ing out at least?
Tagging @Shadrock in case he's interested in giving me all the reasons this feature idea could be super problematic :)
Is this even a reasonable thing to ask of a non (necessarily) technical user? @Erioldoesdesign specifically might have opinions or data here. Not sure how other platforms do things like this, if at all.
YES! I have huge thought's on this.
I was actually with this deployment owner last week: https://bristolstreetharassmentproject.ushahidi.io/views/map
They just got email submissions working on their deployment but were concerned they'd loose the location data that is hugely important to them. The only way to currently do it is to edit a post before you publish it and add in the location yourself.
There's a few ways I can think of UX wise that could make this work but it wouldn't be 'pure' email.
Essentially what you could try to do is sending an email to a deployment triggers a follow up emailf rom that deployment that includes all the survey question info in the email body and then the responder fills out info in the replied email body. Sends that but then the deployment would need to be smart enough to 'scan' the email for those specific responses.
The other idea I had was that a user sends a report by email. The user receives an email back with a link to their post via webpage/app that is a direct edit version of that post. So here we're asking the user to add more detail to their post themselves so not the deployment owner.
Regarding your idea here:
I'm not sure again, how technically savvy reporter/users will be when trying this. (or even non-techy deployment owners for that matter!)
The only thing I know is that user understand human-worded questions like 'Where did this incident take place? (give as much detail as you can)" and they know to type text into text fields. Asking for a google map exact location could work from some but you probably aren't gonna grab the less technically savvy and also the folks not on smart phones (for sms) they would have to describe their location and machines would need to do the rest.
I think that sadly there's just no standard that fits all countries or user groups. It doesn't mean that nothing can be done, just that any solution would just be a first stab at the problem.
There are standards for geotagging sms , dating from a few years ago. See https://en.wikipedia.org/wiki/GeoSMS and https://www.opengeospatial.org/standards/opengeosms , which has been used with Platform in the past: http://www.opengeospatial.org/blog/1520 .
Detecting and parsing these geo URLs (or even google maps, OSM URLs) in SMS or e-mail messages would be a relatively affordable improvement to this version of platform. However, as pointed out, it probably remains a technically savvy thing to use, because widespread support in the client side is just not there (as in, there is no "Add Geo-coordinates" button to most SMS android apps or feature phones).
Still, I guess it could work for some cases, with proper messaging and training.
As an aspirational blue-sky kind of goal, maybe we would be looking at natural language processing combined with context-aware navigation engine, i.e. something that can parse text such as "Two blocks east of Bishop Magua Center along Ngong Road" . This is the best kind of geographical reference that can be produced in some countries, where people navigate based on landmarks, rather than coordinates or street addresses.
This would be pretty hard to make work reliably, too. Not just technically, which it is, but just because the world is ... very dynamic. If you've got 20-25 mins to spare, this is a talk I really enjoyed: https://www.youtube.com/watch?v=_t5DxV7cXgQ , about the challenges of finding directions in Aşgabat, Turkmenistan.
So even with the biggest efforts, you can only be so sure of how accurate your geo data is. Geo data is not necessarily accurate. ( Which is a reminder of issue #600 , there should be a better job done at capturing that complexity ).
As a first stab at the problem, I really like the idea of follow up questions/instructions via email, SMS (or even chatbot in other platforms), because:
Agree. Chatbot / questionnaire sent in steps to email or sms could work. The problem with the chatbot and targeted surveys is that we don't have a good way to support them appropriately for all our deployments at the moment (ie not just the enterprise/grants) , so to implement something similar we should probably think of how to tackle those two issues in a way that doesn't get too expensive to run and maintain , I think?
+1 , this is a relatively large project with maintenance costs for .io , if we want to make it as a more complete/multi use thing.
I think this is true, I am just somewhat conflicted with that perspective, from the point of view of roadmap building.
Just a personal thought forming here: as Ushahidi as an org opens up and encourages development on platform, there may be things that fall outside of the appropriate cost/benefit spot for rolling as a SaaS solution in ushahidi.io . In other words, I'm not sure I'm anymore at the point of not wanting to see a feature in the platform roadmap, just because such feature is not SaaS friendly.
ushahidi.io , being a SaaS solution, could present itself as the most vanilla flavor of platform. The baseline that is quickly available to anyone. And that can be OK, hugely valuable.
It's of course good to try to raise the baseline as much as possible, but it may not be beneficial to expect each and every initiative around this project to want to stay close to that baseline.
regarding io as a vanilla version of platform:
I would argue that a basic implementation for this should be part of vanilla/io, but it's important to realize that it doesn't have to go to .io from the beginning, so thank you for that nudge, I appreciate it.
Hello all, thank you for this very interesting convo @rowasc as well as your help in the chat
My 2 cents concerning the UX, as I understand it there are several features in this feature request:
1- Feedback: I like the idea of sending back an email to let the user know what we understood of his submission
2- Better ways to collect info by email, closer to web, more structured: the feedback email of 1- could ask for the missing info, and probably let the user a chance to change the submitted info
3- The ideal feature for me would be to be able to automatically geolocalize the user and this would be available as an "Email field" and "SMS field".
Thank you @lexoyo for the points!
I think 1 and 2 are much on spot. As I see it, the main objective here is to reduce the workload for an organization that is running a Ushahidi deployment.
Presently, running a deployment can mean having significant amounts of people dedicated just in order to give structure to posts: converting (copy-pasting) plain short messages to the structure of the survey, and following up with the reporter to ask for any missing information.
Automated E-mail, SMS and chatbot interactions could lighten this load a lot.
I feel there will probably always be a manual step, for confirming that the reporting end understood and fulfilled the interaction properly, but that is still a lot less work.
About item 3:
No, it really doesn't, in all of the cases we have seen. It's true that cell tower triangulation is a thing ( although not sure how much it's ingrained in the comm protocols involved), but we have never seen such data trickling down to the consuming end of a SMS gateway.
This is interesting. If I understand it correctly, you mean that the platform would translate the origin IP address requesting the image into a location? Unfortunately, there are many factors that hugely diminish the accuracy of this: outdated IP-to-geo databases (varies by country), transparent proxies rolled out by telcos, VPNs... map markers can easily end up in completely different countries because of any of these.
There are cases where the geographical data is there, as a feature that the comms platform provides. Prime example is twitter. Many users send their geolocation with their tweets. However, twitter terms of service disallow storing and aggregating that data, iirc.
And finally, some people may just not be comfortable with sending their precise location, specially without them knowing they are doing so. I think that, when it comes to location, explicitly asking is best.
+100 for this statement:
The safest way to collect that kind of data is to explicitly ask for it and ask the machines to try and make sense of anything more 'fuzzy' like 'I'm at the corner of rue de garibaldi' and then the deployment owner verify, confirm or change those details.