UI color choices on Call to Action button is poor

[+rragan]

Several places on the site now use a dark blue button with black text. This combo is hard to read. Consider choices based on Ui color combos that are easy to read. 

[+Max and 99]

I've reported the visibility issue on the forum site before. Not exactly the same as what you reported but similar. I find it very difficult to see this text. 

 

[+MNTA]

50 minutes ago, rragan said:

Several places on the site now use a dark blue button with black text. This combo is hard to read. Consider choices based on Ui color combos that are easy to read. 

 

I agree also the grey on grey for the site at the top of this page.

 

[+niraD]

4 minutes ago, Max and 99 said:

I find it very difficult to see this text. 

What text? 

[+kunarion]

Here's the official announcement about color themes:

 

[+humboldt flier]

Agreee with O.P.  

 

         It is rather rough on we who have "old eyes".  Just saying.

[+niraD]

14 minutes ago, humboldt flier said:

Agreee with O.P.  

 

         It is rather rough on we who have "old eyes".  Just saying.

Even without "old eyes" it can be pretty rough, depending on the display environment (not to mention genetic factors like colorblindness).

[+Viajero Perdido]

Also, some customers use browser settings (eg in Firefox) to force a chosen font and minimum size for all websites.

 

Some websites fight this by specifying their own fonts, without which the site is untested and turns out unreadable.  This is accessibility-hostile, because the browser settings win.

 

I have sharp vision (with glasses), and even I'm complaining.

 

PS, I haven't seen a "Call to Action" button anywhere, but of the places I do visit on geocaching.com, things work fine with my own choice of fonts.

 

Edited March 2, 2022 by Viajero Perdido

[+niraD]

41 minutes ago, Viajero Perdido said:

Some websites fight this by specifying their own fonts, without which the site is untested and turns out unreadable.  This is accessibility-hostile, because the browser settings win.

CSS image sprites create similar problems. Some users need to enforce their color preferences, which includes the background color, disabling any background images. CSS image sprites vanish when background images are disabled. When CSS image sprites provide critical content, that content is inaccessible to such users.

[+mustakorppi]

4 hours ago, rragan said:

Several places on the site now use a dark blue button with black text

Ok I give up. Where?

 

 

[+kunarion]

42 minutes ago, mustakorppi said:

Ok I give up. Where?

 

 

I also get Blue Button With Black Text in several places.  This case was when using the Alook browser on my iPhone 8.  I do not make a point to document such things anymore, because it’s a lot of work for me, yet makes no difference.  So this is just an example.  I didn’t test it in other systems or browsers, because it’s too frustrating.  Seeing the hideous color/contrast choices just make me angry.  You wouldn’t like me when I’m angry.

 

[+barefootjeff]

4 minutes ago, kunarion said:

also get Blue Button With Black Text in several places.  This case was when using the Alook browser on my iPhone 8.

 

On Firefox running on Windows 10, I'm seeing that Search button on the View Geocache Log screen as a light grey background with black text. All the other colours are the same as in your screenshot. Weird.

[+humboldt flier]

However, I will give them brownie points for going retro with the GC#.   For a "few" years that faded gray on dusty white was TERRIBLE.  

 

THANKS FOR THE RETRO.

[+kunarion]

52 minutes ago, barefootjeff said:

 

On Firefox running on Windows 10, I'm seeing that Search button on the View Geocache Log screen as a light grey background with black text. All the other colours are the same as in your screenshot. Weird.

It also happens at the least convenient time.  Like, outdoors, wordy log that I decided to type for some reason, iffy data connection, Blue Button With Black Text.  And I think the black text says “Submit”, to post the log… but it’s a funky button, almost entirely unreadable.  I’ll cross my fingers and try it anyway.

 

I thought it was a phone/browser thing, but I never see that style of button on other sites.

[+ChriBli]

14 minutes ago, kunarion said:

I thought it was a phone/browser thing, but I never see that style of button on other sites.

I also have the nice, rectangular, light gray button with black text:

 

So clearly this is at least in part a phone/browser thing. Not being a mobile user myself, I still don't understand why anyone would access the site via browser on a phone. Wouldn't one use the app?

[+kunarion]

10 minutes ago, ChriBli said:

I also have the nice, rectangular, light gray button with black text:

 

So clearly this is at least in part a phone/browser thing. Not being a mobile user myself, I still don't understand why anyone would access the site via browser on a phone. Wouldn't one use the app?

The reason for terrible button colors is to “encourage” me to use an App?  

I can believe it.

[+mustakorppi]

55 minutes ago, ChriBli said:

So clearly this is at least in part a phone/browser thing. Not being a mobile user myself, I still don't understand why anyone would access the site via browser on a phone. Wouldn't one use the app?

Well you can't edit a log with the (official) app. Or post a log for different date than the current one. Or paste full coordinates into solved coordinates. Or enter solved coordinates for a letterbox/Wherigo at all. Or use the geocaching.com checker...

 

 

 

