IssueTracker

Does not seem like a good idea to make this the default behavior without an option to switch it off, see also: https://issuetracker.google.com/issues/112553336

we have suffered the same situation

#2 there is an option to switch this off, please see suggestion in the original #1 and load v=3.33

#4, this is only an option for as long as v 3.33 is not deprecated and as long as one doesn't mind using an outdated version of the API - so it's a temporary fix as opposed to a permanent solution.

How does this update possibly make anything better? Controls are huge, ugly and look totally out of place in many use cases, like a sore thumb. They are also buggy:

- Containers with no icons in them
- Or, icons in containers that are completely misaligned

It breaks and defaces many websites. So now I'm forced to update maps code for the millionth time just to keep it working normally and as intended. You vastly underestimate how much you impact small website owners with serious resource constraints. Proper API design means stable functionality without breaking changes.
This has happened so many times now that as soon as time allows for it, I'll switch to another map provider, because this one cannot be relied upon.

I know you don't care, and I apologize for the rant, but this continuous breaking of something that works fine is maddening.

How do you push out updates like these without testing and breaking a huge number of sites that use your service?
You should be maintaining defaults and setting these sort of things as opt-ins..
Plus how was this approved by the design team? Sticks out like a sore thumb, like a 1 day rush job for an issue that seems like it would've been low-priority with a large amount of time allowed for completion.

In an increasingly touch operated world, we have found that both on laptops and mobiles users are struggling to reliably hit the controls when using touch screens. This does not only affect mobile, but also includes laptops and even desktops to a certain degree, which are increasingly shipped with touch screens. This change is about the input modus touch rather than mobile device. Since touch can happen on any device and we can tell in advance whether the user is going to use the mouse or touch screen, and since the first task of controls are reliable operability we have made these controls available everywhere.

We would gladly take bugs/example of website where the containers have no icons, or where the icons are misaligned or examples of broken websites.

I have issues with maps in iOS webview. The controls ( + and - for zoom) are not responding (or amazingly slow to respond). (I can provide further hardware details on request)

It is ok for the android webview.

Regarding the design issue, I agree with the fact that bigger buttons shall provide a better User Experience, but the controls are covering too much of the map, and thus, make the User Experience worsen.

Why not simply make the controls grow +50% on first click on any controls ?
And let them get back to default size if the user finally not using controls for interaction ?

As a response to #8, here are some examples of broken UI.
I work in the EV charging industry, so that's where these examples come from, but this sort of thing can apply to any industry.

1) https://evhighwaystatus.co.uk/
2) https://chargehub.com/en/charging-stations-map.html

If you look at the first one, you can see that as these control buttons have had a standardized size and position, developers have assumed and learned to place other UI elements next to them. They give enough space and padding via css, but then when the google UI elements suddenly change, you can see how the UI is now broken and you have things overlapping. You can blame it on "well you weren't supposed to assume that, you're not supposed to put things there" but depending on the situation, developers have to make custom action buttons and such so the correct way to push a change like this is to inform the developers using and paying for your product, give them a heads up and not just suddenly force it on them as a surprise.

If you look at the second one on mobile, this is probably a far more common experience to have these google UI elements enabled - you'll see that these buttons are just way too big. Granted some of these websites don't have the best UI design, but look at the [Map | Satellite] buttons, they take up _over half the screen width_! If you look at the height, too, that's 1/3 height of the page on an iphone X that you're dedicating to these controls. While I'm all for better touch controls, there's a delicate balance between having big enough buttons and enough screen real estate to see the underlying content. This is _especially_ true for maps.

Here I can provide more examples of broken UI in the first and second screenshots, plus other screenshot with an example of what #10 says about developers placing elements next to standard controls and making them look pretty similar.
Two quirks I notice: inconsistency on the "drawing tools controls" because they still have the small size and the bigger icons in satellite view lack of border and shadow, they are just square white boxes that seem a bit sloppy.
I'm in favor of having better touch controls but the huge size could be optional.

Example:
https://www.jungledragon.com/image/63498/elephant_hawk-moth_side_view_2.html

- The size of the controls completely defaces the website. Controls are 3 times larger than the rest of the website, breaking design integrity. I've already had dozens of users email me what happened to maps. The real function of this webpage is the photo, with map data as secondary input. Now the eye is drawn to this hideous sore thumb. This is a bug you released, not an improvement
- The size of the controls eats away a lot of space on the map itself
- The fullscreen icon is misaligned
- Empty icons is harder to reproduce, had the problem yesterday, not today

