wubbahed.com

So my simple Morse Code widget has been in the Ovi Store for almost two months now. It’s free, and I didn’t spend too much time developing it, but the Ovi Store finally got their Reporting system back up and running, so I thought I would share some stats on how the app is doing.

• As of this writing, the widget has been downloaded 10,582 times.
• The widget has been download from 130 different countries.
• The top 10 countries that downloaded the widget are UK, USA, India, Australia, France, Finland, Brazil, Singapore, Netherlands and Turkey.
• These 10 countries only accounted for 62% of downloads.
• 65% of the downloads are coming from four devices – E71, N95 8GB, N95 and N96.

How is this comparing to other developers out there?

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?

UPDATE: That was fast, just got an email that the widget has been accepted!

I’ve officially submitted the Morse Code widget to the Ovi Store where hopefully it will downloaded onto millions of devices worldwide. And guess what? It’s FREE.

In case you’ve forgotten about it, here’s a brief video showing how it works.

Over on Taxpayers for Common Sense, they’ve been doing a good job of keeping up with how well House members are complying with new rules about posting earmarks and appropriations to their websites.

The webpage on taxpayer.net gives some insight into their process, but unfortunately, their Excel spreadsheet only uses legislator’s names. This is fine for most individual projects, but if you want to mashup the data across multiple data sources, then ideally you need a common identifier like a GovTrack ID or a BioGuide ID.

Anyway, I took a quick stab at writing an Excel macro which attempted to figure out people’s bioguide IDs. Here’s the results:

Database of FY2010 Earmark Requests (with BioGuide IDs, version 8)

Note that this work was done with version 8 of the Taxpayer.net database, so if they continue to release new versions of their spreadsheet, this representation might be a bit behind.

Now that RepresentedBy has launched, I’ve had a little bit of free time to turn my attention back to my last post about digital transparency.

To help keep the conversation going about digital transparency, I’ve setup a website dedicated to the work around the Digital Transparency Index. The goal of this site is to act as one way of measuring online activity and transparency with legislators, and by providing the data in an open format, allow others to mash it up with their data and observe trends in Congress.

It’s still a work in progress (is anything finished these days?), but check it out and let me know what you think.

http://digitaltransparency.appspot.com

Current Digital Transparency Index for Congress

For the past two months, I’ve been developing RepresentedBy, a Facebook application created for the Sunlight Labs Apps For America competition. During the two months of development, I’ve immersed myself in the online government world and while I’ve been exposed to quite a lot of great work by passionate individuals, I’ve also realized how little of Congress is digitally transparent.

Digitally transparent can mean a lot of things to different people, so in an attempt to quantify that, I’ve developed what I’m calling the DTI, or Digital Transparency Index. This is a number between 0 and 115 that gives you a rough idea of how engaged a legislator is in the digital world. Legislators are scored on the following criteria:

• 25 points if they have a public facing email address
• 20 points if their website has a valid RSS feed
• 10 bonus points if they’ve posted a news item to their RSS feed in the past week, 5 bonus points if they’ve posted a news item to their RSS feed in the past month
• 20 points if they have an active Twitter account
• 10 bonus points if all of the tweets on their home page are from the past week, 5 bonus points if all of the tweets on their home page are from the past month
• 20 points if they have an active YouTube account
• 10 bonus points if they’ve posted a YouTube video in the past week, 5 bonus points if they’ve posted a YouTube video in the past month

The sad truth is that Congress isn’t as digitally immersed as a lot of us. Out of 115 possible points, the highest score anyone received was an 85. Worst of all, out of 451 active legislators, 209 of them scored a big fat zero, 161 legislators scored low (meaning an index of 35 or less), and only 81 legislators scored 40 or higher.

My first assumption was that this gap was an age related issue. The average age of Congress is around 60 years old which isn’t exactly the average age of of your cutting edge Internet user. However, I compared the results of the Digital Transparency Index with the number of years that someone has been in Congress and didn’t notice any obvious trends implying a difference based on age. Here’s a graph showing the results.

The far right of this graph indicates highly engaged digital legislators, and the far left of the graph indicates poorly engaged digital legislators. Aside from the large number of legislators who are not digitally engaged, when you start looking closely at highly engaged digital legislators, there’s not a huge disparity between the number of new, younger legislators engaging digitally and older, veteran legislators engaging digitally.

Next, I wondered if there was a connection between digital transparency and earmarks. Taxpayer.net recently released information about active legislators and the earmarks they have included in the 2009 stimulus package so I compared the amount of solo earmarks included by each legislator with their Digital Transparency Index, and graphed the results:

While there is a disproportionately large number of legislators who are not digitally engaged and who have not sponsored large earmarks, you’ll notice that as digital engagement increases, there becomes fewer and fewer legislators who are sponsoring extremely large earmarks. The only exception to this rule is Nancy Pelosi who has a very large Digital Transparency Index (80), but has also sponsored a large number of solo earmarks ($15,667,000).

Is this a trend? Does being digitally engaged and having real-time communication with your constituents discourage legislators from sponsoring earmarks? Or is it the opposite and legislators who don’t support earmarks on principle are more likely to take that message directly to the people and engage with them digitally?

Here’s a table summarizing my findings.

If you want to see where your legislator falls on either of these graphs, then check out RepresentedBy, a Facebook application I’m creating which includes this information and personalizes it to your specific district.

Finally, I hope to develop the Digital Transparency Index some more, so if you have any comments or suggestions on how to improve it, then please include them in the comments.

My last entry about Google AppEngine and Facebook Applications was written during the development of RepresentedBy, a Facebook application which is still in a rough beta state, but has finally been opened up to the general public.

The goal of RepresentedBy is to:

• To increase civic engagement.
• To increase personal awareness of the legislators representing you in Congress and how they are voting on important issues.
• To share information about your representatives with your friends, and to encourage civic engagement among your peers.
• To provide an open source learning template for Facebook applications developed with Google App Engine.

The app is still in beta, but once it’s ready for release sometime in late March, then the source code will be made available. In the meantime, please check out the application and let me know what bugs you find, and any problems that you encounter.