Richlinks are one of the many features I built as part of the editor team at Evernote.

Richlinks are special content blocks that represent a linked external object but are presented inside the note as rich, interactive content. For example, a YouTube richlink is semantically the same as a text link pointing to a YouTube video, but with a richlink the user can view the external video inline.

During my time at Evernote, we went from richlinks being static images representing Google Drive docs to a set of interactive blocks that allowed YouTube video playback, viewing Google Drive file data, and embedding content from other Evernote notes.

This was a huge challenge because when I joined the team, the editor framework could not handle nested iframe documents without significant risk of data loss and editor instability. So a big part of developing this functionality was getting a handle on our fundamental editor architecture, data loss mitigation, and process controls for regressions.

After rebuiling many of our core editor systems and addressing issues with regressions, we were able to find ways to expand richlink functionality to include additional providers and additional modes of interaction. Today, richlink logic represents a stable foundation on which Evernote will be able to dramatically extend the interactivity of note content in the future with minimal incremental risk or complexity.

Since my time at IBM, Bluemix has been rebranded to "IBM Cloud" and I have no way of knowing if the rebranded versions of these pages are running on the same microservice I wrote or not.

One of my first projects at IBM was creating a new "Maintenance" microservice for Bluemix that could reliably render pages with simple messages such as "down for maintenance", 4xx errors, 5xx errors, etc.

The previous implementation was heavy and slow, requiring many unnecessary round-trip HTTP calls for heavy assets, which could be quite problematic during maintenance periods, when the microservice would bear significantly increased request load.

I simplified and revised the code, removing all dependencies and features that were not strictly necessary. I then added comprehensive tests to ensure reliable operation in production. The previous solution had used heavy client-side JavaScript to handle translation and other external assets, which delayed error page requests by entire seconds.

I instead decided to translate the messages server-side, embed all assets and styles in the HTML document, and remove all client-side JavaScript. The design was also updated with a series of quirky robot illustrations, which was part of the IBM Bluemix branding at the time.

Since my time at IBM, Bluemix has been rebranded to "IBM Cloud". The URLs and styling have changed a bit to match the new branding, but the general layout and functionality of the API Docs framework that I built and helped design is still intact in 2023.

The Bluemix API Docs project was created to provide Bluemix-affiliated service teams with a standardized and validated user experience for their API Documentation. It was later merged with the related "Papillon" API Catalog project, with API Catalog ultimately providing the backend and Bluemix API Docs defining the new frontend experience.

The solution began as a simple documentation page based on data definitions in the Open API (fka Swagger) format, because that was a format nearly all service teams were comfortable working with. We continued to refine the user experience and add on additional features such as sample code generation, Bluemix-related metadata, endpoint groupings, human-readable comments, etc.

During the active experimentation phase, I was the only developer—both backend and frontend—and I actively collaborated with one designer. Later on, additional team members were brought on and the microservice was integrated into existing infrastructure from other service teams. Even though the styles have changed a bit over time, the overall structure that we arrived at through iteration and experimentation is still evident today.

At BancVue (now known as Kasasa) I built out dozens of sites for various financial institutions. Roughly every two weeks I would build out a new site while reviewing designs for upcoming builds, then move on to the next build. This is an example of one such site build.

The design for Destinations CU had interesting use of color where each section had a different color scheme, which SCSS helped solve without code duplication. This site also shows some early indications of my focus on motion. Since I finished the primary build with several days to spare, I worked with the designer and client to add a few touches of animated transitions.

I have not been involved with content updates or modifications since the site launched in 2013, and the site has since been completely redesigned. The partially-archived version linked below is a decent representation of the site layout, but it may have some missing images, broken links, etc.

Ludum Dare is one of my favorite events. It is a game jam (similar to a hackathon) where participants create a game from scratch in a short amount of time. Ludum Dare happens once every 4 months, with thousands of new entries each time.

For Ludum Dare, participants create all assets, design, art, code, music, etc for an original game (based on a shared theme) in one weekend. Solo participants have 48 hours and must create all assets from scratch, while group participants have 72 hours and fewer asset restrictions. I used to participate in the solo competition more frequently, but in recent years I have mostly been helping friends with music or art for their projects.

I love the Ludum Dare event because I always learn something new. There is valuable experience to be gained in the practice of completing a project—no matter how small the scope. I leave each competition feeling creatively rejuvinated, ready to tackle even more ambitious creative and technical challenges.

Note: All of these games have music, so you may wish to adjust the volume on your computer before playing. You will need a keyboard in order to play most of these games. Additionally, the games from LD30 and LD32 also require Flash to play.

WebGL is becoming increasingly attractive as a technology for engaging web users in unique ways. As I see more and more sites taking advantage of the technology, I am driven to learn and experiment with it more and more.

Here is a collection of WebGL shader experiments I have created on CodePen in order to explore concepts/techniques and to attempt to recreate interesting effects I see on websites.

Note: These experiments have not been optimized, so they may run somewhat inefficiently, especially on mobile devices.

SVG is an interesting format that can be used to allow for a unique combination of accessibility, technical flexibility, and visual interest.

Here is a selection of CodePen demos involving SVGs, ranging from very simple static visual effects to dynamic animations.

I have a bit of a strange interest in different image formats, including SVG, so I'm always open to a discussion about exploring new ways to put images to use on the Web.

Here is a collection of miscellaneous public demos I have created on CodePen over several years. I often use CodePen privately to experiment with ideas or reproduce bugs I'm working on, and sometimes I create a more polished public demo to share a technique or just for fun.

The first few examples here are more practical demos, tools, and technique breakdowns. The last few links are just for fun.