But yeah. I see the blue button on a log screen on my iPhone or my ipad (both iOS 15.3.1). The "Submit log entry button" on the Edit log screen is also affected. Maybe every button that has the old school grey color when viewed on a computer?

Edited March 2, 2022 by mustakorppi

[+ChriBli]

39 minutes ago, mustakorppi said:

Well you can't edit a log with the (official) app. Or post a log for different date than the current one. Or paste full coordinates into solved coordinates. Or enter solved coordinates for a letterbox/Wherigo at all. Or use the geocaching.com checker...

Wow. I was not aware of all these limitations. Not that I would ever consider trying to edit logs or solve puzzles on the cracked-screen iPhone 4 that I actually own. Navigating to a geocache in emergency situations when I couldn't load the coordinates into my GPSr in advance at least works reasonably well.

[+kunarion]

1 hour ago, mustakorppi said:

But yeah. I see the blue button on a log screen on my iPhone or my ipad (both iOS 15.3.1). The "Submit log entry button" on the Edit log screen is also affected. Maybe every button that has the old school grey color when viewed on a computer?

The blue button was a surprise to me.  I first saw it maybe a couple months ago?  Yeah, maybe only on the web site and only on IOS.  It’s also elusive… it’s not on every entry screen.  Anyway, not a big deal, but an example of odd colors.  I doubt it’s a default Apple button.  But where that color scheme comes from, I can’t say.

[+Max and 99]

I get that they want the attribute to show up better WHEN it is selected, but gosh why do they have to be so pale and hard to see until selected?

 

 

 

[+kunarion]

On 3/2/2022 at 5:00 PM, ChriBli said:

I also have the nice, rectangular, light gray button with black text:

So clearly this is at least in part a phone/browser thing. Not being a mobile user myself, I still don't understand why anyone would access the site via browser on a phone. Wouldn't one use the app?

 

I'm not sure about everywhere the Blue/Black Button appears, or when.  I haven't tried an Android phone lately, and I think I've only seen the strange color buttons in at least a browser on the iPhone 8, not sure why it's only on geocaching.com.  Sometimes I get backed into a corner with The App, especially when I really hoped it was gonna work.  One situation is when making a log and expecting to drop a TB.  I was 110% sure I could do that in The Official App, yet there's no selection for TBs.  Maybe my App is broken.  But the point where I actually need a function that the App must do, that's the worst time to start troubleshooting a broken App. 

 

So anyway, I switch to a web App, and after carefully typing all the info and selecting all the proper drop-downs on a teeny phone screen (and pinch-zooming without closing the page), I'm presented with a dark blue oval with a word inside it.  I guess the word is "Submit", cross my fingers and click it.  I must at least attempt to submit the log live in the field, regardless of how awful the interface is.  Then I make a mental note to cease using "Apps" and "Phones" for Geocaching.  If it's unusable, I might stop using it.  Because it's a good idea to stop using it.  You know, rather than protest the poor color choices deliberately programmed into things.  I've asked til I was blue in the nose, yet the poor color schemes remain.

 

My usual plan is to resign to log everything on the PC at home (which may result in days of delay for any given log).  Phone Apps, and The Official App in particular, are terrible for Geocaching.  Very frustrating in surprising ways.  Don't get me started on navigation to a cache using an iPhone.  Standout weird unreadable buttons are enough for me.

 

Edited March 4, 2022 by kunarion

[+thebruce0]

One factor to bad colour selection may be that different browsers render basic UI elements (like form buttons) differently - in a way the browser developers have decided is best and most flexible for their application and user experience.  But with some CSS, it's possible to override default visual styles.  So "creative" developers may think "let's make some elements look a bit more like my visual style for my website" -- not realizing that not every browser will let the web developer alter standard UI elements.

 

So a standard button that's great with black text in one browser, may be blue with white text on another, and different on another.

Webdev comes along and wants buttons to be dark green with yellow text (ugh, but for the sake of argument)...

The first browser lets you change text colour but not button colour -> yellow text on grey. 

Second browser lets you change background colour but not text -> white text on dark green (may be acceptable).

Users of the first browser get a bad experience, but not users of the second browser.

 

Webdev can't test every browser to see how their overriding of default browser content affects its users.

 

Webdev has two options.

1. Create a custom styled UI element instead of letting browsers use a standard object and decide what is best for their users visually. That gives them more visual consistency across the entire demographic, but limits users' ability to adjust accessibility and customizability.

2. Use standard elements whenever it makes sense. That adds of ease of development and better accessibility experience across the entire demographic, but doesn't necessarily guarantee a consistent experience for the website style.

 

The only other option to go all in and create a fully styled and fully adjustable accessible element. That's a lot of R&D and custom programming.

Most devs go with option 1 and hope for the best in their demographic.

 

It seems like GCHQ in this context may be trying to override the styling of a standard HTML browser element and the styling isn't turning out as desired in all browser contexts.

