Log in

No account? Create an account


Dear Google,

You get a big thumbs down for making it impossible to report a bug on google spreadsheets. No, I don't want to post to a forum. Set up Bugzilla, and stop wasting 15 minutes of my (and presumably others) time bouncing all over your site looking for a way to submit a bug report.

P.S. Your array evaluation mode is busted. If it's not powerful enough to do something, failing is better than doing something arbitrary. I admittedly am not a spreadsheet guru (although I have reluctantly learned a few tricks from some).

I don't use Excel outside of very rare circumstances (I don't have a copy except on an old battered system - it's almost likable for a spreadsheet), I use GNUMeric a fair bit (very fast but a bit buggy), and Openoffice is useful to translate things between other formats (but is too heavyweight for my tastes). Google spreadsheets is a young product but looks to be slowly reaching the "reasonably useful" state. It seems like spreadsheets have the same kind of loose communal standards that SQL databases do - just irritatingly different that migration between them doesn't work very well, a few small differences, and some areas of advanced functionality where some of them are so different or deficient that one has to do a lot to replicate what's easy and done in another.

Rough areas of SQL database 「standards」 tend to be related to Relational Calculus, performance issues, constraints/triggers, data types, and cursors. Rough areas of spreadsheets tend to be in different evaluation styles (array evaluation, solver functions, etc), lookup/matrix functions, and data types. In theory, SQL is standard. I don't know of any standard for spreadsheets. Both are in about the same level of mess. The benefit to the standard is that we can blame Oracle or IBM or Microsoft or the Postgres devs when they don't adhere to it (and they can then say "yes, we don't, maybe we'll fix it if we feel like it"), while Microsoft, SUN (openoffice), or whomever presumably started out by copying each other and any interest in compatibility came from their early years of making migration to their product easy.

If I had a mac, I'd probably like trying Apple Numbers - I keep hoping to find something like Lotus Improv. I suspect for most of us who stay around software systems for long enough, we outlive a number of ways of doing things and carry that memory of something better with us for awhile (even if that "something better" is later surpassed). I'm sure there are people still around who take things a bit far and cling to their ancient Amoebas, cubes, or sufficiently old PCs with Matrox video cards for OS/2.


The easiest way to effectively bugreport a google product is to send your bugreport to a google employee you know (i.e. me) who can vet it and then file it directly in the internal bug tracker.

I suspect for most products it wouldn't make sense for us to expose a real external bug tracker, because people don't care whether the behavior is a bug or not, or whether it's been reported before, or whether they know what they're doing, and the triage load would kill us.
(Let me add to that that I don't speak spreadsheet well enough to understand your bugreport, so I would need to understand how that formula is supposed to work before I could file a bug internally.)
The bug report goes into some detail on this - to provide background:

Normally cells are evaluated in cell-evaluation mode - most functions take single values and simple aggregates that don't correlate with each other. For more complex things, there's an array evaluation mode which changes a lot of functions in spreadsheet-language to operate over aggregates of cells where normally they only operate over one. For example, in this mode, you can multiply ranges together (e.g. A1:A9*B1:B9) and you get a list of A1*B1,A2*B2,etc. You have to resolve things down to a single value in the end so it can fit into the cell in which the formula resides of course, but intermediate stages can have lists of "immediate" data.

You switch a cell to array evaluation by doing control-shift-enter after editing its formula rather than just hitting enter (this normally changes it to a funny-looking intermediate form when you view the form but changes it back to what you entered when you try to edit it).

The problem here is that the VLOOKUP() function is not array evaluation capable, treating a range in its first argument as just the first value in that range when run in array mode. In Gnumeric, openoffice, and excel, VLOOKUP() is array capable.

I'm not sure in general how much attention array evaluation has been given in google spreadsheets - the simplest tests work at least.
I suppose there's utility in having pointed out to Google some people they should consider hiring then (I've done a few), but that's still not a great system - there are probably a fair number of spreadsheet geeks who don't know a Google employee (or don't want to use their acquaintanceship that way) and can still generate a sensible bug report.

I wonder if there's a good way to get most people to use the forums without making everyone do it. It'd be cute to have quizzes whereby people could earn "spreadsheetIQ" or similar to help qualify them for the bug system, although that isn't necessarily the best solution.
Yeah, filtering bug reports is a hard problem (and I think the informal system of "poke an employee who can vouch for your cluefulness" is surprisingly good, despite my initial skepticism at it.)

I managed to find (with some searching) your bug in the internal bugtracker; it was reported a year ago with nothing since, so I have pung it and added myself to CC.

"If I had a Mac"

There are ways of installing OS X on a non-Mac nowadays. Some of them even (arguably) legal.