Background: The DC government is exposing an API for their 311 call center, to allow application developers to build open source tools to make it easier for citizens to submit issues. As part of it, they and iStrategyLabs have launched a second Apps for Democracy contest. The creative juices are flowing, and I have a few ideas I plan on implementing.

But first things first… in order to make it even easier for myself and for other developers, I built out a ruby gem that interacts with the Open311 and Geolocation API. I know I’m helping out my competition, but it’s all for the better good, right? Here you go:

http://projects.skeevisarts.com/code/DCGOV-0.0.1.gem

You can also grab it from github: http://github.com/skeevis/dcgov/tree/master

Download and install it, and you should be set. It’s fully tested using rspec, so just open up the spec folder and you’ll be able to exavtly how it works. I’ll eventually add this to rubyforge, but for now you can take the extra step

DC OCTO has a ways to go. The API is supposed to launch on July 1st, but they certainly have a lot more to do with the API, both in terms of development and documentation. The Geolocation API seems to be pretty solid. The 311 API has unimplemented (stubbed) functions, spelling mistakes in variable names, no error handling, and no documentation (the “submit” function, the most important, is a total mystery). It’s too bad that people will find this when they head to the CodeJam over the weekend, but oh well.

Good luck to everyone else!

I had an idea for a widget, and felt like brushing up on my Flash and Actionscript skills.

Here is a very very rough Version 0, with Clearspring already set up!

I have to work a lot more on the style of course. I’m also thinking that these narrow dimensions just arent cutting it.

Like so many things from my college experience, I never realized how amazing this was until years later.

Rather than taking a “usual” internship at a government agency or consulting company for the summer, I instead chose to stay on campus for the summer, and in addition to a lot of relaxing, worked at two amazing labs at UMD. One was the Center for Satellite and Hybrid Communication Networks, where I got to play around with awesome gadgets like motion tracking cameras and sensor networks. The other position, which I kept throughout the following school year, was as a researcher in the Human Computer Interaction Lab. I was tasked with working on an Java interface (using Swing) for the MALACH project, which, in a nutshell, was to allow people to browse and view a massive amount of transcripts of recordings of Holocaust victims. The recordings originated from the Shoah foundation, whose mission is to record and store all memories of survivors of the Holocaust (side note: my grandmother volunteered as one of the interviewers). So I spent the summer working under Ryen White, who now works at Microsoft Research.

As we were presented with developing an entirely new interface, we had a number of challenges. We came up with some pretty cool solutions. One thing I came up with was an interface element nicknamed PygmyBrowse. PygmyBrowse is a rather simple and easy method of bi-directional navigation of infinitely complex trees in a compact environment. I thought nothing of it at the time, but the professors around me disagreed, and suggested I pursue it further. After spending a good chunk of the semester holding user trials (in between running one of the largest student groups on campus, being actively involved in my computer, and oh yeah… double major), we ended up with an academic paper, with yours truly as the primary author. Which ended up getting accepted to a major human-computer interaction conference. Whiiich I didn’t attend, because there was one or another extra-curricular event going on (kicking myself 3 years later).

Now when you do a google search for PygmyBrowse (a lame moniker I concocted with a couple friends), it’s actually been implemented.

If I dig up the Java source code for it, I’ll release it.

You can download the PDF of my paper here, or view it on Scribd.

When I first made the jump from a big consulting company to a tiny creative agency, I was worried I would be spending most of my time doing small boring web projects. Yeah, right.

As if I the C-SPAN Convention Hubs that I wrote on earlier weren’t successful enough, we at JESS3 teamed up with C-SPAN and New Media Strategies again to launch the Debate Hub. I served as lead developer. Not only does this have the same great features as the Convention Hubs, like embeddable video, Twitter coverage, and blog content from all over the web, we added in some really killer features.
The Timeline is one of the best features. We’re pulling in transcripts as the debate progresses, and have it segmented out by speaker. Click on a piece of the timeline, and magic happens. This is built off of MIT’s SIMILE project.
The Transcript Treemap is another awesome feature. It shows the most used terms of each candidate, based on the transcripts, along with sparklines (more appropriately, the jQuery version). I even managed, thanks to some more jQuery magic, to allow you to dynamically filter what debates/candidates to show. Of particular importance to me, as the Treemap was created at my alma-mater’s Human Computer Interaction Lab, where I was a researcher for a short period of time (more on what I did there later).

