IssueTracker

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 3d6aa2e9b3243dcc4de1f54bd8d40339bd69cb05
Author: Seigo Nonaka <nona@google.com>
Date:   Wed May 27 17:38:05 2020

    Adjust the Typeface display style with the style of given font
   
    This behavir is implicitly done by Typeface.Builder and
    Typeface.createXXX function but not to be done by
    Typeface.CustomFallbackBuilder since it is designed to be working
    with multiple font files which has different style.
   
    Looks like the style argument is ignored on older API implementation.
   
    Bug: 156853883
    Bug: 152023266
    Test: ResourcesCompatTest#testGetFont_adjustDisplayStyle passes on 29
    Test: ./gradlew core:core:connectedAndroidTest on API 29, 28, 23
    Change-Id: I3a377c339a7aed50973cf11df86ddf0069f4ec25

A       core/core/src/androidTest/assets/fonts/thin_italic.ttf
A       core/core/src/androidTest/assets/fonts/thin_italic.ttx
M       core/core/src/androidTest/java/androidx/core/content/res/ResourcesCompatTest.java
A       core/core/src/androidTest/res/font/thin_italic.ttf
M       core/core/src/main/java/androidx/core/graphics/TypefaceCompatApi29Impl.java

https://android-review.googlesource.com/1318947

I presume that you've put in a fix for the issues with the Bootstrap css, as the button icons are appearing again, but there is still a small issue with the StreetView layout which might be related? (See attached.)

As a reaction to #8. Our UX research has indicated that the new control works well on both touch and non-touch. So even if you know that the input will be mouse only, the interface should work fine. Just to gather sufficient data, is the desire for small controls purely an aesthetic one? Or is there also a functional aspect to it?

As a reaction to #9, we specifically did this targeting laptops, as more and more laptops these days come with touch screens. So if the target of your application is people using laptops/desktops, they could very well be using touch screens and be benefiting from this right? And even if it's less likely to have a touch screen, we see a very clear trend in this growing, especially on non-mobile, so should be the right choice for the future.

So far we don't have plans to support multiple icon layouts, but please use starring as a mechanism here, so we can assess impact and feedback.

As a reaction to #10, yes we noticed the Street View Layout one as well, funnily enough that one has been broken in combination with bootstrap for quite some versions, but we never realized the bootstrap + our css combo. We have a fix for that that will land pretty soon as wel.

Hi #11, my concern isn't that the controls do not work on touch, or non-touch.  My concern is that the controls no longer fit the aesthetic of the page and has turned what looked like a professional product into one that appears rather amateur.  It is certainly an aesthetic problem.  Like #9, our users are research-types who don't want or require large chunky controls on the screen covering too much of the map - they want the most prominent thing on the screen to be the map itself.  As per your response to #9, like them it is quite possible that our users are using touch devices - I don't think that anyone is stating that they definitely will not, but that doesn't change the fact that they, and us, value discreet controls over chunky ones.  It *is* aesthetic, but these aesthetics affect the user experience in cases like ours, #9's and, no doubt, many other people who have not commented or found this thread.  If the user's experience is adversely affected then we have a problem.

All we are asking is the option to determine "controls_touch", or "controls_small", or something like that in future versions.  Nothing too extreme.  Giving your users a choice is important.

I'm 100% in favor of giving touch devices more importance in usability terms, but that wouldn't affect the overall user experience, particularly when we are trying to provide more importance to the map itself than the controls. We made our web app to use and show the most available space of the map since we display other layers on top of it, we liked the small controls for an elegant and sleek visualization, dislike the new huge ones.
I get that's merely aesthetics as the other comments say, but it is important for our users. At least give us the option to switch over touch or small controls in a future version, forcing the use v3.33 knowing it will be deprecated it's more like a temporary patch than a real solution.

At the moment we are committed to this UX, as we think this will benefit most users. However we do understand that people have different use cases and people have different UX on their page they'd like to match. However since there already is an option to pursue custom controls it is currently not on our planning to pursue this path. But again, please star the different bugs, so we get a good signal of what is important to our users.

