Know Your User: Elvis, Bean, Hedy

While working on Project Moab, we encountered a really interesting, and nuanced problem that led us to expand our thinking and ultimately guide how multiple parts of the system operated. It also gave us a fun tool that I’m applying to other projects as well: Elvis, Bean, and Hedy.

Continue reading “Know Your User: Elvis, Bean, Hedy”

Code Analysis: The Hot Sauce Test

Oftentimes I am called into a project that is adding new features to an existing application. While a lot of updates seem easy on the surface (I’m just adding a basic page that saves the user’s e-mail address), the underlying architecture of the system can make this rather complex. The shocking thing is that a lot of times the complexity isn’t immediatley discoverable. To help identify and estimate the work needed for a new feature, I’ve devised what I like to call “the hot sauce test.”

Continue reading “Code Analysis: The Hot Sauce Test”

Is the API the next killer app?

The ?killer app? is a term for those of a geekish lean that describes the ultimate application out there that you simply can?t live without. It is typically used identify a utility or program that provided countless opportunities to create new things, or tweak out your computer, or give you immense flexibility over content consumption. If was a mark of good standing if your application was tossed around in the question, ?Is this the killer app?? I dreamed I could write something remotely close to this.

By most references, VisiCalc was the first killer app since it open the doors to spreadsheets for the average user on a computer. Around the time I was getting into computers (the glorious age of DOS 5.2 of 14.4K baud modems), you could look to archive tools, such as PKZip, as the killer app that allowed people to move large sizes or numbers of files around with minimal hassle. Around this time I also found QModem to be my own killer app, since it allowed me to connect to my local BBS with plenty of custom scripting options [yep, I scripted out my own ZModem downloads before the protocol came standard 8^D].

As computers became more ?average Joe friendly? (no derogatory implications in any form), the killer app migrated out a bit more into the public sphere. Compuserve, then AOL. Became the killer app because users could send messages to friends, shop online, and check out special products from vendors. I?m sure there?s plenty of folks who remember when TV commercials had the tagline ?Check out AOL keyword X? at the end of them. Further still, browsers became the killer app, since you could use various plugins, or sites that were JavaScript heavy, to do things without downloading or installing anything. Even this trend seems to have passed by and the ?social portal? seems to be the next killer app. Facebook has held the lead on this one for a while now, but there are a good number of clones or similar type websites that will allow folks to share photos, discuss common interests, play games, and easily consume your free time.

But on the edge of the social portal I think lies the next, or potentially current, killer app, the API. For those not familiar with term, API is an acronym for Application Programming Interface. In simple terms, it is a programming library that the creator of a program has opened up to allow other programmers to interact with the core of the system, or the data within it. For example, in the process of updating the CCG Toolkit, I chose to create web services to be used as an API to view the Tournament Card Registry data. That way, anybody that knew how to consume a web service (or had a program that did so), could easily get at card data and rulings for their cards.

Firefox became immensely popular due to its plug-in interface, which was made possible by an API that allowed programmers to create nearly any kind of ?widget? that would load with Firefox and allow the end user to do more with their browser. The Flock browser took the best plug-ins it could find and integrated them natively into the browser to enhance the user?s browsing experience.

Twitter is probably the best example of leveraging the API to its advantage. By itself, Twitter is simply a protocol for displaying status updates and passing on other people?s statuses you find interesting. The interface was incredibly simplistic: a web page. You had to various searches if you wanted to check out what else was going on in the ?twitterverse.? That all changed with the release of the Twitter API. Now every programmer under the sun could create a desktop or web based application that did all the fancy searching/sorting/following that you wanted. You could create widgets on top of the Twitter API in order to display your recent status updates, or trending topics on your blog page.

The beauty of this is that Twitter developers themselves only had to focus on the infrastructure and the protocols to be used. They can then let the creativity of developers and the demand of the users dictate which applications bubble to the surface and are used. As a result there are huge amount of twitter clients out there on every platform imaginable. By doing this, usage of Twitter itself has increased without the actual developers of Twitter having to worry about aesthetics, UX, or even platforms specifics, something that has plagued desktop applications for a long time.

Facebook has an API. Various Google Apps (including Calendar and Maps) have APIs. MySpace has an API. My favorite programming site, StackOverflow, has recently released an API and is hosting a contest to see who can build the most awesomeness out of it. I could go on and on.

So while people are getting less and less tied down to a specific platform for their data and day to day interactions (I use a Windows 7 box at home, an iPod Touch while I?m out and about, and have an XP box at work), the killer app has to keep up with this. Since keeping up with the plethora of platforms out there is insane, the killer app has had to take itself one level deeper, to the core of the code itself, or the API. The new killer app is really an API on top of a framework that is going to generate users across any platform somebody is willing to write for, without troubling the original developer at all.

I guess the next question that arises, does the API need to come first for your product, or do you generate the product and use the API to seal the deal?

Simple Projects are not so Simple

A week or so ago, a request came in to help provide a notification system to the public based on news/announcements from various departments. We already had a module that generated an RSS feed based off of news items in our CMS, so extending this a bit for e-mail and SMS (text messages) notifications would be a snap. Departments could have notifications for a few different categories, and we’d structure the summary, the link, and the title accordingly. [Hot dang! I just found an RSS specific library to make generation of new items even simpler!] We’d keep the titles short, so if we ever moved into Twitter or something, we wouldn’t have length issues.

Being good programmers, we started outlining the workflow and that’s when all the fun begins. While it would be great to have a “low latency” subscription model to say “just enter your e-mail address, select the department(s) you want and go,” there are too many bots and folks out there that would want to subscribe somebody else to the list just to annoy somebody. Then the complaint would be written in the local paper (I work for the county government), and things would really get crazy.  As a result, having a simple confirmation e-mail and code (like you see in a lot of subscription services) would need to be put in place, and that wasn’t so bad. We just need to track the codes and write some kind of bot to check an e-mail inbox and have some additional pages to handle those that click the link to confirm/unsubscribe. 

But now we move into the text messaging system. How the heck do you send out messages to ALL of those services?! [Whew, thank you wikipedia, you have a list of SMS e-mail gateways that we can use.] But how are we going to do subscription confirmations over the cell?! We can use the code, but you only get 160 characters in a standard SMS message, and the default code takes up a lot. We then send out messages to about 5 of us, all with different cell phones, and the text message coming in was grossly different for each device. Some had the code in the subject, some didn’t. Even better, two of us had web enabled phones, where they could click a link to activate the subscription, but my little phone isn’t web enabled, so a web link would be pointless for me! Even when the messages came in, I could only see the summary/title, I couldn’t go to a full article.

All of this indicated that our first releae needs to be e-mail based where we have a bit more control over subscriptions and have more flexibility with content link. It also reminded me of a profound truth…simple projects are not so simple a lot of the time when programming. This is also why I love programming so much. Coming up with simple solutions that are also elegant and mucking through all the challenges they throw at you. Consider it the joys of engineer/ninja/artist programming or something. 8^D