It’s received a ton of press coverage, including ZDNet, Ars Technica, TechCrunch, RedState, and a number of other sites. It’s been a wild ride.

I’m not a very politically involved person. For me, I make sure I vote when possible, care about the issues I choose to care about, but never get more involved. However, I like to think that, when working on projects like these, we’re giving more people access to more information than they previously had, and allowing them to make more educated decisions when it comes to electing their leaders. It may only make a small difference for a small group of people, but that’s all that matters.

Hard to believe I graduated college two years ago…

JESS3 has been working on a not-so-secret project for C-SPAN in the past few weeks.

TechCrunch, the best tech blog out there, just reported on it. C-SPAN is still ironing out some last issues, but IT’S ALIVE!

Read it.

A very big moment!

Much more to come about it later.

Being a web designer and developer, the CMS I choose for a client is a huge issue. I wrote a little bit about it before. However, sometimes you just can’t find a CMS that will work for that particular project, and, barring changing the architecture of the site to fit in the mold, you’re left writing your own system for displaying and updating content, which, sadly, I’ve had to do a number of times.

I read an article today about FireRift – this seems exactly what I was looking for out of a content management system.

Firerift is a Template Independent CMS. That means you design and/or
develop how you want, and then plug Firerift into the portions of the
site where you want it to manage that content. Firerift will scour your
code looking for any Firerift Code Snippets and convert them into the
corresponding function.

Really looking forward to this, as should any frustrated web developer.

Stemming out of an heated conversation about who knows what, an idea was born. Jesse and I decided to hold off client projects for one day (just one, calm down!) and set out to build an entire Facebook application from scratch. We had tossed around different ideas in the week before, but by the time we set marker to whiteboard on Monday morning, we had locked down an idea – Facebook friend-based statistics. Jesse is a huge fan of data visualizations, and I like discovering information and patterns out of existing data that I didn’t realize.

So we started from scratch, and by the end of the day, we had the wireframes, full design and a functional version. Jesse was blogging during the day about it.

And now, it’s a full app! Say hello to FriendCompare! We still have a LOT more we want to do with this – even at 1 AM the next morning, Jesse and I were on the phone brainstorming on different things we could do. However, we had to cut it off somewhere!

Development-wise, the application didn’t turn out to be as easy as we thought it would be . Hence why, for the past week, among with working with all our clients, I’ve been working like crazy to get it out.

Some Development Notes:

• Having all the information about the users – their friends, events they attend, education information, is AWESOME – and digging out the interesting nuggets of data poses a really cool challenge.
• FQL, Facebook’s own version of SQL – the language used to access information from just about every modern day database – gives you access to what you think would be a great wealth of today, but also poses HUGE roadblocks, besides the privacy restrictions. You would think that for a statistics application, you would need lots of standard SQL functions like COUNTs and JOINs, but as Facebook had neither, we were left pulling huge amounts of data down onto our server and analyzing it there. This makes any good web developer cringe in pain.
• Additionally, Facebook’s API is horribly slow. If you try to make more than a couple FQL/API calls, Facebook starts timing out, rendering the application useless.
• Enter Preload FQL. Rather than you calling the API from your server, you can specify ahead of time what information you’ll need from the Facebook databases, so when Facebook calls your application, all the data you need is already there. However, developing in that method tripled the amount of time necessary.
• We needed a LOT of different pieces of information, so bearing in mind all the above issues, it took a lot more than a day’s work to get it done.

So, in hindsight, maybe this particular idea wasn’t the best to try and tackle in a day. We were offered an existing codebase, however I turned that down, as it seemed a better decision at the time to write from scratch.

Thanks to everyone who helped out, including Eric and Jay from Lookery! Not to mention all the people who blogged about it and sent messages of support, and our clients for letting us take the day off!

In order to better establish a web presence for myself, I am rebuilding my own website. I have big ideas for this, displaying my writings, past and present, my interests, my friends, my work, and also as an living technical showcase for my abilities.

One feature I wanted to have is a display of whatever I am up to in the online world. I wanted, to start out with, aggregate my Flickr, Tumblr, blog, Twitter, and Facebook accounts. In the future, I may add more.

I played with a few different tools for this to run off of, including FriendFeed. In the end, I decided on building my own with Yahoo! Pipes, both as an exercise, and in order to closely control how it works. Yahoo Pipes can be powerful, but at the same time cumbersome to work with.

It took a lot of tinkering around, but I finally got it to work

