wubbahed.com

I’ve proposed a talk for SXSW Interactive next March called “Stop Talking, Start Making,” and I would love it you could visit the SXSW PanelPicker and vote for my presentation (along with all the other sessions that interest you). SXSW is unique from other conferences in that the popular vote heavily influences their selection, so your voice definitely counts!

“Stop Talking, Start Making” is about the importance of rolling up your sleeves very early in the creative process, and spending 24 hours getting your hands dirty building something. You can’t just sketch something out or put together a few slides in a PowerPoint presentation, you’ve got to build and demonstrate a working product.

In the tech world, this approach isn’t new. For years, it’s happened at BarCamps and hackathons, and the ethos is a central part in many hacker labs, co-working spaces, and publications.

But this presentation isn’t for developers — it’s for creative types, marketers and brand owners. You’ll learn ways you can incorporate the hackathon model into your creative development process—to rethink a brand, quickly build ideas from scratch, and to incorporate new and emerging technologies into an existing brand.

You’ll also learn how the hackathon can be an invaluable tool for evaluating and nurturing internal talent, as well as for recruiting new talent.

Most importantly, it will be fun and entertaining. I promise.

The Challenge: Build and release an app that required less than 12 hours of work.
The Result: NYC Subway Status for Android

I’ve been beating the drum lately on the need to build things very quickly. I’ve found that despite loads of thinking and planning, often you don’t discover most of the real problems with your idea until you’re knee deep in development. Building something in a brief time period is meant to short circuit the process and avoid analysis paralysis.

Working this way, though, can be very stressful. You’re having to cut corners, to make compromises, and to eliminate functionality in order to meet your deadline. However, working like this also forces you to simplify your ideas and focus on the core user experience which can lead to a simpler, more refined final product. Sometimes it’s better to do one feature well than to cram in three or four features.

The result of this latest personal challenge is the NYC Subway Status app for Android. It was built in a few hours and does one thing very well — tells you if the NYC Subway lines are running smoothly, encountering delays, or scheduling maintenance. Here are some screenshots of the app in action.

You can install the app for free just by searching on the Android Market. Alternatively, you can scan in this barcode on your phone.

Enjoy!

UPDATE: Version 1.0.3 now released!

So for the past few months, I’ve been working with food writer Michael Ruhlman on the Android adaptation of his cookbook “Ratio”. Well pop some bubbly, cause the app is now live in the Android Market! Search for it on the Android Market or scan this barcode:

Last night I attended the In Code We Trust meetup at Eyebeam, which was an excellent gathering of people talking about what they’re currently doing in the Gov 2.0 space.

One of the speakers was Sarah Kaufman from the MTA, highlighting the hard work they’re doing right now to help bring MTA information and data to the developer community. Check out the MTA data sets currently available including the new GIS information about subway entrances and exits.

Sarah’s talk reminded me of something I’ve been wanting to do for a long time — create a simple calculator to figure out how much money to put on a MetroCard. The MTA vending machines make it easy to put an exact dollar amount on a card, but it doesn’t make it easy to figure out how to add 4 rides or 8 rides to a card. It’s not a hard problem, so I took 30 minutes last night and made a simple web page that figures this out for you. It should work on iPhone and Android, so check it out.

http://bit.ly/mtacalc

Finally, I should add that I made this in 30 minutes, so it’s probably got bugs, but who cares? It’s usable. It’s a released product. It’s more important to get something out there and get feedback than to linger in development forever trying to make it “perfect”. Let me know what you think.

I’ve been posting some of my more technically-oriented posts and micro-posts over on http://www.techreative.com/. Here’s the most recent one.

Making Android development designer friendly

So for the past few months, I’ve been working with food writer Michael Ruhlman on the iPhone adaptation of his cookbook “Ratio”. Well pop some bubbly, cause the app is now live in iTunes!

Purchase Ratio for iPhone and iPod Touch

I’ve been using MobilePress for a while now on my blog. It’s a quick, easy way to make your WordPress blog friendly for all those crazy smartphones out there like iPhone, Android, Nokia, Palm Pre, etc. etc. You just add the plugin to your WordPress install, activate it, and you’re set.

My only issue with the plugin is that it doesn’t support alternate content for mobile devices. Sure you can post the same text in both places, but it doesn’t always work that way for things like very large images or YouTube embeds. Often you’ll want the desktop version to have the very large image, but the mobile version to have a small thumbnail. Likewise with videos you’ll want your desktop site to have the full video embed, but the mobile site to have a link to the 3GP version of your video. To solve this, I quickly wrote an extension to MobilePress that allows you to accomplish this using WordPress shortcodes. Here’s the result.

You’re on the non-mobile site!
see mobile version

If you’re on the mobile site, you should only have seen a small thumbnail linking to a mobile version of the video. But if you’re on the normal version of the site, you’ll get the full video embed.

So how did that work exactly? In the post itself, place [mobile] at the beginning and [/mobile] at the end of any text you want to appear only on the mobile site. Likewise, for content that you don’t want to appear on the mobile site, you place [nonmobile] at the beginning and [/nonmobile] at the end of any text. For this post, here’s what the text looked like.

[mobile]
<h1>You're on the mobile site!</h1>
<a href="rtsp://rtsp-youtube.l.google.com/CkYLENy73wIaPQk4TalGJzJtDRMYDSANFEIJbXYtZ29vZ2xlSARSBXdhdGNoWg5DbGlja1RodW1ibmFpbGCLjNC-9__5m0oM/0/0/0/30/video.3gp">
<img src="http://i.ytimg.com/vi/DW0yJ0apTTg/default.jpg?w=160&h=120&sigh=uxtjuGf9Vjatje_YL3m1JSn0mMY" alt="video" width="160" height="120" style="border:2;margin:0px;" />
</a>
[/mobile]