In your complete disregard for existing websites who are not obsessed with mobile first or making everything oversized, I assume you will push through anyway. Can you confirm this, so that I can first disable all controls (better than this), and then switch to another provider?

This is totally ridiculous. There needs to be a configurable option for this. You have options to turn the controls on and off, and options to set their positions, so it only makes sense to provide options to set their size as well.

Hmmm... if this is true:

"As we are seeing increases of touch operations on various devices, we adjusted the control UI to fit for both finger touches and mouse clicks."

Why aren't your own maps aren't using the larger controls?

https://www.google.com/maps/

People are asking questions on stackoverflow how to solve this. Users are emailing why the page looks so weird. Isn't that the ultimate proof that this is a bug, not a feature? It breaks things in radical ways, across the web. It has pretty much universal negative feedback, how many signals do you need to rollback and realize a mistake?

Typical Google.

I don't understand how you guys can just change it like that without leaving an option for the user to configure the size of the controls. It's simply outrageous.

The button size should really be configurable in the Control Options parameters

I "solved" this problem by just turning off all default controls and making my own control buttons (zoom, fullscreen, etc) that look/feel identical to v3.33 ones. The hardest one is fullscreen since they don't expose a Map API method for that, but I just inspected their code to see how they used the JS "requestFullScreen()" feature.

Apologies for the cross posting, but we originally posted it here:
https://issuetracker.google.com/112553336 #14

We have authored an example of customer controls in this code sample. Where customers can fully use their own CSS to style controls how they feel is appropriate for their page.
https://jsfiddle.net/q40abnmL/

(It shows how we do fullscreen)

We have moved the sample to the developer site.
https://developers.google.com/maps/documentation/javascript/examples/control-replacement

With this approach, you can edit the CSS to make the controls look like the other buttons on your site.

To offer up a workaround to this that increases time to code something honestly is frustrating the need to enlarge something was not there poor decisions and design

I have implemented the workaround, but I don't feel that I should have had to do this. It should not be the default.

I note that Google itself is still not using the larger buttons in its own Maps product. https://www.google.ca/maps

If Google's own internal team won't even use this misguided UI design; I think that says it all really. .

I agree. To add work for users in order for them to  undo poor design without the ability to opt out while your own  apps still are not using the bad design is poor service to those who are paying to use your product.

Totally agree with #23
Google seems to fuck around with developers recently without any notice.

If you decide to change something, make sure you allow users to switch to the default functionality at any time!

Yeah, we cannot accept this change.

I don't give a shit what your usage stats say about touch use - you have paying customers who rely on this API, and believe it or not, lots of those customers build specialized business software intended for use only on desktops. Abruptly making changes like this, with no way to revert them, shows a complete disregard for your customers needs - this now makes our products look broken, and thus makes our customers, and us, extremely unhappy. Locking the version we use is a temporary solution at best, and providing some nasty example code to implement some half-baked custom controls, that not a solution - that's incompetent, disrespectful and unacceptable.

I'm not even going to say please here - just show some respect for your customers and add an option to revert this immediately.

This change has been announced in several places for a quarter now. This issue in fact starts with an announcement.
There is a way to revert them, as there always has been with all changes we push. Simply adjust your JS version to the previous version and you will get an immediate revert. As it is with all our changes, they are first announced and then they are rolled out over the versions over a 9 months period.

If developers want a different look and feel than the default we provide, we recommend that for the time being you fall back to the version you were already using, and then follow this sample https://developers.google.com/maps/documentation/javascript/examples/control-replacement which shows a way to go forward where developers are in control of the looks and feel of controls on newer versions.

Answering to #27, exactly for that we are not approving this change and requesting and REAL solution to revert this, as simple as boolean parameter in options to initialize the map.

I'm very dissapointed with the sample you provide because it doesn't show a proper way to add the missing controls to the map, such as pegman for street view, rotate and tilt buttons on eagle eye view, terrain and labels options under map and satellite buttons. The documentation for controls https://developers.google.com/maps/documentation/javascript/controls doesn't say anything explicit about that as you can see on the attached images to prove my point. Also on the sample when you click a button it leaves a blue square (I'm using last version of Chrome).