Then I made a minor variation to it, to show the one most recent item out of each. This way I can show them all together, if I choose to.

I plan on modifying these pipes so you can customize it for yourself at some point in the near future.

Out of desire to learn something new, and in part due to specific needs on upcoming client engagements, I sat down and plowed my way through Expression Engine. After about five or six hours of slugging through Michael Boyink’s amazing tutorial, I’m feelin’ a bit like Neo (youtube video below)

Having started out hacking out sites in phpNuke way back in the day, then b2 (the predecessor to Wordpress, that’s how old school I am), and moving to mainly Wordpress and a little bit of Drupal, not to mention numerous homebrewed solutions for client sites, I had a laundry list of things I was looking for.

Here’s what is awesome.

• Custom Field Groups – When you are building a site, most pages have more than one block of text. It’ll have some content boxes on the side, intro text, images, etc. While, say, Wordpress, is only really is suitable for having a title and a main body of text, in EE you can build sets of content, and assign them to specific template pages. This makes it ridiculously easy to build out and administer complex pages.
• Separation of content and display. ExpressionEngine handles organization and entry of the content. The template, when called, pulls any content it requires from the database. Most content management systems work vice versa, where templates are called to display specific pieces of content.
• PHP-less templates. I had gotten used to telling my web designers to avoid touching anything between <? and ?> . EE uses template tags that resemble Smarty. And, in my opinion, is easier for a non-developer to understand.
• Minimal need for plug-ins. Because it has so much built in, there isn’t that much need for them.
• There are a ton of other suprises – you’ll really only learn if you work your way through the tutorial.

But:

• It’s not free. You can download a free version to learn off of, but if you want it for commercial use, it’s $250 bucks. It seems pricey, but for what you are getting in the short and long run, it’s a drop in the bucket.
• Building a site in EE relies heavily on wiring things up in the control panel (the tutorial spends 75% of the time in there), which can be confusing and often mind-numbing.
• Because of that, it’s hard to rely directly develop the design and the site together. The design should be set and all CSS/HTML completed before you even think about firing this up.
• While, yes, it can run blogs, it was built as a general-purpose CMS. If your site is primarily a blog, I would still recommend using Wordpress or MovableType.

Mindy over at Viget has a great write-up of switching from Wordpress to ExpressionEngine. She points out some of the same issues, and gave some great pieces of advices for those used to Wordpress.

Looking to start out in ExpressionEngine? Download the core edition, and then pop over to Boyink’s tutorial. It’s a whopping 17 chapters, with a lot of repetition, but it is worth it to really lock down the cycle of building templates, weblogs, field groups, etc.

Facebook applications are awesome – and a good number of developers and agencies have committed to themselves full time to developing applications for themselves and for clients. We all see huge potential for being able to interact with users on such a personal level, so easily. Relying on other services is a big component of this generation of web applications in general. The ability to import and export data out of other services freely using publicly available APIs really lit a fire among coders, hackers, and entrepreneurs. I’ve used other people’s APIs to create a few things of my own (including a bunch of FB apps).

The problem is, it’s not yours.

* You’re running your business on other people’s property – They can kick you out an any time, for any reason (or none whatsoever).

* When it goes down, you go down – I’ve encountered periods of extreme frustration when something goes down (say, the Facebook Platform), and thus, your application breaks or disappears altogether. Good programming and redundancy can mitigate that **some** of the time, but otherwise, you’re stuck whining “it’s not me!”

* Who says they’ll stick around? – Similar to above. Unless they are an established and stable company (and what company is in the current economic state), they have to be concerned with their own profitability. Who says they won’t go belly up, leaving you SOL?

* You have no control – A slight change in the way things work can throw everything off-kilter for you, and you have no control over that. That happened to me last week, and, as responsive as they may have been, I still had no technical ability to stop it or change it back. You just deal with it.

* There are no guarantees, and no responsibility – You’re using a free service, most of the time with no SLA. While they may have you agree to something, there’s nothing on their end.

* You are just a feature – All too often, I’ve seen things that rely so heavily on external systems that it’s really nothing more than a nice little feature, a tool that helps someone use the primary service.

* You are replaceable – If you really are just a feature, who says you can’t be replaced. Everyone was yammering about social.im a few weeks back – so much for that. (there’s a rumor that they were acquired by the big blue giant, but I highly doubt it).

I’m not saying that you shouldn’t ever develop an application that relies on any external system. But you shouldn’t put all your eggs in one basket – diversification is the only free lunch.