[nonmobile]
<h1>You're on the non-mobile site!</h1>
<object width="425" height="344">
<param name="movie" value="http://www.youtube.com/v/DW0yJ0apTTg&hl=en&fs=1&rel=0"&rt;</param&rt;
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src="http://www.youtube.com/v/DW0yJ0apTTg&hl=en&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed>
</object>
[/nonmobile]

Pretty easy, eh? Here’s the source code for the plugin.

function mobilecontent_func($atts, $content = null) {
	if ($_SESSION['SESS_MOBILE_ACTIVE'] === TRUE) {
		return $content;
	} else {
		return "";
	}
}

function nonmobilecontent_func($atts, $content = null) {
	if ($_SESSION['SESS_MOBILE_ACTIVE'] === TRUE) {
		return "";
	} else {
		return $content;
	}
}

add_shortcode('mobile', 'mobilecontent_func');
add_shortcode('nonmobile', 'nonmobilecontent_func');

That’s all there is to it. Each of these functions just checks for the existence of a session variable telling whether or not you are using the mobile version of MobilePress (the cookie management is handled entirely by MobilePress). Based on the session cookie, it either returns the text itself, or it returns an empty string.

I’ve only spent a few minutes writing the plug in, so I am curious if others would find this useful or if there are any obvious bugs or enhancements people notice.

You can download this MobilePress extension here, and let me know what you think.

May 30-31 is BarCampNYC4. Register now as slots are disappearing quickly.

I’m putting together something to talk about RepresentedBy and its future development roadmap. Will anyone else be working on something around open government, or technology for change? Would love to assemble a group session on this.

Recently, I’ve been playing around with Minify. For those who’ve never heard of it, Minify is a simple HTTP content server built as a PHP5 application. It’s placed in a folder on your server, and then either using a querystring or mod_rewrite, it will dynamically merge and minify CSS and JS files as they are served up to a user’s browser. This allows you to develop using multiple CSS or JS files with comments and clear visual formatting, but when they are delivered to your users via a browser, they get minified and optionally merged making your site load and render faster in the user’s browser.

While Minify is meant to run on a webserver, I thought it could also work as a handy offline tool for optimizing Nokia WRT widgets. Since WRT widgets are just zipped folders of Javascript, HTML and CSS, Minify seems like a simple step you could include in the widget packaging process of your workflow before testing and deploying.

I wasn’t sure how much savings Minify would give the average WRT widget, so as a quick test I batch processed the contents of the STEW sample widget from Forum Nokia using Minify running on a local webserver. The resulting files were bundled as a new widget, and here’s a comparison of the two.

The savings aren’t gigantic, but they’re significant enough that you should seriously consider adding this step before deploying a widget. I’d also be curious to see if anyone has done comparisons about whether or not Minify affects how much memory is consumed at run-time in the browser.

I might do some more work on automating this process or creating a tool that minifies widgets automatically for you, but ideally, I think this should be something automatically built into widget IDEs like Aptana.

How are other developers out there currently optimizing their widgets for release on Ovi Store?

I’ve spent the past two days attending the inaugural Nokia Developer Summit. For those interested who weren’t able to attend, there’s been coverage on Nokia Conversations, and on Twitter using the #nds09 tag.

The high level takeaways from the show are:

• If you want to develop for Nokia, build WRT widgets. They’ve got a lot of functionality, you can tie it in with other Ovi services, and they can be built quickly.
• If you need more low level control than is offered by WRT, be sure to develop using Qt because that’s the direction everything is moving in — S40, S60, and Maemo all are moving towards Qt
• Once you’re done with your app, supposedly you can make lots of money with it on Ovi Store.

I don’t attend a lot of conferences, but if I had to give this one a letter grade, I’d give it a solid B.

WHAT WORKED

• It was a large enough conference to be significant, but small enough that it still felt real and informal. Attendees were friendly and open.
• The Nokia staff were extremely friendly and responsive. Everyone at Nokia I talked to gave time and attention to my questions, which is more than I can say for some other confereneces I’ve attended. There were even some instances where they went above and beyond. For instance, @ribot and I were talking about some Flash Lite issues, and when the Forum Nokia rep didn’t have the answer, she picked up her phone, dialed a number, and handed it over saying, “The Flash Lite guy is on the phone. Ask your question.” That’s responsiveness (and let’s hope they continue that same level of responsiveness online).
• There was a good mix of content delivered in meaningful ways. In addition to keynotes and specific tracks, there were sessions to demonstrate hands-on coding, and fun events like the 24-hour hackathon. Even the booths at the event didn’t feel too gimmicky or sales oriented.

WHAT DIDN’T WORK

• Not enough specifics about timelines. We were shown a lot of new technology, but no clear roadmaps for exactly when the APIs would be made public. Also, some APIs were clearly targeted towards WRT developers and some towards native app developers, but this info wasn’t offered up — it didn’t come out until the Q&A.
• Not enough emphasis on clear development paths. Developing for mobile involves a chaotic mix of different devices, screen sizes, firmwares, OS features, network speeds, local languages and operators. I was hoping that Nokia would help make some sense of this mess and give developers some idea of where they could obtain maximum value for their efforts, but no one seemed willing to put a stake in the ground and say, “Do it this way.”
• Truly embracing openness. Lee Williams from the Symbian Foundation gave an emotional presentation on living and breathing the idea of open source, but in countless other sessions Nokia was promoting APIs that were only available to select partners and wouldn’t be open to the public until the software was released publicly. I really wish Forum Nokia would adopt their own Labs section similar to Nokia Beta Labs where *anyone* could be given early access to some of these APIs.

But overall, I thought it was a great experience. I’m curious what others out there are thinking (regardless of if you attended). Comments?