I started teaching part-time at the College of San Mateo for the Multimedia Department in the Fall of 2000 following my graduation from the Multimedia program the previous Spring. I had previous experience teaching Flash for Learn iT! during the two years previous and CSM’s Flash teacher had departed so there was an opening. It was a great fit as I helped assist in the class during the Spring semester and they knew I could do the job.
At the time, there wasn’t a single great book to teach a class from, so I put together a suggested reading list and started writing my own curriculum. Some weeks I was only slightly ahead of my class preparing their material.
I went on this way for years, regular updates to the ActionScript programming language kept me on my toes. Eventually, I ended up finding a book by Rich Schupe that was pretty close to what I had been teaching.
One of my many responsibilities working at Nom was to port flash-based browser games to a mobile setting. This meant code optimizations, creating the appropriate game flow (menu and score screens along with the ad calls), placing the Nom API hooks, converting click events to touch and removing hover events, and a whole lot of QA on multiple devices.
While working on this game, I developed a reusable template for all the menu and game results screens streamlining efforts for the other developers so they could focus more on the gameplay, only needing to plop in the necessary graphics for the game screens. This template had all the typical Nom API integrations and by using this we cut down QA related issues by quite a lot.
This is a take on the traditional minesweeper, and fun to pick up and play for 5 minutes.
In 2012 I spent a year leading a team of developers building casual games for mobile. I contributed at all levels of this effort, building games, offering technical support, working with the developers to optimize gameplay, managing timelines, and ensuring all the platform integrations worked seamlessly.
When I started with Nom, it was primarily focused on Android, but once Flash was able to be ported to iOS, I spearheaded porting existing titles to the Apple Store. It was a little tricky, and very new at the time (These games were targeted to iPhone 3, 4, 4s, and 5 along with the iPad 2).
When I started at Nom, the companies focus was on developing a large user base. Having a large user base was at the time the key to getting a future round of funding. Unfortunately, that year was not great for game companies, and many didn’t survive. Nom ran amazingly lean, it had a decently long runway and had a very small burn rate. Once it became apparent that any future funding might not happen, we turned our efforts to making revenue through advertising. This meant going back through our entire catalog of 50+ games and adding in the advertising calls to appropriate places in the game-flow.
The advertising revenue worked out really well, but we implemented it just a little too late. I was told as we were winding down the company that if we had started 6 weeks earlier that we would have hit a cash-flow positive state by the time the existing funding ran out. By that time the founders had settled on a new idea and were already starting a kickstarter for it.
Nom sold their Nom.com domain name and all the games were moved over to mekalabo.com. There are a number of games that aren’t available any longer simply because apps need updating because of Operating System changes.
Have a look at the games I worked on from the links below.
Transitioning to Flashtalking’s Creative Manager – August 2016
During the summer of 2016 working on the Studio team, we were working hard on transitioning clients from the older Creative Interface to the newer Creative Manager. There were some differences in workflow, one of the major ones was starting a new Creative Library and uploading your first files. I created this short video in order to quickly address client concerns that were coming up in e-mails on a regular basis.
We could send this out and follow up with the client if they needed more assistance. Ideally, it was better to address concerns individually, but this allowed us to respond quickly, giving us time to set up a screen share if necessary, not wasting everyone’s time trying to pick a moment.
Creating a State Call in the Flashtalking API – August 2017
One of my responsibilities at Flashtlaking was to dig into some less used parts of the API and make them easier to utilize by surfacing a typical workflow and documenting necessary details to make the experience less daunting. When you don’t use something regularly and don’t have friendly documentation that tells a good story of its workflow – you typically don’t want to be the point person supporting this effort. My job was to figure out what that workflow would be and tell a compelling story of how and when you would want to use it. The State Call was one of those things.
Occasionally a client would need to track more detailed information from an ad, like if it were using some kind of geo-targeting to pass along a users zip code or general location. Or maybe we wanted to track what SKU product numbers were visible in a carousel and which item was clicked on by a user. In order to do this, we had to log that data as a string to a service that would pick it up and parse it into a report.
It was vital that the string and the actions were very specific and well tested before rolling it out live. Also, it was hard to test this without getting multiple team members involved (who often didn’t have the time), so any and all testing before bringing them in was imperative.
In the presentation notes and video below, I cover the details of this setup and how to test without being scared of this whole process. My job was to make this type of thing feel achievable by anyone.
One of the larger clients I supported at Flashtalking was Hulu. Hulu had an interesting setup as they wanted to create video ads but as they have a fairly robust CDN they wanted to save a little money and use their own network to stream the videos, but through the Flashtalking player in order to get important metrics. Typically this wasn’t allowed through the API, but we found a workaround.
In the time I was supporting this effort with various agencies building ads for Hulu, Flashtalking transitioned their tool for uploading and managing creative files from an older Flash-based system called the Creative Interface to a more modern HTML 5 tool called the Creative Manager. Along with this transition came some changes to the way the ads were set up. Below you can see the documentation I put together along with a screen share video I created showing the changes.
Flashtalking Studio Training – January 2016 – January 2018
Learning an ad-server’s API isn’t hard, just detailed. Creating a compelling story leaving customers with a “can do” attitude creates better results leaving all parties happy.
One of my responsibilities joining the Studio and Support team was to conduct training sessions with clients new to using the Flashtalking API. Ad Server API’s aren’t that difficult to implement, but they are detailed. With only an hour to cover all the basic integration points and the basic developer workflow from ad creation to QA and client approval, it can be tough to conduct a training session that doesn’t overwhelm the participant with details.
Typically one of these training sessions would be a rapid-fire barrage of facts referencing some minimal documentation which was in need of some love. Following a training, it was our job to answer questions through e-mail about details forgotten or missed. Depending on the client, this could end up being quite a bit of extra work.
One of the first things I did was try to get the documentation updated, which proved to be more of a long-term project. Instead, I turned my focus to developing my own support documentation that was shared before a training session. This document covered in detail the typical training session, could be quickly customized to suit the client, and easily expanded to cross-reference other supporting documents.
When the training screen share was scheduled, included on the invitation was a link to a public-facing Evernote document with detailed notes with starter files and screen captures of everything covered. We recorded the screen share and sent a link to the video in a follow-up e-mail along with links to any documents supporting questions that arose during the training session. With the detailed notes and screen share in hand, we created a level of comfort with the Flashtalking API giving our customers a “can do” attitude cutting down on unnecessary communication that ends up wasting everyone’s time.
Expedia wanted to develop a larger audience on Facebook. Starting with a few thousand fans, they launched a contest leading up to the summer travel season with the goal to gain 1 million new fans. We accomplished this in 6 weeks with a well planned viral contest and targeted ad buys.
The contest allowed someone to enter (once they liked the Expedia page – gaining a fan). They could then enter 6 of their friends to take a dream vacation with them, these users then could enter their own trips with 6 of their friends. Users could decorate their own plane (with my flash-based application) and our Ruby on Rails application to save that data and display it for that particular user showing which of their friends had accepted. We set up the invitations to customize user profiles in the window of that custom plane.
The Facebook application not only got some of the highest traffic our company had seen to date but also working with the company who purchased the ad buys resulted in Efficient Frontier buying Context Optional, later selling the new company to Adobe which became Adobe Social.
Facebook Application for Toyota Prius – August 2009
My first project with Context optional. I built the Flash-based visualization (rainbow graph) and the bar chart visualization (lower right) to take JSON data retrieved from a Ruby on Rails application and create the rainbow display based on the number of random acts pledged, varying the width of each bar to reflect the popularity of the individual ‘random acts of kindness’. The bar chart in the lower right corner also reflected this information in a more generic way.
I have long neglected my portfolio. In the last four and a half years with my former employer, it wasn’t something that was a priority for me, unfortunately.
During that time, some nefarious entity gained access to my codyo.com domain and got me listed on Google’s unsafe site list. That was a surprise. Apparently, there was some exploit in an old version of WordPress I had installed that allowed them to gain a surprising amount of access.
As I started this new chapter in my hunt for a new position, this wasn’t something I wanted to deal with. But it’s time for new beginnings.
I removed everything under my domain, checked with my web host to make sure it was clean, got Google to clear me (after a little back and forth), and now I’m starting things here fresh again.
I’m now starting to reassemble older portfolio pieces and should have more here soon.