Improve native info window CSS

[DevinWalker]

The style of the native Google info windows needs to look sharp and look consistent

Problem 1: When you view a marker's info window that contains a lot of content or a thumbnail it does not look good. There is too much of a margin on the right and when a scrollbar appears it does not look nice:

Problem 2: Info windows with a lot of content displays outside the bounds of the marker window:

Problem 3: When you click through a number of markers a flash of the previous marker content is noticeable. This appears to only happen when Google Places data is displayed within the info window. There should be a loading gif displayed when content is loading in the info window:

Check out this tutorial: http://en.marnoto.com/2014/09/5-formas-de-personalizar-infowindow.html

• I especially like how he added a gradient fade at the bottom

[DevinWalker]

@lchski let me know what you think about this issue and if you can take it on. I know you commented on https://github.com/WordImpress/Google-Maps-Builder/issues/166 with some hesitations about styling the native info window.

[lchski]

That link you provide offers some good tips/methods for styling the native window, which I can implement. The same reservations remain—that this’ll be a fragile change requiring a specific markup structure and styles coming from the API—but if you’re okay with that I can go ahead.

I’m not sure about the loading-outside-bounds problem—that may have to do with their sizing algorithm, in which case there’s not much we can do. I can play with it, though.

As for the previous marker content being visible, I reckon that’s an easy enough fix.

[DevinWalker]

The same reservations remain—that this’ll be a fragile change requiring a specific markup structure and styles coming from the API—but if you’re okay with that I can go ahead.

@lchski I'm ok with it because it will be an improvement to the native styling

I’m not sure about the loading-outside-bounds problem—that may have to do with their sizing algorithm, in which case there’s not much we can do. I can play with it, though.

See what you can do with it. In our previous versions we displayed a loading animation then the content was displayed once loaded. It would be nice to achieve that same functionality.

As for the previous marker content being visible, I reckon that’s an easy enough fix.

Great!

[lchski]

Just to make this a bit easier for me to keep track of what’s done and what’s not, here’s a checklist of what (in my mind) needs to be done, as well as the commit(s) that fixed the issues, where applicable:

