[Feature Request] 6 Suggestions to Improve Category User Interface

[JeroenM]

Introduction

Before I present my suggestions to improve Maps, I shall start with my personal feedback:

"I find the user experience around categories the most annoying thing as a contributor to Google Maps. "

It was this conclusion that kick-started my motivation to study categories in Maps. Since I have learned a lot on the topic and as I became better informed, I also became more surprised how little importance is given to categories. Whilst in my view, categories are the ABC of mapping and offer a great opportunity to educate mappers. Insights, that go beyond the knowledge of what category to use when!

For those that are interested, I have shared my findings in these articles.

Suggested Category Solutions

Suggestion #1

As mentioned in this article about categories from the Local Guides perspective, when typing a category, the system currently only suggests categories using that word. In other words, it does not (smartly) auto-suggests related categories that you might be looking for.

For example, when typing Lookout the system does not suggest Scenic Point as your available option.

When using Google Search, the moment you start typing the system is doing some “thinking” and suggestions pop up that you are most likely to be looking for, yet it was not the wording you used in your search phrase. Why can the category list not work the same?

Suggestion #2

The current system of adding missing places, whereby certain types of places can be directly added by Local Guides and other types of places need to be reported via feedback, is not user-friendly and seems rather unnecessary.

Why can we not, for example, simply add a missing beach and the moment we selected this “Google Only” category our submission is channeled to the job queue for the respective Google department that needs to manually add this beach? The Feedback procedure, the one we are told to use now, is very user unfriendly. Why not streamline the funnel to the right job queue straight from the Edit Form?

This solution would also solve the “unfair” situation whereby Local Guides do currently not get rewarded for such advanced contributions.

Suggestion #3

This suggestion takes the previous idea a step further.

Given the main scenarios when people looking for a category and get stuck, the idea is to have all know categories in the database and to color code them by the following four scenario types.

• An existing Category Available to Local Guides (green)
• A synonym of an existing category (blue)
• A category that is only mappable by Google (purple)
• A category that is not mappable (red)

The big advantage of this solution is that it would solve multiple problems.

First of all, it could prevent people to pick a “workaround category” when the category they are looking for is either not mappable (red) or only mappable by Google (purple).

Secondly, it will educate contributors to map and give insight into why your suggested map edit is not going to be applied (red).

Currently, purple categories are not rewarded and accepted via the normal suggested edit system, but using this idea, those otherwise reported Google only edits, could end up as “Pending” in our contribution list until a Googler looked at it.

Suggestion #4

Forget about suggestions 1-3 altogether and let people simply type the category we think is best. The Google Bots should learn all the synonyms and regional phrases that are used and based on the entry by the contributor, the system should automatically allocate the standardized Google category that is applicable for such a place. Instead of using a category label, people should also be able to describe the place.

To implement this suggestion, it would probably be necessary to go through an intense phase of machine learning at the early stages, but if Google was to make this a Local Guides task, I would be very surprised if it would not be fully embraced by our community. This solution is of course totally in line with Google's drive for AI-driven applications.

Suggestion #5

Please bring the definitions of categories back. It is obvious from some of the forum threads on Local Guides Connect that not everybody is on the same page when it comes to what an actual category stands for.

Misunderstandings lead to bad mapping, so again, use the opportunity to educate users.

Suggestion #6

The above suggestions would, of course, require changes to the User Interface of Maps. Perhaps, it could be considered to have the option to switch between "learning mode" and "standard mode". For those that have learning mode turned on, perhaps it is feasible to have the categories available offline?

Fellow Local Guides, please let me know what you think and feel free to add more ideas related to the discipline categories (as in holistically and not individual missing categories).

[JeroenM]

@Rodrigo_P 

You mentioned in your recent blog post that improvements are on the horizon. I sincerely hope that these improvements go beyond cleaning up the current category list itself. Categories and its User Interface offer great opportunities to communicate in a way that would lead to better quality edits.

[LucioV]

Great suggestions @JeroenM!

[JeroenM]

@LucioV 
Thank you. It has been fun studying this topic, and there was a lot more to it than I realized when I started.

[MWJones]

Well written commentary @JeroenM, I would, as a former Map Maker user and have seen this for a while, would try to answer some of your suggestions.

Suggestion #1

As mentioned in this article about categories from the Local Guides perspective, when typing a category, the system currently only suggests categories using that word. In other words, it does not (smartly) auto-suggests related categories that you might be looking for.

