Previous Entry Share Next Entry
Improving Hunt Software/Improving Google Docs
cananian

There's been a lot of discussion about publishing and sharing the software that Mystery Hunt teams use to collaborate to solve puzzles. This is mostly misguided, IMO: teams are very different, and they organically grow solutions to fit their unique processes. On the other hand, an increasing number of teams (including my team, Codex), are building their collaboration software on top of Google services, especially Google Docs and Spreadsheets. Rather than trying to collaborate on One True Hunt Team Software, I think it would be far more useful (for all teams) to lobby for improvements to Google's services. These raise the bar for everyone, and indirectly benefit many other people with collaborative processes.

So here's my list of improvements I'd like to see in Google services:

  1. Integrating Docs and Spreadsheet. If we had an initial "sheet" of the spreadsheet with editable formatted text (not spreadsheet cells) we could actually do away with the wiki we use for capturing free form thoughts and links related to a puzzle.
  2. Integrating Spreadsheet chat, Google Talk, and Jabber. We could just use the chat in the spreadsheet if it were open and accessible, instead of creating our own per-puzzle chat rooms.
  3. Making publish and "setAnonymous" access available via APIs that actually work. We need to use Google Doc Script to do the setAnonymousAccess call, which is not exported via the otherwise-more-complete GData APIs, and drive a headless Firefox 2 instance via Selenium to get the publish bits enabled for the spreadsheet. That's ridiculous.
  4. Providing a way for Google Doc Scripts on a spreadsheet to export data more easily. We can use a Google Form to create a spreadsheet for a puzzle, but no easy way to provide a link to that spreadsheet on the page that results after form submission, or redirect from there.
  5. IIRC Google Talk support for multi-user chat is still barely supported. It doesn't use the standard Jabber protocols, for one. If this were a better supported/more standard service, we wouldn't have to run our own Jabber server.
  6. And, of course, the "next generation" of all this would integrate audio and video into the chat as well. Video is probably more useful, as it communicates human emotional cues. Audio isn't easily archived or searchable, and doesn't work well in crowded rooms, so it is less useful to us. But it would be great if we could actually see some/many/most of the particants in ringhunters, maybe little live video icons next to their faces.

Any further suggestions from other teams?


  • 1
As I mentioned when I ran into you at some point, I ran into the publish bug too, and will do my best to get a fix for that pushed through (already opened an internal bug, etc). Of course if the past three years of running Google-based hunt software teaches me anything, it's that we'll fix this bug but break something else :)

I'd recommend trying to do Hunt development at a time more like early November if you want to get bug fixes pushed (the end of December tends to have production freezes, and then it's almost Hunt). Not that I ever work on my app before the week of Hunt :)

(http://github.com/glasser/hq/, if you' re curious about how I use spreadsheets. This year we decided to not use "publish" and use the semi-documented "withKey" "anyone with the key can access the sheet" instead, and embedded in our app's page using something similar to but not quite the same as publish which led to some odd results. Also, created the sheets not using the user's credentials but by using the credentials from an account created just for that purpose.)

We used withKey as well (but that's not supported by the GData API! Argh.) And I did notice that if you wget a spreadsheet URL you get a plain "basic HTML" version, so I was tempted to rip out the proper embed stuff and just use that instead. But it was ugly. Really, publish should just work.

We also used a dedicated account for sheet creation.

Actually, withKey is sorta supported by the GData API (version 3.0 at least). It's documented as read-only but if you do a PUT with something like withKey="anything", it'll generate a key which you can read back. Take a look at SpreadsheetAddHandler in https://github.com/glasser/hq/blob/master/hq/puzzles.py

Ah, I was using the Java API, which sucketh.

Oh, yeah, that wasn't in the Python client either, as you can see by the fact that I had to define my own AclWithKey class and insert it into the AclEntry class. I should submit that patch to the client project.

We barely use Google tools, but we do use Jabber and many people connect to our main chat and puzzle rooms with their gtalk account. Annoyingly, if you are logged into gmail as well as a Jabber client like Adium, chat invites will be uselessly intercepted by gmail and shown there rather than sent to your client. (Hence I only read email during the hunt through my phone.)

Just turn off chat in gmail.

Metaphysical Plant uses homegrown software with Google Spreadsheets integrated in, and as far as I know our kludgiest thing is the "log the spreadsheet chat in the second spreadsheet tab" software. I'd love to be able to use built-in logging instead.

I'd be really interested in how your huge kludge works. I don't think the spreadsheet chat is even mentioned by any of the official spreadsheet APIs.

Another Googler on Codex contributes:

I really wished Google Spreadsheets would show which sheets are currently being viewed/edited by the other users, down in the tabs at the bottom. You can see the cells the other users are on if you're already looking at the right sheets, but it was common for us to duplicate sheets and start pursuing other ideas, and then have people confused about which sheet people were actually working on.

Isn't Google doing an awful lot these days with collecting huge quantities of speech data to circumvent needing analytical solutions to problems in speech recognition? I would think that searching speech data would be right in line with their plans, and probably take into account internationalization and languages and all that.

It's great that this stuff is being developed for a particular puzzle competition but it looks like it could have a very broad range of applicability beyond that. There might be better replacements for some of the kludgey telecommuting tools people rely on (IRC, AIM, Campfire, Skype). It would be particularly cool to look at how to make big complex chunks of information more instantly accessible and comprehensible, like what Doxygen does for C code, but for other kinds of information besides source code.

You should get in touch with Careey when you have a moment. Don't wait too long.

  • 1
?

Log in

No account? Create an account