A personal pet peeve of mine (and millions of others?) is that the Facebook Connect for iPhone login screen (which is how every Facebook app logs in, including Scrabble and all my own iPhone apps like Puzzle Jewels and Puzzle Jewels World Edition) uses the default keyboard type for entering you username instead of the handy email keyboard which has the @ and . symbols readily available.  This seems to be due to iPhone OS 2.0 not supporting tags for the email keyboard and it just got left that way I guess…

After yet another painful login on some Facebook-enabled iPhone app, I poked around Facebook’s bugzilla and found the bug report for it, and then I tested the input type of email that should tell mobile WebKit to show the email keyboard.  It works!  A quick message over to Brent Goldman, and a few messages back and forth because I didn’t have rights to reopen the bug, and boom the bug should be fixed by next week!  Because the login page is served up from facebook’s servers, no changes needed to all the Facebook-enabled apps out there!  Rock on!

Thank you, Brent, and to everybody else with an iPhone, you’re welcome!

My port of FrozenBubble to the iPhone has finally been approved, after about two weeks of waiting.  There were some interesting coding hoops to jump through, as this was a port of a javascript version which already worked in mobile Safari (thanks Glenn Hanson!), and I was converting it to run completely local/embedded in an AppStore application.

Had to hack the javascripts a bit to load everything from the same directory, as the bundle in iPhone apps seems to be flat.  Or it’s flat if you don’t unflatten it, or something.  No biggie.

Mobile Safari likes to have “bouncing” when you scroll past the end of a web page, even a short one, so gotta turn that off.  And gotta turn off the action menu if you hold your finger down.  And a few hacks to get sounds working.  Most of it came from http://www.codingventures.com/?p=31 - thanks fellow iPhone hacker!

Lots of little tweaks to make it feel like a native app, like using the accelerometer for tilt-based aiming.  The animation isn’t the best, due to poor little iPhone’s javascript engine breathing hard, but it’s pretty darn good for what it is.  And fun!

For a hobby project, my brother Alex and I wrote a game for little kids called TowerSmash.  I wanted to write a game, well really more of a toy, that was truly meant for little kids.  So  many “kid games” on the iPhone seem to have little buttons all over the place and levels that load and things you can and can’t touch and scores and bleeps and then boom the game is over.  Um, did we have fun yet?

I wanted something that was open-ended, and that kids could just play with.  What sprang to mind was how all kids seem to endlessly ask grownups to build towers out of wooden blocks so that they can smash them down using cars or their hands or whatnot.  So that’s what we built.  A toy where it’s easy to create towers of blocks and watch them tumble if they’re not balanced, and then easy to throw shiny balls at the blocks to knock them off the table and off the screen.

Get it from the AppStore – $1.99

The electronic catalogs for my nearby public libraries are pretty basic. They are the same boring Horizon Information Portal websites that provide the basics but sifting through the results is clumsy. And searching another library at the same time? Forget it.

Enter WorldCat. Searching a library is, dare I say it, fun again! Everyone can add reviews to library items ala Amazon, it automatically shows you nearby libraries that have the item using guesstimated location based on your IP, and they make money by providing links to Amazon if you’re too lazy to go get the book from a library yourself. Very well done… I’m jealous.

I still wish I could find my library search engine that I made back at UIUC in 1994. It was the capstone project for, of all things, CS411 Database Systems. The professor was dating/engaged/married to Eric Bina who was the co-creator of Mosaic with Marc Andreessen. And so apparently she liked the idea of making her databases class build a web application. I was fine with it, really, because Mosaic was pretty cool, although I found myself always keeping 2 windows open and dragging links from one to the other so I wouldn’t lose my place while I wandered about. Kind of a kludgy coping mechanism before the era of tabbed browsing.

I came up with the idea for my team of 3 to build a web interface to the UIUC library system, which was a mainframe beast, maybe 3270 but I’m not sure. Luckily one of the guys on my team had build the TCPSETUP program for Doom, so he was good at making socket programs and so he built a library for talking to the mainframe. I built out the perl-based webapp which took care of sessions, form-processing, calling the library to talk to the mainframe, rendering the search results, etc. The other guy, um, didn’t do anything.

Even though I didn’t have a name for it (usability) I worked hard to make the webapp easy, even fun, to use. You typed in a search by author or title and would get back a list of results all nicely lined up with information about each match. Click on a book to see more details, and best of all, get a form where you could put in your school ID and the library would send the book to your dorm room! For real!

Every team presented their final projects during the last week of class. Other teams had built basically useless apps, all were clunky, didn’t make sense, whatever. We presented ours to applause, actually, but apparently our professor was not impressed. “It looks too easy”, she said. That was the goddamn point! The back-end work to screenscrape multiple greenscreens for every page view was nutso stuff, and yes, the front end looked smooth & clean. She gave us a B. And that was when I knew that all those people who had told me that “grad school was when you start doing real work, no more theory crap like undergrad classes” were out of their minds. I had worked my ass off to build something real, and got a frakkin’ B for my troubles.

Postscript – a few weeks after this class ended, the webmaster for UIUC heard about my library webapp and asked if she could install it on the library website. It became the official library web search engine running at UIUC for the next several years. Yeah, that sounds like B-level work to me… Adios, grad school!

Tivo has 3 speeds of fast-forward. One arrow is about 2x, and when you drop back to real time, it starts playing right at that spot. But with two arrow and three arrow levels of fast-forward, when you click play to drop back to normal playback speed, Tivo rewinds a bit, on the premise that by the time your brain processes the scene that you want to see, you’ll have skipped past it a bit, so Tivo guesses how far back to rewind and starts playing from there.

In theory, this is a great feature, because you can relax a bit more while fast-forwarding. Instead of being on the edge of your seat and trying to “predict” when what you want to see will show up, you get to see a slight “preview” of what you are fast-forwarding past, and then you say “aha! that’s what I want”, and then Tivo skips back a bit so you don’t miss anything. But that, alas, is the Tivo Spoiler.

For those of us who occasionally watch reality TV shows that have various dramatic moments, it’s awesome to fast-forward through all the gobbledygook and inane chatter the hosts spew out to waste time and ratchet up the tension. The only problem is that as you try to drop out of fast-forward to see the Big Reveal or whatnot, you usually tend to see just a frame or two of the contestants just before your Tivo rewinds a few seconds so you can watch the envelope opening or what not, but your brain has already processed who won and who lost, so it’s kind of a let down.

*sigh*

I’m not sure how to get around this, really, aside from being more vigilant during fast-forwarding and also subjecting myself to more inane reality-show chatter…