I'm very upset with this, seems a lot of work for the developers to make the controls look sleek and elegant again in our apps for something that was given and totally functional with the default UI. Switching to the previous version is only a temporary fix because eventually it will be decrepated and no longer supported.

I totally agree with #28 (and many other before...). You perfectly know it isn't serious suggesting as a "solution" to remain stuck to an old version of API.
I just don't grasp why you didn't put a parameter, eg boolean or either (small, medium, big) or whatever.
Please release a patch with just this change...... millions of developers will be grateful.
Because the suggestion to not accepting updates means in other words...... well if you don't like Google's product then take a look around, there are alternatives!!!

Based on the feedback that have received we have decided to change our plans a little bit and add a controlSize map option to Maps API. Now this feature is yet undocumented, and we're still doing some polishing on it. But to start the year new and fresh here it is:

https://jsfiddle.net/4hjar1v5/

Let us know if you have suggestions for polishing or if you've found bugs with it.

It only works synchronously with a map creation. And probably weird things are going to happen if it's changed later.
The default value is 40 and setting 40 should be a no-op; and although there is no minimum or maximum capping for it yet, we may not accept bugs for all values :-) for example values around 10 or below are clearly not how useful.

First of all, thanks for this improvment and taking this thread into account, the different sizes apply to all the controls solving what I've mentioned in #28.
One thing to improve is the "rotate view" control on Street View after dropping the Pegman, because it's size is limited by the controlSize option, it should be bigger than the zoom controls to be consistent with Google Maps. I've tested it on the jsfiddle with different values for controlSize and removing the "transform: scale(0.725);" attribute in the element style solves it but requires to adjust properly the alignment with the zoom controls.

Thanks for adding the "controlSize" map option.
There seems to be a bug for the "style: google.maps.MapTypeControlStyle.DROPDOWN_MENU".
The value of controlSize does not affect the size of the dropdown menu.
If you add the following to your example on https://jsfiddle.net/4hjar1v5/ changing the controlSize does not adjust the size of the dropdown menu.
    mapTypeControlOptions:{
      style: google.maps.MapTypeControlStyle.DROPDOWN_MENU,
      mapTypeIds: ['roadmap', 'terrain', 'satellite']
      },

I'm simply chiming in on how this change has negatively impacted our desktop tool, which has a small dedicated space for the map. The map controls now take up a significant portion of the available map space, overlap with centered custom controls, and generally look completely out of place with the rest of the tool.

I had forced an old version (3.33) of Google Maps in order to skirt around the issue temporarily, but now that version is gone.
I'm thankful that there's now an option to affect the control size, despite the fact that it should have been an option as soon as this change was rolled out.

Now I need to go double-check all of our map controls and ensure they're using a reasonable control size, test, submit pull requests, wait for tests to run, and get fixes out soon.

Please avoid adding breaking changes to minor API releases in the future.

I work with #33 above and also saw this breaking change affect usability in our desktop app. I also concur with #26 -- we pay to have a stable component with expected behavior for our application. The new UI, while nice as an option, is completely unacceptable as a default experience for existing API users without an option to use the prior UI in a way that does not involve using old code revisions.

Thanks a lot! The "controlSize" option is indeed very useful. As already mentioned above, in desktop app use cases, and especially when UIs feature tiny elements by design, or when the map takes small part of the screen real estate.

In fact, the feature is a must, so I would like to suggest the following enhancements:

You might consider to introduce constants with some “default” values for controlSize, in order to achieve consistency, for example:
google.maps.MapControlSize.SMALL to equal 24, the “good old” size, and, let’s say
google.maps.MapControlSize.LARGE to equal the new large size (40)

As also previously mentioned, the google.maps.MapTypeControlStyle.DROPDOWN_MENU style should also respect the control size value.

P. S. Another suggestion might be to introduce something similar to the google.maps.InfoWindow, as I’ve noticed that now info windows feature round corners by default. For example, it would be nice to add borderRadius to google.maps.InfoWindowOptions, as for some “edgy” web designs it would be good to have the old (squared) info window. (Perhaps this may be filed as another FR/issue?)

Hi, "controlSize" is nice. Can I change somehow the controls font size too? When I set up controlSize = 32, the font size 18px is a quiet large. The 16px would be nicer.
Thanks for reply.

That's quite useful. It would be great if there were a contolSize for each map control so they could be adjusted independently of each other. Also, if there were a way to change the size of the scale bar (way too small for use).