• [ ] Rework info window styles with less margin and better handling of the scrollbar
• [ ] Investigate the loading-outside-bounds problem, seeing if a loading spinner addresses it
• [x] Hide previous marker content by always replacing it with a loading spinner upon opening the marker (https://github.com/WordImpress/maps-builder-core/commit/c2f339823eb4ef2193b101f7c59002b6965d4d0e)

[lchski]

It looks like the loading spinner (which I’ve ensured is added to the bubble) doesn’t fix the loading-outside-bounds problem. I’m pretty sure it has to do with the Google Maps InfoWindow content-sizing algorithm, which is not within our control 😕 Going to go ahead with trying to rework the styles, though.

[DevinWalker]

@lchski can we use some simple CSS overflow:hidden?

[DevinWalker]

This is an interesting fiddle where they wrap the infowindow bubble http://jsfiddle.net/veaz/7Zm8w/

[lchski]

@DevinWalker we currently do the same wrapped infowindow technique—wrapping it with .gmb-infobubble. It doesn’t help us with styles, unfortunately, because Google creates the width/padding of the window via absolute positioning and widths. That earlier link does give good methods for styling, though!

As for overflow: hidden, I don’t think we can use it to fix the problem, because it prevents scrolling. I tried it on a few of the different divs generated by Google Maps, to see if there was one where we could prevent the flash of content but maintain the scrolling, and I couldn’t find the right fit after a few combinations. Interestingly, though, the flash of content seems to only happen intermittently; it’s rather an odd situation.

[DevinWalker]

Is there any middle ground where we can achieve a nice looking info window?

[lchski]

I’m going to implement the options offered in that first tutorial you posted, which should get us some of the way there. I’ll have that done today, and then we’ll take a look to see where we’re at.

[DevinWalker]

Sounds good to me, thanks

On Mon, Aug 8, 2016 at 12:53 PM, Lucas Cherkewski notifications@github.com wrote:

I’m going to implement the options offered in that first tutorial you posted, which should get us some of the way there. I’ll have that done today, and then we’ll take a look to see where we’re at.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/WordImpress/Google-Maps-Builder/issues/214#issuecomment-238355662, or mute the thread https://github.com/notifications/unsubscribe-auth/ABf7M0aX7a21hF1aGpflCuHBjfv3RvB_ks5qd4kfgaJpZM4JcEMS .

Devin Walker

Founder & Lead Developer

P:

858-449-6460 <8584496460>

W:

http://wordimpress.com

433 G Street #201 San Diego, CA 92101 https://goo.gl/maps/BePgp https://www.facebook.com/wordimpressive https://twitter.com/wordimpress https://plus.google.com/u/0/b/117062083910623146392/+Wordimpress/about http://wordimpress.com/

[lchski]

I’ve put some work in on the maps-builder-core/214-info-window-improvements branch that takes somewhat after the styles adopted in that tutorial. Currently Google Places results are broken (though I can think of a possible fix for that, by trying to scope more closely to our custom .gmb-infobubble selector), and results that otherwise wouldn’t expand to 350px width (because of not having enough content) are forced to do so anyways. I thought I’d put this out there to get a feeler before trying to deal with the edge cases. Let me know what you think!

[DevinWalker]

I just did some extensive testing and customizing and have noticed several issues and warning signs that going down this road could be more difficult than we anticipate. There doesn't appear a really cut and dry way to get this working like we like (now I remember why I switched to that Info Bubble library in frustration).

[mathetos]

What's the alternative? We're not happy with the infoBubbles JS, and native doesn't provide us with the flexibility we need. What's the solution then?

[DevinWalker]

Good question. I spent a lot of time on it today and feel that the best route forward is to figure out how to wrangle the native info window. It's not easy but can be done.

[lchski]

Doing some more digging and thinking this morning, I’m pretty sure that the native InfoWindow is more trouble than it’s worth. It comes with too much baggage. We, then, have two or three options as I see it:

• Go back to InfoBubble and fix its sizing algorithm (I already have code for this), even though it may have problems down the line
• Move to the InfoBox library, which is similar to InfoBubble but seems to have a focus on greater customization (https://github.com/nmccready/google-maps-utility-library-v3-infobox and http://michaelsoriano.com/customize-google-map-info-windows-infobox/, via @mathetos)
• Develop our own marker library, similar to what InfoBubble and InfoBox accomplish, but suited to our needs (essentially, we implement a Custom Overlay, which is what the other libraries do; some links on this: https://codepen.io/emgerold/pen/kjivC?editors=0110#0, http://artandlogic.com/2014/02/custom-google-maps-info-windows/)

I’m leaning towards either the second or third option. I haven’t been able to get InfoBox’s demos running yet, but I’ll make a small demo of my own to see how it fits our needs.

As a note here, the goal of this (as I discussed with Matt last night) is to come up with a new solution that provides at least as good a visual appearance and functional experience as our existing InfoBubbles, while also providing us with as much control as possible for styling via CSS and, if necessary, JS.

[DevinWalker]

Nice research @lchski - I appreciate that. I agree that using the native info windows won't be the best route going forward. I took a look at option 2 and the utility library fork on Github. It doesn't appear to be very well documented or supported. Which leads me to number 3, which appears to be the best route to go. It should provide us the flexibility we need to size and style the info windows, which is the biggest pain point right now.

[mathetos]

If we go with option 3, then I'd almost prefer we break it out to it's own public Repo that others could leverage as well. Since we're solving a problem other most likely could benefit from. Could bring some nice attention to our plugin as well.

[DevinWalker]

Let's just get it done and then we can figure out how we can provide it back to the community.

[lchski]

I’ve investigated the InfoBox plugin (option 2) and it works much nicer than either InfoBubble/native did. That said, going option 3 would allow us to adopt the best code/features from InfoBox and InfoBubble to get to a place that we like. Going to focus on getting rough parity with our existing InfoBubble implementation via a custom implementation and then we’ll evaluate. As for breaking it out, it’ll be easy enough todo once we have it done—it’s a self-encapsulated function.

[lchski]

I’m working on the custom implementation in WordImpress/maps-builder-core/214-custom-iw-library. A basic working version is there now. Here’s my rough task list for what still needs doing:

• [x] CSS
  • [x] Scroll overflowed window content
  • [x] Close button (ensure always visible, possibly by overflowing .gmb-infobubble__content instead of .gmb-infobubble; make it look better)
  • [x] Arrow style
• [ ] JS
  • [x] Place window correctly relative to marker—accounting also for possible differences in marker heights (currently it doesn’t always place in the right spot)
  • [x] Enable scroll events on window
  • [x] Add arrow markup
  • [x] Update calls to window API in frontend scripts
  • [ ] Update calls to window API in admin scripts
  • [x] Update mashups to use new window
  • [ ] Account for how Places results create markers differently (can’t count on anchorPoint in the same way)
  • [x] Create panToView function
  • [ ] Consider whether we need a sizer function
• [ ] PHP
  • [x] Review generated window content: .gmb-infobubble shouldn’t be manually included
  • [ ] Enqueue custom window JS plugin where necessary
• [ ] Testing
  • [ ] Test each of the demos on the demo site using the new scripts and styles

[DevinWalker]

Thorough task list, thanks I'm looking forward to checking it out!

[lchski]

Update on this: we are in a much better place. Here’s where things are at:

• The window is styled: styling is more flexible now, and we have total control over markup structure
• The window is working, more or less, for each of the places it appears (normal markers, mashups, and Places results)

Unfortunately, there are some places where things should “just work” that are giving me some grief:

• Window positioning with mashup and Place results
• The flash of the old window content is still happening on occasion

It’s come a long way, but isn’t quite ready yet. I’m going to dig into the InfoBubble/Box plugins again to learn where they might tackle some of these situations differently, and see if it could help us here. I’m now working in both core and pro branches.

[DevinWalker]

Thanks for the update. When you say flash of the "old" window content - does that mean you see the native info window appear briefly and then it's replaced with our new one? How's that happening if we're removing the use of the native info windows entirely? #confused :)

[lchski]

@DevinWalker, it’s just Problem 3 noted at the very beginning of this thread, where quickly clicking through markers causes a bit of a lag in the content editing (notably with Places results). A loading GIF doesn’t seem to have placated it, though there are some other avenues I can think of pursuing to address it.