To demonstate how smaller controls can be achieved again on 3.34 we have prepared the following sample:
https://jsfiddle.net/q40abnmL/

Here the controls are fully customizable in CSS, and developers can change them to match closer what they want to achieve with a map on their webpage. Feel free to copy-past this code or just inspect.

Hello #14, thank you for a demonstration of an alternative solution for recent API version. I'm affraid we'll need to implement UI this way to maintain usability in our use-case. Oh well, at least there is a way.

I can understand your reasoning behind this UI change, but just out of curiosity: Have you been considering switching to this new large layout ONLY on the touch-enabled devices (via dynamic touch detection, like Modernizr do)? If not, what was the top reason for not doing it this way?
Thanks in advance.

As a bit of a CSS workaround, this seems to mostly work for me:

        .gm-style-mtc div{
            direction: ltr !important;
            overflow: hidden !important;
            text-align: center !important;
            position: relative !important;
            color: rgb(86, 86, 86) !important;
            font-family: Roboto, Arial, sans-serif !important;
            user-select: none !important;
            font-size: 11px !important;
            background-color: rgb(255, 255, 255) !important;
            padding: 8px !important;
            border-bottom-left-radius: 2px !important;
            border-top-left-radius: 2px !important;
            background-clip: padding-box !important;
            box-shadow: rgba(0, 0, 0, 0.3) 0px 1px 4px -1px !important;
            min-width: initial!important;
            height:auto!important;
        }

The only problem is that the "Terrain" option on the roadmap, and the "Labels" option on the satellite map aren't quite right.  That's because the DIVs that hold these options are nested.  I am no CSS expert, but I believe that they may be accessed by using something like .gm-style-mtc div:nth-child(x) (or something!) to style them in the way that we're trying to achieve (that of the v.3.33 CSS).  Is anyone here good enough in CSS to get to those "Terrain" and "Labels" DIVs / checkboxes and style them properly and post the code here using the above as a starting point?  The above CSS works for the standard buttons and seems far simpler than the solution provided by #14.

#14 Yes we have considered having a different touch and a different non-touch UX. But there are multiple reasons why we decided not to go down this path.
First: We are seeing an increasing amount of hybrid devices entering the market. This upwards trend has been going on for some years now. By Hybrid devices I mean laptops which have both a touchpad/mouse and have a touch screen. These devices simply don't fall into the binary categorization. Some owner of devices like this are not even aware they can touch the screen. Some owners really love the touch over the touchpad. And everybody in between. We believe this UX works well in all scenarios. The new UX reflects the device mixture on the internet of this day and age.

Second, but less important. Detection is very tricky. Many browsers report they support touch, even if no touch-hardware is directly connected. But Linux/Windows for example, report this when it supports touch hardware. This means that someone could connect a touch monitor to it, but it doesn't report whether it has.
We could present a non-touch UI and switch over to a touch-UI when we see the first touch event. But that means swapping the UI halfway the life time of a map. And quite possibly even too late. The first touch click should work as well.

Finally we honestly believe the Maps API is configurable enough for developers to remove controls and add controls that really suite  their particular use case, and we're always eager to help. Our prepared example is meant as a demonstration of that.

A solution like presented in #16 has some risks, as it uses a non-supported part of the API. The dom structure of the API could change and the CSS may no longer work. If one would pursue a solution like this, we would recommend pinning your application to quarterly, and before ever roll over inspect weekly to detect any changes.

#14 Please do some more testing / apply some more thought before you post something like this as an "official solution" from a googler. This "solution" is completely littered with bugs.

On Chrome: when you click + or - it leaves a very thick blue box shadow artifact that bleeds through to the other zoom.
On Safari: The css white boxes do not fit so the edges aren't clean. When you click the zoom controls boxes also shifts left 1px and then back.
On Firefox: Again your css white boxes do not fit.

This is only testing 3 browsers on my macbook, I'm sure you have a lot more to account for on Windows and mobile.
Please do better.

It seems like rewriting the controls for smaller buttons, which has been the default size since forever, is overkill. I still feel the size of the buttons should be configurable with a flag/option. Why should I do the extra work just to get it to behave like previous versions?