Wed 5 Mar 2008

Quality Oversights In Google's Public Services

It's always annoying to have to examine the teeth of a gift horse, but if somebody is basically dominant in their area, or one of a very few dominant players and you are essentially forced to interact with them, then it's game on. Lately Google's non-search products have been driving me more and more to despair. Perpetual beta is not an excuse for producing poorly behaving services and not having a proper bug reporting system in place.

Two Examples

Only two, from amongst so many that are possible, but I want to get to the conclusion in less than 10,000 words.

Mailing List Administration

I went to clean up some spam from a couple of Django groups. It was already very painful to do this, requiring half a dozen clicks or so. You had to select the message, the click twice to open the screen report it as spam (once to open the extra options, once more to select the "report abuse"), then two more clicks to report it. Then back to the message and three or four more clicks to delete the message from the archives. No way to do this for multiple messages at once.

However, new, bonus feature: you now cannot report a message as spam without also typing something into the description box! So group administrators have to spend even more time to come up with some explanation. Really, really dumb. Okay, maybe you want some justification for some of the options like "against the laws of my country", but when a group admin is saying "this message in my group is spam", just believe them! Google aren't in a better position than the group admin to know. And, yet, somewhere inside Google, somebody can say "we knew it was painful; but we've changed it". Yes, but don't you dare use the word "improved" there.

Google Code

Google have a history of making revolutionary user interfaces. The whole reason that Google are well-known is searching and part of the success of their search interface was it's simplicity and utility. It's gone downhill a little lately with the blurring of the line between paid results and stuff you actually want to see in the search results, but that's another issue.

Google code's issue tracker is a sin against computers, however. It assumes my screen is such-and-such a width and that my browser is expanded to full screen, apparently. Because they've split the screen up into a multi-pane view without using frames (thankfully!), but have set overflow: hidden on the div containing the bug report and comment text! Hidden! On what planet is throwing away part of the main content, the whole point of viewing that particular screen of information, a good idea? What code and usability reviewers signed off on this debacle? Did you really only test it on your full-screen browser on your 24" monitor?!

So We Should Report A Bug, But...

It's been asked before on the Internet and there is no answer: where is the bug reporting system for Google. In both of the above cases, I went to the help screen, typed in "reporting bugs" and received precisely zero useful results. No issue tracker for any of these systems.

Since Google groups is being used by so many projects as their primary communications method and since an increasing number of projects are using Google code for hosting, I cannot avoid interacting with their products. I would file bugs if only they'd joined the 1990's and installed some kind of issue reporting system. Before anybody mails me, having to track down a "help" Google group from amongst the thousands of groups and hope that somebody there with the power to change something notices is not a solution here. That's broken because the right people don't get notified, because there's no indication of which is the right group to go to and because it doesn't any way to track an issue from reporting to resolution.

Yes, it's quite possibly impractical to have an issue tracker for something the size of Google code. People are very bad at understanding the difference between an actual bug -- something that makes using a product difficult/impossible -- and a request for a pony. People are very bad at searching for duplicates and will file a ticket and let you worry about if it's a dupe. Tough! If you're going to put out products and say that they're in beta, you are soliciting bug reports. Provide a way to receive them. Hire people in the role of bugmasters. Encourage an environment where finding and accepting flaw reports carries no social stigma. Further, where time is set aside specifically to work on this aspect. No new development, only fixing. This is hardly undiscovered country here.

Maybe all this is happening inside Google. Hard to tell, since they aren't a particularly open company about what happens internally. But, if it is, the effects are not visible. So the PR side of providing software is missing, too. Where are the Google blog posts about the 100 bugs they fixed in a concentrated QA effort in Gmail last month (hypothetical headline only. Not predictive of actual results)?

Contrasts

It's quite interesting and simultaneously incredibly depressing to see the new products coming out of Google over the years. Things like their picking up of the mailing list / newsgroup hole left by the relative demise of USENET, Google code, etc. They clearly have some people coming up with good ideas and a willingness to release experimental things into the world. But where's the oversight and the hindsight? If something becomes successful, where are the team trying to break it? Checking for standards compliance (Google's IMAP implementation is an example of a well-established standard being poorly implemented and tested. Now that it's turned out to be an accepted feature, who's fixing that)? The Google code issue is an accessibility problem (if I increase the font size, more and more information gets hidden. A win for all mankind ... not).

In revolutionary, agile development environments and companies, what I'm describing here is hardly a new problem. Everybody likes building new stuff. But maintaining and critically examining existing stuff is critical, too. There's some pride to be had in knowing about the problems and trying to fix them. There's some responsibility to be accepted by the larger company, too. If you're going to encourage people to experiment, then set aside more than just code review resources. Revisit things down the track. Try to break your own products. Don't hide behind perpetual beta, since that describes all software in the entire universe.

The thing is, Google clearly have the ability to fix this since (a) they employ a ridiculous number of clever people and (b) over time we have seen steady improvements in things like Google Reader. Spot the problem: the thing with a few hundred pieces of competing software gets UI improvements, whereas the areas with less players, such as large-scale project hosting and mailing lists do not. I'm sure there's an economy of scale issue in that Reader is much more self-contained than, say, Google groups, but the priorities are interesting to observe, too.

Being spread too thinly and trying to be too wonderful by continually releasing new products without a commitment to greatest quality ever are hardly new problems. It's sad to see Google sliding down that slope. Particularly as some of their products rise to dominance and become things people are relying on (and, by implication, dragging in other people who want to work with that first group). They're not alone here. I could write a similar mixed criticism and praise of Yahoo without struggling, although, on the whole, I think they do better in the more restricted spaces they concentrate on. However, it's not a level playing field. The big guys have to live up to higher standards if they're going to keep blowing their trumpet about how good they are. We, the users and the technically savvy of the world, have to keep holding them to those standards, too. Otherwise, it's just Microsoft all over again.

Apologies to all the people I know working in Google. You are smart people. Maybe you're even doing useful work. Don't know, since you don't talk about what you do. If you're working on these public-facing products, though, quit sucking at problem resolution. Transparency is a good thing in that area.

Topics: software/design, technology/Google