Difference between revisions of "User:ShadowMasterCM/UR Handling in NYS"
|Line 28:||Line 28:|
== Scenarios To Consider ==
== Scenarios To Consider ==
#Age of URs:
#Age of URs:
== Processing URs ==
== Processing URs ==
Revision as of 21:30, 14 June 2016
New York State has had a significant number of Update Requests created within its borders, creating a unique testing grounds for what works, and what does not, when it comes to handling Update Requests [UR].
History of NYS URs
During the Fall of 2014, there was Map Raid conducted in the general NYC Region, and at its conclusion all pending URs had been 'flushed' from the map. At the time it may have seemed like a huge victory against the seemingly never ending flow of URs.
However, many new URs quickly filled that void in the NYC region, as well as continued to build up through out the rest of NYS. Approximately 1 year later, NYS had roughly 30,000 pending URs. Yes, I said 30 THOUSAND URs, just in New York State.
Google Hangout was initially set up for the 2014 Map Raid, and was eventually converted to "NY Editors" and is now used as the primary communication platform for editors working on New York State data in WME.
During the calendar year 2015, NY leadership had recruited several new editors and began training them. Eventually, the training and knowledge shared in NY Editors started to pay off. More editors were focused on fixing map data issues, rather than flushing URs. Fewer repeating URs were being generated. Editors better understood the issues and could recognize them faster, and resolve the map data issues faster.
However, despite the best efforts of the newest generation of NY based editors, as well as the occasional visiting editors, it never seemed like the UR issue was getting any better.
UR Data Collection
Data collection about the URs of NYS began at the end of December 2015, using the 'stats' section of the UR-MP script. The collection of the data was refined and eventually was formatted in a way that we could look at it and review exactly how bad the UR situation was in NYS.
Why URs Matter!
Hopefully by now, most of you have heard or read, 'Quality Over Quantity". Most editors understand what that means, but for some reason it is quickly dismissed when processing URs!
Corporate America has done significant research and determined that most customers will not bother to complain, they simply go somewhere else. Modern society expects instant gratification and insists on perfection, even from a 'free' app like Waze. There are so many alternatives available for GPS, that we must take extra care that we not leave any user dissatisfied with Waze, or the data that we as editors manage in WME.
So now consider that some user of the Waze app, had something not function as they expected, and that they bothered to submit a UR. That UR is possibly the one and only chance, we as editors, have to make the Waze experience better for that user.
Poorly handled URs likely will result in disengaged users that uninstall Waze. Lower user counts likely decrease sales of in app Ads. Those Ads are what pay the expenses to keep the app free.
Less users, lead to less ads, which leads to less need for editors!
Scenarios To Consider
- Assumptions: Many editors are have been taught to make educated guesses about URs and simply close them. However, consider this could result in incorrect assumptions about the actual issue, resulting in a confusing experience for the user. Imagine a user submits a UR about a newly constructed housing tract they live in. They send a 'General' UR type with no additional information as they pull out for work in the morning. An editor then finds the UR, and notices something odd in name of the main road in WME, fixes that and closes the UR with a comment about 'road renamed'. The user now wonders if Waze staff is incompetent [many think staff does the editing, not volunteers], and the street is still missing. Even worse is the editor that simply closes that UR with out a comment, leaving the issue unresolved and likely an angry user. Avoid 'educated guesses' and assumptions. ASK FOR MORE INFO!
- Age of URs: Many editors have personal opinions on how old it to old, meaning it is simply a waste of time to send requests for info to any UR that is XX days old. There were URs discovered in remote areas of NYS that were 3+ years old. Each UR was sent the standard request for additional information. Many were not responded to, and were eventually closed as "Not Identified". However, there were also several dozen that DID respond, and provided enough information to help fix major issues with the current map data. This included adding an entire housing tract, including street names and house numbers!
- Reminders: Many editors consider 'Reminders' another waste of time. Let us consider how busy each of us are, and how often we have to reschedule tasks, or simple forgot to do something. Why should do we think Waze users are any different. We all need a reminder from time to time. Leaving a UR on the map for another week does no harm. It can end up being very useful if the user responds to the reminder, and provides information that helps resolve an issue with map data.
- Weekend Warrior: This is an expansion on the Reminder comments above, but it deserves its own explanation. Many people that own GPS devices often only use them when they are going on a special trip or to a new destination. Many of them do NOT use the GPS to navigate to/ from home/ work, because they feel they 'already know how to get there'. So a parent taking the kids to the 'away game' may use the GPS to get to the sporting event. Family outings to a park or camp grounds over the weekend. Special events like NASCAR races and NFL games are not usually something we do every week and 'know how to get there'. So a user opens Waze of Saturday morning, has an issue on the way to the 'event' and sends a UR, and then later Saturday night closes Waze. Sunday or Monday an editor finds the UR and requests more info, and then 3 or 4 days later, closes it since they did not get a reply. Even if you waited as long as 7 days, but did not send a reminder, there is still a significant chance you will close the UR before the user ever opens Waze again. This leads back to the disengaged user mentioned above.
Update Requests in Waze Map Editor https://wiki.waze.com/wiki/Update_Requests_in_Waze_Map_Editor
Solved If you are able to identify a reason for the reported issue, and if you are able to fix the problem in the editor, fix the problem and save your changes. Then mark the update request as Solved. Not Identified For various reasons, such as lack of detail provided by the Wazer, or conflicting route vs. drive trace information, you may not be able to identify the source of the reported problem. In these cases, you should attempt to initiate a conversation with the reporter.
The resolution process / Etiquette Promote harmony between editors and the reporter, and improve the good reputation of Waze and its user community Promote harmony among editors and prevent conflict or duplication of effort Engage the reporter productively, efficiently, and courteously in the problem resolution process Missing information
There are many ways to overwhelm the reporter!
Non-responsive reporters without prematurely closing reports that could still be worked on, with resulting map or routing improvements.
Multiple editors take ownership vs shared ownership
1) request more info / clarify as needed
2) wait 7 days
3) send reminder, with info the report will end up closed as Not Identified, if we don't hear from them
4) wait 7 more days
[Note: this reminder step and waiting longer is newer guidance we are using as a trial and will likely become the official guidance at some point based on results from it so far)
5) still no response - scan general area for worst / obvious issues - this is where you can apply best guess scenarios - find something that needs fixing in this area - look harder if you can't find something!
Always close a UR with a comment
Even if only to say it's being closed as NI
Avoid longer overly complex replies in UR.
Add closing comment encouraging user to send more URs when needed in future.