[+kunarion]

Here is how the Blue Button ("Submit" button) looks on some platforms.

 

This one is on my Samsung Galaxy Tab 7, Android.  Looks correct here, and the same as on my desktop PC in most any browser:

 

 

 

This is the Blue Button bug.  It appears in a lot of places where a submit button occurs, with other text.

On my iPhone 8, it's the same in Chrome, Safari, or my "fast browser", Alook.  It's more platform-specific, rather than browser specific.

It's hard to see here, but each instance of "blue" is the same color, the color of a "web link".

Note that the blue "OPEN" button has readable white text.

 

 

 

 

This is in Chrome on my iPad Retina ("iPad 4").  Note the similarity to the iPhone buttons, and how the "Go" button has again wrapped to the 2nd line.

The text for the buttons is black, and it takes extra web developer work to make a button grey across all platforms.  When the button link is blue, the black text is tough to see.

But you can't change the link text to white, because then it's hard to see on the gray buttons of other platforms.

 

 

 

 

[+thebruce0]

On the iPhone 8 image - the OPEN button looks different because that header is created independently by the browser, not the website - but the GO button is entirely HTML and generated on the website.

My guess is there is CSS perhaps attempting to override the element style to a white on blue button, but the font colour is being ignored in the browser for that element. In other browsers all the styling be ignored so the buttons are rendered according to the browser style. 

 

Or... maybe there is a browser styling being inserted to display that header, and its CSS styling for the OPEN button is leaking into the web page's display of the GO submit button... 

 

In any case, it's weirdness. And an example of unpredictability when you start trying to override standard browser asset stylings.

[+kunarion]

36 minutes ago, thebruce0 said:

On the iPhone 8 image - the OPEN button looks different because that header is created independently by the browser, not the website - but the GO button is entirely HTML and generated on the website.

 

Certainly.  I pointed it out merely to show that there's at least a conflict in color decisions.  If it was a consistent plan, both "OPEN" and "GO" would match.  But I think the "GO" button is supposed to be unbolded black text in a very light gray rectangle/oval, as it is on other platforms.  Just guessing.

 

I was astonished to see it happen on iPhone browsers.  It's not like there are only a few "iPhones" out there, all functioning differently.  It cannot have gone unnoticed.  And The Web Site was re-built to fit "phones", so we know it was intended to be run on phones at times.  So the explanation for the "Blue/Black Go Button" is... it was ignored.  OK, I don't know what the buttons look like on the latest iPhone.  Maybe it's fine.  In that case, still... it was ignored.  But the problem may then fix itself by attrition...

 

Not that it's trivial to re-design that button.  When I maintained web sites, I spent many hours changing CSS to match some template's color scheme (which I also adjusted), to display as well as possible on various systems.  My paradigm for a web site HTML was, dark text on light backgrounds.  Always.  That kills a lot of designer templates.  Too bad.  So sad. 

 

Edited March 8, 2022 by kunarion

[+thebruce0]

9 minutes ago, kunarion said:

37 minutes ago, thebruce0 said:

On the iPhone 8 image - the OPEN button looks different because that header is created independently by the browser, not the website - but the GO button is entirely HTML and generated on the website.

 

Certainly.  I pointed it out merely to show that there's at least a conflict in color decisions.  If it was a consistent plan, both "OPEN" and "GO" would match.  But I think the "GO" button is supposed to be unbolded black text in a very light gray rectangle/oval, as it is on other platforms.  Just guessing.

 

I meant that the header to open in the app is generated by the browser, not designed by HQ, so I wouldn't expect any consistency between the OPEN and GO buttons. Which is why it's odd that there is a half consistency   If you can view the same page without that header appearing (not sure if there's a way to force the browser to skip that), I wouldn't be surprised if the button appears as intended.  And if so, I'm not sure what HQdevs could do to stop the header from overriding that standard HTML element style.

Anyway, we're just viewers from the outside, so there's nothing any of us can do, sadly. heh

 

12 minutes ago, kunarion said:

Not that it's trivial to re-design that button.  When I maintained web sites, I spent many hours changing CSS to match some template's color scheme (which I also adjusted), to display as well as possible on various systems.  My paradigm for a web site HTML was, dark text on light backgrounds.  Always.  That kills a lot of designer templates.  Too bad.  So sad. 

 

Yep. And as designers we have to decide whether to use standard UI elements or create our own; and if using standard elements whether to override browser defaults or not, and if so having to do browser compatibility research to determine which browsers even do allow overriding default UI styling and to what degree. I remember the big debate about the onset of CSS was completely changing the intent of HTML which was supposed to be universal allowing app developers to render the page with some flexibility in their UX. But browsers all decided to do things differently, so it was a like battle of creative web devs (wanting things to look the way they want) vs browser app devs (wanting things to work the way they want) vs accessibility functionality and flexibility (providing room for people who don't like/want any of the above to still have a reasonably functional website)...