Google Maps just fucking SUCKS now

[jakeroot]

I'll wait for Winkler to chime in and confirm that Chrome or Edge have the same issue (if that's the case), but until then, I'm still baffled.

The issue is present but less pronounced in Internet Explorer version 11.0 with zoom returned to the neutral level:

Your problem is using Internet Explorer.

Well, he can't use Edge because he only has Windows 7. Agreed that IE is not optimal for GMaps browsing, although it appears to be superior to Firefox for this purpose.

Maybe it's a Windows 7 thing.

Mr Winkler, can you try Chrome to be sure it doesn't have the issue as well? Or do you not like that browser?

[MNHighwayMan]

Your problem is using Internet Explorer.

Well, he can't use Edge because he only has Windows 7. Agreed that IE is not optimal for GMaps browsing, although it appears to be superior to Firefox for this purpose.

Besides that, I guess I just don't understand what the problem is. Of course it's going to look different if you're viewing the route in the Mercator projection vs a globe.

[jakeroot]

Your problem is using Internet Explorer.

Well, he can't use Edge because he only has Windows 7. Agreed that IE is not optimal for GMaps browsing, although it appears to be superior to Firefox for this purpose.

Besides that, I guess I just don't understand what the problem is. Of course it's going to look different if you're viewing the route in the Mercator projection vs a globe.

If you look at the gif's and video on the last page, the way globe mode renders on my computer is radically different than the way it renders on J N Winkler's computer, despite us using the same resolution monitor. It isn't really a Mercator vs sphere issue. It's a "why does globe mode look like shit on my PC but not on someone else's" issue.

[hotdogPi]

Looks good on Safari.

[J N Winkler]

Maybe it's a Windows 7 thing.

Mr Winkler, can you try Chrome to be sure it doesn't have the issue as well? Or do you not like that browser?

I went ahead and installed the current version of Chrome (64-bit for Windows 10/8.x/7):

Your problem is using Internet Explorer.

The same issue is present to varying degrees in Firefox, IE, and Chrome.  And BTW, I don't use IE by choice.  Before I fired it up this morning for the specific purpose of checking globe view rendering, I had last loaded it about four months ago when I was trying to see if I could get the Java applet for "classic view" on MnDOT's EDMS to work.  (The search interface MnDOT now promotes, eDIGS, is much more robust, but the metadata it shows and uses in keyword search is much more limited, and does not include work type for construction projects.)

Besides that, I guess I just don't understand what the problem is. Of course it's going to look different if you're viewing the route in the Mercator projection vs a globe.

On my PC there is more wasted screen area and more distortion in the route displayed in globe view on initial load.

If you look at the gif's and video on the last page, the way globe mode renders on my computer is radically different than the way it renders on J N Winkler's computer, despite us using the same resolution monitor. It isn't really a Mercator vs sphere issue. It's a "why does globe mode look like shit on my PC but not on someone else's" issue.

Exactly.

[jakeroot]

Maybe it's a Windows 7 thing.

Mr Winkler, can you try Chrome to be sure it doesn't have the issue as well? Or do you not like that browser?

I went ahead and installed the current version of Chrome (64-bit for Windows 10/8.x/7):

Well, as with IE, it's better than Firefox, but still not optimal. Still confused as to why it wouldn't zoom in more. The route is definitely centered between the right edge of the navigation panel and the screen edge (unlike what Firefox was doing), but it's still zoomed way too far out.

[Michael]

Since I'm using an old computer with Windows XP, I can't use 3D mode.  I used it within the past week or two on a friend's Windows 7 laptop, and "diving" into Street View looked cool, but I don't think it has any more value than just being eye candy.  One issue I've had is with Street View in Firefox or in Chrome with a spoofed Firefox useragent.  In these cases, there is a "space warp" effect on the image.



Last night, I was tracking an Amtrak train on my friend's (same one as above) Note 8.  It was annoying that I had to use two fingers to pan the map.  It shows the message "use two fingers to move the map", similar to the message about using [CTRL] and the mouse wheel to zoom.  As soon as I saw it, I thought "Oh great, the mobile version of 'use ctrl + scroll to zoom the map'".  I was going to say I don't have any idea why they did this, but I just realized that there could be a fullscreen map on a webpage, and you can't use a scrollbar like on a computer.  As I'm typing this, I'm wondering if this is more of the "mobile first" approach that companies and websites seem to be taking.  It's like they're forgetting that computers exist, and I'm not a fan of it, but that's a whole different topic.

[vdeane]

It's like they're forgetting that computers exist, and I'm not a fan of it, but that's a whole different topic.