For example, when typing Lookout the system does not suggest Scenic Point as your available option.

When using Google Search, the moment you start typing the system is doing some “thinking” and suggestions pop up that you are most likely to be looking for, yet it was not the wording you used in your search phrase. Why can the category list not work the same?

The current editor being used in maps is a very "basic" editor for place listings, intended for most of the general users, so the lack of features is intentional. It is my understanding from when they closed Map Maker, that a more "advanced" editor was in the works, which could see something like the ability of editing multiple categories per place, as well as other capabilities for listings not currently available in the "basic" editor.  

Suggestion #2

The current system of adding missing places, whereby certain types of places can be directly added by Local Guides and other types of places need to be reported via feedback, is not user-friendly and seems rather unnecessary.

Why can we not, for example, simply add a missing beach and the moment we selected this “Google Only” category our submission is channeled to the job queue for the respective Google department that needs to manually add this beach? The Feedback procedure, the one we are told to use now, is very user unfriendly. Why not streamline the funnel to the right job queue straight from the Edit Form?

This solution would also solve the “unfair” situation whereby Local Guides do currently not get rewarded for such advanced contributions.

 The problem lies in the fact the "basic" editor we currently have only has access to certain "layers" of the map. The transit layer, marking bus and train stations, for example, is locked, and not editable by users outside of Google (Google has partnered with many bus and rail transit companies to get those objects to a high degree of accuracy, and thus errors should be reported to the appropriate transit company). Beaches would be on a "natural features" layer, and likely are not accessible with the current editor as well.

At one point, Map Maker users had access to draw grounds or boundaries. Access to those layers was removed after a bad case of spam, and frequent misuse by users.

Thus, things like beaches will likely be able to have some editing if and when an "advanced" editor is made available.

Suggestion #3

This suggestion takes the previous idea a step further.

Given the main scenarios when people looking for a category and get stuck, the idea is to have all know categories in the database and to color code them by the following four scenario types.

• An existing Category Available to Local Guides (green)
• A synonym of an existing category (blue)
• A category that is only mappable by Google (purple)
• A category that is not mappable (red)

The big advantage of this solution is that it would solve multiple problems.

First of all, it could prevent people to pick a “workaround category” when the category they are looking for is either not mappable (red) or only mappable by Google (purple).

Secondly, it will educate contributors to map and give insight into why your suggested map edit is not going to be applied (red).

Currently, purple categories are not rewarded and accepted via the normal suggested edit system, but using this idea, those otherwise reported Google only edits, could end up as “Pending” in our contribution list until a Googler looked at it.

Again, the problem you describe is the limitation of the "basic" editor. I doubt that this type of change would prevent users from trying to circumvent the rules, since many of the people submitting edits via the "basic" editor have no clue of the rules to begin with.

Suggestion #4

Forget about suggestions 1-3 altogether and let people simply type the category we think is best. The Google Bots should learn all the synonyms and regional phrases that are used and based on the entry by the contributor, the system should automatically allocate the standardized Google category that is applicable for such a place. Instead of using a category label, people should also be able to describe the place.

To implement this suggestion, it would probably be necessary to go through an intense phase of machine learning at the early stages, but if Google was to make this a Local Guides task, I would be very surprised if it would not be fully embraced by our community. This solution is of course totally in line with Google's drive for AI-driven applications.

