When Google decides your problem is not relevant enough to be solved
What do costumers expect when dealing with services from a tech giant?
That’s a tricky question.
Some people would say they don’t expect perfection in every corner: there are gazillions of things happening in their (several) products. Normally, some of these products might have problems, bugs and stuff like that, and there’s not enough capacity to fix them all quickly enough. I myself, as a CPO at a startup, would be tempted to have this approach. It’s, to say the least, logical from the prioritization point of view.
But is that so? How about being the user in need for once? How is the user pain being accounted in the decisions here?
How much can the user afford to deal with a problem?
Well, depends on the problem. But some problems just can’t be carried around for a lot of time. Especially if they reveal any kind of laziness on the making of the service/product carrying the problem
This is the case with Google AppEngine.
Oh, Google AppEngine. Not all of you may be familiarized with this ‘terrific’ service. I’m not gonna talk about it on detail. You can read about it on our beloved Wikipedia. http://www.wikiwand.com/en/Google_App_Engine
In our application, which is hosted on AppEngine, we deal with a lot of user platform addresses. Namespaces, as we call it. And some more have to be created from time to time. Where to go when you’ve got to create a new one? Google Admin Console.
And there’s the place when unexplainable things happen.
Google recently redesigned the Google Admin Console to carry Material Design. Nice. Really cool. This was news in a lot of places…
https://www.youtube.com/watch?v=5HmttbYH3SQ
Looks cool on video, huh?
But now let’s get to business… using it. Remember the namespaces? They’re listed here:
The namespace listing is blurred on purpose. But I hope you get the idea. Each line is a namespace and a ‘delete’ link aside. This page looks quite normal, right?
Except for the fact that our application has, in fact, hundreds of namespaces.
That list is simply cut around the 40th result. The others aren’t listed.
Seems like a simple CSS bug, right?
Let’s get to the inspector to fix this mess and continue working really quickly…
Wow. What the hell.
Seriously, Google. Get your shit together. You can’t be serious with this HTML/CSS structure. Inline styling? What is this, 1998? What’s about that much divs? No classes, no ids? Why, Google, why?
I wouldn’t care if this structure and styling was made this way… as long as it wasn’t causing me trouble. By the time I have to mess with Google’s CSS to fix a bug and be able to access the rest of the results of a page… well, then I start caring.
Stop, Google. This kind of mess can’t get to production.
We spend regularly around 10 minutes of messing around the divs’ heights (and they mostly don’t even have a class or id to be identified properly) to fix the problem and be able to access the end of the list. And it’s like this every time a different person has to access this functionality. Because of the lack of classes and IDs, I can’t even do the job myself styling the page properly with something like Stylebot. Seriously, Google?
The end of the list could just not be that important… but for some reason, the option to create a new namespace is there. The most important action on this page.
Not on a button on the top, not as the main action on the screen, but at the end of a list.
Which is unreachable because of a CSS bug.
Which is a mess to fix because of a lazy HTML structure.
On a paid service (that costs hundreds of dollars per month).
Get your shit together, Google.
PS: This has been reported to Google by our engineers at least a month ago. No response yet by the time of this writing.