Definitely.  I hate it.  It's understandable that they don't want mobile users accidentally panning the map when they wanted to scroll the page, but why inconvenience desktop users because of it?  They could have easily implemented this on mobile but left the desktop behavior the same.

There's allegedly an API setting that will disable it, but I've never seen it used.

[20160805]

Screw the "mobile first" approach - I've been a loyal user of desktop computers my whole life, and there's no reason to change when computers are still everywhere in offices, libraries, and schools, among other places; and when computers are so much easier to see on, use, and work with than clunky mobile devices anyway.  Besides, on a computer you get vastly more hard drive space (this one has 571 GB total, and even after years of using it it's still more than 80% free), and it's much easier to use a keyboard with actual keys than to try to manoeuvre your fat fingers around tiny little spaces on a screen.

[jon daly]

^Preach it!

[freebrickproductions]

I suppose the whole "mobile first" approach is due to more and more traffic being on mobile devices, which is probably soon to pass the traffic from computers for most major websites (Google, Facebook, YouTube, Twitter, Tumblr, etc.) if it hasn't already. Can't say I approve of it though.

[hotdogPi]

I suppose the whole "mobile first" approach is due to more and more traffic being on mobile devices, which is probably soon to pass the traffic from computers for most major websites (Google, Facebook, YouTube, Twitter, Tumblr, etc.) if it hasn't already. Can't say I approve of it though.

It's already easy to make separate mobile and desktop versions of pages, though.

[freebrickproductions]

I suppose the whole "mobile first" approach is due to more and more traffic being on mobile devices, which is probably soon to pass the traffic from computers for most major websites (Google, Facebook, YouTube, Twitter, Tumblr, etc.) if it hasn't already. Can't say I approve of it though.

It's already easy to make separate mobile and desktop versions of pages, though.

"B-but making a page that works on both devices is so much cooler though!!1!"

[jakeroot]

Mobile web browsers have very quickly caught up to desktop web browsers. It was really common back in the day for websites to have desktop and mobile versions, but that's not as necessary as it once was due to larger displays and similar browser technology. Plus, the code behind websites is being written for both uses in mind, unlike ten years ago when desktop use was the only thing considered. The one thing holding mobile browsers back was Flash, and that's nearly dead (and will be by 2020). The Maps API being discussed here is an example of an API that was developed for both environments. It's not "great" in either environment, but anything else might severely compromise one environment, while benefiting the other.

[vdeane]

It's possible to make designs optimal for both versions without making something completely separate, though.  Take my website, for example.  I don't have a completely separate mobile site, but I do have code that detects mobile devices and downloads a separate stylesheet for them that changes things like text and photo size to make the mobile experience more optimal.  Couldn't Google do something similar with the API?  Granted, my site is actually XHTML 1.1 rather than HTML 5, but I'm sure there's something that could make it work.

[jakeroot]

It's possible to make designs optimal for both versions without making something completely separate, though.  Take my website, for example.  I don't have a completely separate mobile site, but I do have code that detects mobile devices and downloads a separate stylesheet for them that changes things like text and photo size to make the mobile experience more optimal.  Couldn't Google do something similar with the API?  Granted, my site is actually XHTML 1.1 rather than HTML 5, but I'm sure there's something that could make it work.

Certainly it's possible. But I'm sure if you asked Google, they would be more interested in moving towards a single stylesheet that works for all devices (with the only real differences at this point being screen size and input method). I am personally annoyed by websites that optimize for my mobile browser, since my screen and processing power is optimal for browsing normal websites.

[D-Dey65]

it doesn't suck anymore, this topic is unneeded

Nah, there are still too many errors. I just told them about their exaggerated length of the US 15/501 overlap, and though I only mentioned it in Santee, SC, I did point out that the error covers the whole highway. 

It seems someone has changed the entirety of US 15 to be labeled as "US Hwy 15/501" . In central NC, that is correct. But in Pennsylvania, it is not. It seems that edit took out all the 15 shields with it too.

They could always replace the label with "US Hwy 15/401" from Society Hill, SC to Laurinburg, NC, and "US Hwy 15/301" from Exit 97 on I-95 to Summerton. Now that I think about it, I should've told them the exact details of where the 301, 401 and 501 overlaps begin and end.

[jakeroot]

it doesn't suck anymore, this topic is unneeded

Nah, there are still too many errors. I just told them about their exaggerated length of the US 15/501 overlap, and though I only mentioned it in Santee, SC, I did point out that the error covers the whole highway. 

Those issues are unrelated to the topic of this thread. This thread is about issues with Google Maps' interface and usability, not route accuracy. Google Maps had these same route "inaccuracy" issues before it was redesigned a few years ago.

[hbelkins]

it doesn't suck anymore, this topic is unneeded

Nah, there are still too many errors. I just told them about their exaggerated length of the US 15/501 overlap, and though I only mentioned it in Santee, SC, I did point out that the error covers the whole highway. 

Those issues are unrelated to the topic of this thread. This thread is about issues with Google Maps' interface and usability, not route accuracy. Google Maps had these same route "inaccuracy" issues before it was redesigned a few years ago.

To me, usability is directly related to accuracy.

[jakeroot]

it doesn't suck anymore, this topic is unneeded

Nah, there are still too many errors. I just told them about their exaggerated length of the US 15/501 overlap, and though I only mentioned it in Santee, SC, I did point out that the error covers the whole highway. 

Those issues are unrelated to the topic of this thread. This thread is about issues with Google Maps' interface and usability, not route accuracy. Google Maps had these same route "inaccuracy" issues before it was redesigned a few years ago.

To me, usability is directly related to accuracy.

That's fine, but for the purposes of this thread, they are two distinct things. You can't locate map inaccuracies if you can't use Google Maps.

[doorknob60]

It's like they're forgetting that computers exist, and I'm not a fan of it, but that's a whole different topic.

Definitely.  I hate it.  It's understandable that they don't want mobile users accidentally panning the map when they wanted to scroll the page, but why inconvenience desktop users because of it?  They could have easily implemented this on mobile but left the desktop behavior the same.

There's allegedly an API setting that will disable it, but I've never seen it used.

T-Mobile's MVNO map allows you to zoom with the wheel without CTRL, but their postpaid map requires you to use CTRL. They both are Google Maps based, so clearly the setting exists.

[jakeroot]

It's like they're forgetting that computers exist, and I'm not a fan of it, but that's a whole different topic.

Definitely.  I hate it.  It's understandable that they don't want mobile users accidentally panning the map when they wanted to scroll the page, but why inconvenience desktop users because of it?  They could have easily implemented this on mobile but left the desktop behavior the same.

There's allegedly an API setting that will disable it, but I've never seen it used.

T-Mobile's MVNO map allows you to zoom with the wheel without CTRL, but their postpaid map requires you to use CTRL. They both are Google Maps based, so clearly the setting exists.

Both implementations on a mobile browser require users to use +/- buttons in the bottom right. Which is weird, since the pre-paid map should be coded correctly to allow pinch-to-zoom with touchscreen devices.

I don't mind using +/- buttons, but it's not as straight-forward as pinching. Plus, given the way Google Maps normally works on a phone, it's reasonable to think that website implementations would have similar controls. At least from a typical user's perspective. I'm sure if you showed the two above maps to people on the street, their first instinct would be to pinch to zoom, not use the buttons.

FWIW, I don't mind holding control to zoom.

[Michael]

I just was looking at the old ClassyGMap, and the new API and color style has made it there sometime within the past 24 hours.  It's an old link to before the KMLMap rebranding, and I assume that it isn't updated anymore, so the change is probably on Google's end.  I can't use the scroll wheel to zoom with or without [CTRL] (or in my case, it was [ALT]), and the buttons are larger than they used to be and are missing labels.  The map/satellite buttons are labeled, but they're large too.  After zooming in enough in an area with 45 degree imagery, the tilt and rotate buttons are labeled, but they're large like all the other buttons.  It also appears that I can only have 8 points in a route (10 including the endpoints).  I used to be able to have 11 points (yes, one more than the limit of 10 for some reason) in addition to the two endpoints.

Lastly, I can drag Pegman to the map, but Street View won't open.  I tried several different useragents, but none of them worked.

[Rothman]

Google Maps still sucks due to no county lines, a woefully small number of destinations/via points and no visual indication of toll roads versus free roads.

I miss the old Rand McNally atlases where they would show you free and tolled portions of highways (Garden State's multicoloring comes to mind).

[skluth]

Your problem is using Internet Explorer.

Well, he can't use Edge because he only has Windows 7. Agreed that IE is not optimal for GMaps browsing, although it appears to be superior to Firefox for this purpose.

Besides that, I guess I just don't understand what the problem is. Of course it's going to look different if you're viewing the route in the Mercator projection vs a globe.

Google Maps does not use Mercator. It uses something called Web Mercator which doesn't exaggerate as much near the poles. This was a serious problem where I used to work (I recently retired from NGA.) as many new employees didn't know there was a difference and would reproject incorrectly.