At one time, Google permitted "free-form" categories, in the "basic" editor as well as via Google My Business. This ended up being one of the worst disasters, as businesses would end up with various categories (or if a category was locked, they would play "misspelling" games with the locked category to get around the lock, thus allowing spam on the map.

The idea of a category matching might make sense, especially where regional dialects might have different names for the same thing, for example in English, you might hear it as a Pharmacy, Drug Store, or a Chemist, even though they all mean the same thing.

Suggestion #5

Please bring the definitions of categories back. It is obvious from some of the forum threads on Local Guides Connect that not everybody is on the same page when it comes to what an actual category stands for.

Misunderstandings lead to bad mapping, so again, use the opportunity to educate users.

Agreed, hopefully this could come back in the "advanced" editor (we had the ability to see definitions in Map Maker).

Suggestion #6

The above suggestions would, of course, require changes to the User Interface of Maps. Perhaps, it could be considered to have the option to switch between "learning mode" and "standard mode". For those that have learning mode turned on, perhaps it is feasible to have the categories available offline?

 That is what my understanding is the plan, the "basic" editor would remain available for general everyday users, while a secondary "advanced" editor would be able to be opened, that would allow additional feature editing capabilities, including direct editing of linear features, much like the former Map Maker. Alas, as is typical with Google Projects, they do not announce new features nor their availability in advance.

[JeroenM]

Dear @MWJones,

Thank you very much for the feedback and taking the time to comment on each of my suggestions. 

The ideas I posted here were not intended to highlight the missing current advanced editing features. I was aware of all you said about subsets, secondary categories, etc. It is all in my 5 articles on categories. If you have time, I would love it if you could peer-review my articles. To get back on topic, your feedback on my suggestions here already made me see ways to improve them. 

ADDED 30/12:
I have read more post on Connect since I wrote this response, that makes me understand better what you were trying to say. I realize that some of my suggestions are indeed caused by temporary inconveniences whilst Maps is still under development. It took some time to sink in...sorry.

My suggestions boil down to three subjects:

1) How to make the current user experience of finding the rights category more user-friendly;

2) How to improve the workflow when users wish to "report" edit suggestions for those "locked" categories of unavailable subsets;
This point is caused by the inconvenience of the temporary feedback solution, as the new Maps (the smart form I talked about) is still being built.

3) Advocating that there is a great opportunity in using categories as a means of educating users about some of the mapping rules;

Suggestion #1 = Why does the system not suggest categories as I am typing?

Like I said, the current UI only suggests categories, whilst you type, that matches the exact wording. The current UI does not make "smart" suggestions. When a user starts typing a synonym  I would like the system to suggest the available related categories in that region.

Example: User types "Dog Doctor" and the system spits out "Veterinarian".

 Suggestion # 2 = Why the Report Feedback feature should be obsolete for suggesting edits.

This requires a bit of reframing in the minds of old MapMakers and a Googler or two 😉
The current (simple) suggest an edit procedure uses forms. The limited mindset that I observe is that somewhere in Google Maps history, people felt it necessary to separate the forms used for edits that are within ones "permission level" and forms to report desirable edits that are outside one's access level (AKA -> Report Feedback). My guess is that this set-up was triggered by the fact that old technology did not have "smart" forms.

The current set-up is outdated!

Using "modern" form logic, it would not be difficult to route those Edit Suggestions outside one's access level to a different processing route. The current Report Feedback form is not only for edit suggestions related to those "unavailable" subsets but for all kinds of feedback. So there must be a process in place where Google has to filter the feedback they receive and channel it to the right department. By keeping all type of edit suggestions together in one funnel, there should be zero edit reporting taking place via the "Report Feedback mailbox".

Having one sophisticated streamlined process for edit suggestions has multiple additional benefits. The most obvious ones are:

a) It allows for keeping a complete history of some-ones contributions, including those contributions outside the current point system;

b) It allows for more transparency in the processing of those edit suggestions that currently go via the Report Feedback procedure. Contributors can monitor the outcome of their edits with the same "Pending", "Approved" or "Not Applied" responses. If something goes amiss, people know when to re-submit their edit suggestion. The current Report Feedback is just a "black hole" to most of us.
c) It offers an opportunity to revise the point system an allow people to be rewarded for edits outside their "access level".

 
I think I might have misunderstood MWJones when saying that there will be a future Advanced Maps editor. I "heard" the current one is the simple one and another app is going to fill the gaps left behind by Map Maker. What I should have heard, the feedback is a temporary fix as the current app is not fully built. I feel a bit daft now, sorry.

What you are saying @MWJones, is that this sophisticated form is reserved for the future advanced editing app. But I don't see why this should be the case? Why stop the average Maps user from reporting a missing beach on Maps, if they have not downloaded this future advanced app you are talking about?

Suggestion #3 = Why including "non-available" categories in the form makes sense.

I realize that this approach may be counter-intuitive if you look at it from a limited perspective. Don't take my word for it and test it, let's approach this as scientists...

Yes, my initial approach here was to use this mainly as an opportunity to educate people (with the colors telling them when something is not mappable). In the interest of data quality, I now realize, that it might be desirable not to color code the "non-available" categories, but to make them part of the automated algorithm and as a filter to catch lot's of undesirable map edits by people that are un-trained and novices in map editing.

It comes down to human behavior.

