Thing is, I’m not a mobile guy. Say IOS to me and you’re likely to get “Don’t they grow corn there?” Users, unfortunately, don’t care. They’ll take your perfectly good web app and use it from a tablet or a phone. Then they’ll ask if you can change the spacing, or maybe even put up a phone app. That might excite you, but I’ve been kicking and screaming the whole way. And there I was, sentenced to spend two days in a big room chock full of serious phone heads.

Glad I did.

WindyCity gatherings feature a mix of presenters that make it damned hard to leave the conference without learning something new and useful. Better still, they offer ample networking opportunities to get (and offer) more personal input on the topics that have piqued your curiosity. And — lightning talks! — potentiallyimpromptu 5 minute presentations by attendees on “a topic of interest”.

Some things that got my attention:

Cody Dove of the Chicago Improv Commission (CIC kicked things off with some very funny improv on the first day, even if you are not a werewolf) talked about the creative similarities between improv and writing software. His “yes, and …” exercise demonstrated just how much we lose with a “yes, but …” outlook.

Eric Meyer of 8th Light blew me away when he showed us how to do TDD on IOS with a full up “Slide show? We don’t need no stinkin’ slide show!” presentation. OK, Eric ran through a few slides to get things rolling, but then he announced it was time to code. Dude! (Yeah, yeah – geezers should never say “Dude!) I can barely type with somebody looking over my shoulder. This guy was coding live for a large room of (probably picky) developers.

And it was brilliant.
Here’s why:

When my business partner (also my wife!) and I talk BDD to people, we often find interest coupled with resistance:

“Great stuff, and we definitely want to go there, but we’ve got major deadlines right now. It’ll have to wait.”

It’s the classic IT conundrum: “We’re too busy chasing our tails to stop chasing our tails.” Poor development practices generate feedback loops. You scurry to meet deadlines. The trip from A => B mesmerizes you into forgetting that the goal is Z, not C.

Spec languages and story runners and red/green/refactor and and test doubles, mocks and bears, oh my! sound pretty scary, especially when the development treadmill is keeping you out of breath.

I understand that. I also understand that there is overhead, not to mention fear and loathing, in learning new tools and processes. However, watching Eric work let you see that BDD/TDD is not some special heavy-weight version of development. It’s just development. If anything, letting the tests lead you is easier than working without a net, and certainly less error-prone. Fewer errors means that A=>Z comes faster, and that’s how you get projects done on time. The worst way to get done quickly is to hurry, and thank you, Eric, for showing us how easy it can be to do things the right way.

“Doing mobile right”, not a single presentation so much as a theme that seemed to bind three different presentations together for me. Strictly speaking, most of the conference was about doing mobile right. We heard about integrating mobile into your business, the relative merits of native apps vs the mobile web vs. hybrid apps, etc, but three presenters seemed to hone in on the essence of maximizing the mobile experience from a design and implementation standpoint.

Jason VanLue of Envy Labs kicked off his segment by referencing Web daddy Tim Berners-Lee’s declaration that “The primary design principle underlying the Web’s usefulness and growth is universality” and declaring that there is no such thing as a mobile web. Or… a pc web, or a 60” LED flat-screen web. There is just one web, and we reach it by various means. Responsive design seeks to understand our users and the context in which they work. Media queries allow content and context to be preserved across a range of devices, but break points are chosen in consideration of content and use, not devices.

Jason’s a designer and, without much comment, he displayed a series good design principles, including these from Frederick Law Olmstead, designer of New York’s Central Park:

Respect the Genius of a place

I like this one, even if it is hard to wrap your mind around the thought of genius lurking in a lousy Eight square inches of touch-screen LCD. There is, however, a certain brilliance in something tags along wherever you go and connects you to the world in a way that is both public and personal. Messing with that space should not be done lightly.

Never too much, hardly enough

The need for a light and disciplined hand in this space should be obvious, but I’ll bet you’ve seen more than 1 app that didn’t get the memo.

