WebViewer scrolling in FM Go either dodgy or nonintuitive, my users think it's broken

Discussion created by kupietz on Aug 1, 2017
Latest reply on Aug 4, 2017 by TSGal

Most of the time in touch UI design, if a person swipes on an object, the smallest scrollable object under their finger will scroll. Therefore, any object in the window (or the window itself) can be scrolled with one gesture.


Can you imagine if, in working on your desktop, you had to first actively click to select a list view or window every time you wanted to scroll it with your mouse wheel instead of just hovering over it, otherwise your entire screen would try to move instead? It would get annoying quickly. It's not a productive UI behavior.


This seems, either by accident or design, to be broken in FM Go's web viewers. If I present scrollable content in a web viewer, the user tries to scroll it by swiping, but instead the entire layout bounces in place, and I get a bug report. I keep having to explain to people that you must first tap the inner scrollable content, then it will scroll as expected without trying to move the entire visual layout (which isn't meant to move at all and never should... in fact, consider that part of this complaint. Making an entire nonscrollable layout move when you drag on it adds nothing useful, and is annoying when it's not what the user intended to do.)


As non-technical users who don't know what a "web viewer" is, they don't understand why this is. Nothing else in their online/computer experience behaves this way. Please consider fixing this. The smallest moveable thing what they're touching should move, not the largest, unless the smaller one has reached the far limit of its scroll in that direction, in keeping with the behavior that happens pretty much everywhere else in the world where you ever might try to scroll something on a screen.



EDIT: Forgot to mention: latest versions of FM16 and FM Go 16, iOS 10.3.2