Example 1: A novice submits a missing mailbox and fills out the form selecting the category mailbox. Now Google knows that there is most likely a mailbox in this location and could still use its AI to verify this with data intelligence (e.g. deep learning from street view images, etc). The person receives a Not Applied response.  After having submitted X number of mailboxes with no success, the system should then automatically alert the person about the mapping rule that mailboxes are not mappable. Meanwhile, the system has been informed about x number of mailboxes.

The second person, one with bad intentions to score points, that knows not to use the category Mailbox and uses another "alternative" category instead, is going to be scrutinized with a harder verification process, as Google is now aware of the fact that there is a mailbox there. 

If that the second person succeeds in adding the mailbox by abusing another category, all it takes is a third person to edit his/her dirty map listing, by changing the category to mailbox. The mailbox disappears from the map, the second person drops in trust-score and Google now knows there is a mailbox there. In MHO a better procedure than the "Never existed" procedure.

Example 2: A user adds a missing bus stop. The "smart" form asks all the desirable questions about which bus route (e.g. bus line 101) that the bus stop is related to, the bus company that provides the service etc. and the report gets channeled to the Google Transit Team and the transit partner that this report relates to.

Additional benefits include:

a) Google is collecting data on currently not mappable places, yet might wish to capitalize on this data with Google Assistant (where is the nearest mailbox?) in the future.

b) The additional information added to the system helps flag dirty map contributions that use the wrong category.

c) Google gathers a lot more data on the behavior of the contributor (AKA trust score).  It says a lot about the intentions/ attitude of a contributor if he A = never touches a mailbox again, ones he/she learned it is not mappable or B= starts to knowingly bypass the system to gain points. Currently, bad contributions get the benefit of the doubt. After all, the person might have made the dirty contributions unknowingly, not aware of the rules. By this approach, the system should get a better idea if we are talking about bad edits made in ignorance or intentionally not playing by the rules.

Suggestion # 4 = Not Free Form Tagging, No Free Form Funneling in Multiple Steps.

This suggestion should not be confused with my first suggestion, where a user might type Drug Store and the system automatically suggests Pharmacy instead (based on the regional language settings). With suggestion #1 you still need to select a category that is available from a fixed list in your region before you can submit your entry. Instead, I am suggesting a multi-step approach.

In the "Add a missing place " form, a person does not select a  category but just puts in a description of a place. This could be a one or two-word category tag, but it could also be a description: like  "a place to get your prescription medication".  The person submits the "first page" of the form and the form comes back with a category suggestion from the existing list to which the person can respond with a yes or no. If it is a no, the system could ask questions to further define the category.  It should not take more than a few questions to clarify the applicable category. An advanced mapper or a person with better taxonomy skills, go straight through. Where the system is in doubt about the category of the submitted missing place, it could ask questions to other users to define the category. Like the questions asked in "Check the Facts" or "Do you know this place?".  

Example: I add a missing pizza place and use describe the place as a pizzeria. The system may respond to my contribution with questions to define if we are talking about a Pizza-Takeaway, Pizza Delivery or an Italian Restaurant.

To clarify, the free-form in my suggestion does not mean that the "tag" used by the contributor ends up on the map, it is a way to funnel the form submission in a more user-friendly way, where it is accommodating lower quality data submissions and allowing them to be improved (selecting the right category) in the process. This process would include opportunities for fine-tuning of category data on a POI, including the decision what should be the primary category of a non-claimed business. 

Okay, that's it for now. I hope I did a better job in explaining the concepts of my ideas/ suggestions this time. My suggestions are all solutions to different "pains" I experience as a Local Guides. Of course, there are always different ways to solve a problem. One is not always better than another. I also realize, that my suggestions are fabricated on limited knowledge of the "behind the scenes" at Google or their strategies related to product development. 

Besides highlighting some of my pains by offering solutions to them, I sincerely hope that some of what I say here helps trigger something positive for the product development team. Fellow Local Guides, please keep the brainstorm going by offering Google with ideas for solutions.

@Briggs my ideas touch on different levels of your recent post with your suggestions how to improve the verification process. Since you are not only a do-er but also a thinker, I very much welcome your feedback/ comments on this post. I thank you in anticipation.

Best (holiday season) wishes to all, JeroenM

[chadindiana]

Good points being made by all. I'm gonna just watch and read for now instead of adding more input.