The next day, Chiu-ki Chan, who should be certified as an alternative energy source, dove into fluid design for Android. She talked native app instead of web, but her session could have been the lab period for Jason’s classroom lecture. In addition to being a very accomplished developer, Chiu-ki is the force behind Monkey Write, an Android app that teaches kids the proper way to make Chinese characters by making a game of the process. She took us through the design evolution of her app, going from concept, to working with a designer, to creating the horizontal representation for 10” tablets to the vertical representation on phones. Chiu-ki really knows her Android and provided plenty of useful code examples, but the real nuggets in that stream were her design decisions: what got put in when, what got left out, what got resized, and what didn’t. Some of those decisions involved the app’s bookshelf, which held additional modules. She used flat-packed IKEA furniture as a metphor for the way she assembled individual visual elements to create the bookshelf and described the practical design and utility considerations — ie, having enough space to hold things that are big enough to see — that led her to eliminate the actual shelves in the phone version of her app. I could almost hear Jason doing a quiet voice-over as Chiu-ki described her determination to keep the character workspace square. Chinese characters are square and she did not want the space to stretch or becme distorted. Respect for context. Very cool. Last and maybe least, Chiu-ki gets the prize for best line of the conference: “There’s no room for a monkey on my phone!”

Justin Munger, aka the Man of a Million phones, completed the topic by taking us on a tour through Microsoft Windows Phone and its Metro interface. As an old free software guy, saying nice things about Microsoft isn’t easy, but Metro’s pretty slick. Unlike the chrome-oriented IOS and android platforms, Metro is typography based, inspired by the pictographic signs that guide people throughout Europe and the rest of the world. Size and placement of typographical elements highlights important information and the result is a very clean and easy-to-read look. There’s also a cool panorama feature that treats the screen as a viewport into larger space. While that’s not exactly new territory, the natural way Metro cues you to look for more is fresh. Instead of some “Hey pal, there’s more stuff” screen element, some aspect of the background is left intentionally incomplete — running off the edge — leading you to swipe over to bring the rest of the screen into view. It’s little unsettling to some, but works pretty well, not to mention harmonizing nicely with the Olmstead principles listed from Jason’s talk the day before.

Metro’s Bauhaus cool look makes the iPhone and android look almost quaint by comparison. Better still, my old geezer eyes were able to read and navigate a phone without glasses. That doesn’t happen much these days. I’m sure it’s not everyone’s cup of tea, I don’t know what it’s like to live with on a day-to-day basis, and Microsoft certainly has mountains to climb with its microscopic market share and small app store, but…Metro is cool stuff.

And, finally, I come to, well, finally…sitting down at the bar at the end of the conference and talking mobile development with some of the presenters and fellow attendees. They were regaling us with tales of how much simpler it is to develop for IOS than for Android because of Apple’s tight control of the hardware. Develop for IOS, and your app will run on all IOS devices. I turned the tables just a bit and pointed that we had picked up some tablets for which there is no iPad equivalent at any price. And isn’t that the problem for developers? Economics is driven by demand, not supply. If people want something, somebody is going to figure out how to sell it to them. Amazon brings out the Kindle Fire and millions of people buy it. Some buy it instead of an iPad and some buy it in addition to their iPad. Either way, compelling products will attract users and developers will, as always, be stuck with that fact. Doesn’t look like mobile development is getting any easier any time soon, especially if Windows Phone can manage a resurgence.

Lots of fresh-faced young developers. Smart,  full of passion and still able to recite the design patterns they learned in computer science class (not so long ago).

And doing some mighty cool stuff.

All very good, but…

Rails ain’t bad for bringing  up boring old applications that just  work reliably and well without needing a full staff and staff meetings and arguments on where to hold the Christmas Party .

Ruby and Rails are liberating technologies, but neither can be picked up in a matter of days.  Doing them right vs merely doing them is the difference between having a tool and fighting an obstacle.  I know.  I’ve cargo-coded* my way head-on into more than a few jams.

Do it right, and Rails rewards you. Do it wrong, and it slaps your hand hard.

That’s what I’d like to write about — including some of the bone-headed mistakes I’ve made along the way.  Hope I can make it interesting.

* Cargo code: (Noun or verb) To borrow pieces of code that you don’t fully understand, but serve your need at the time.  Until, that is, something changes and you’re screwed because you don’t really know why they worked in the first place.