Thinking About Projects

At Capterra, we wanted to create infographics showcasing software and we wanted news sources as well as companies that were included on the infographics to use these for their own web media – articles and generated content. It was a great content and marketing idea and, spoiler alert, it worked.

I would need to dynamical generate infographics. We wanted company logos and content on a single, image file which should be web-accessible. I would also need to create a workflow for the team to manage various data we would use to construct the infographics in our internal company app. Perhaps a CRUD (create, read/retrieve, update, delete) interface or something else.

The Software Infographic Project

Figuring Out How to Solve the Business Problem

After thinking through the core technical needs to satisfy the business needs by writing out some use cases, generating some workflows, diagramming out how the pieces would fit together, and doing some research, I decided to use the ImageMagick library for creating PNG image files. Each infographic would start from a pre-designed, base image with some artwork provided by our designer – mostly gradient coloring. From there, our content team member should be able to manage content for multiple entries, each highlighting different software at different points in time, like when some application hit the market and started disrupting things, or made some sort of impact in the world.

It was a lot of fun to think about the pixel positions in \(\mathbb{R}^2\), the Cartesian plane, and making sure we were accounting for our upper and lower bounds mathematically. \(\mathbb{R}^2\) consists of two (\(x\) and \(y\)), perpendicular representations of \(\mathbb{R}\), also known as a “line.” So, there’s some minimum and maximum length and width for each infographic we need to work inside of. The maximum length could vary, but the rest were constants. Then all of the other objects included in generating the image file would be dynamically placed along various \(x\) and \(y\) coordinates.

I needed to do things like determine if a set of points were on a line and do some analytic geometry so I could dynamically handle small and large variations in positioning for common content placements as well as multiple entries on the infographic.

Managing the Entries

Each entry would be a company and each entry had images and varying text content. For example bold on some of the text, as well as some merge variables for common text or image inclusions. Then we would need to include some other things like charts and graphs, at mostly common places, but would also move dynamically with the number of companies which we happened to include on a single infographic. The charts and graphs were also images, generated with lots of integer rating values which would be determined by our content team ahead of time. Maybe we’d shoot for ten entries, but this could be eight or it might be fifteen. I needed to work with our designer on this too, so we could figure out how much text we needed for each entry so text and images would fill the space well. This was mostly trial and error and a few calculations given the font size and line spacing along with image sizes.

We also needed to store all this data somewhere, so I needed to create the database schema in our Oracle DB to store text of varying types like descriptions, titles, and urls. This would all need to be managed in our internal company application, so we needed an interface to manage all the content and generating the image files as well as putting them somewhere.

I needed to build out some infrastructure to integrate with our content delivery network (CDN) and store our images somewhere – both the ones we’d use to generate the infographics as well the final infographics themselves. Images used for generation should be protected and private while the final infographics should be publicly available on the web. We had used recently started using AWS for a virtual server (EC2) so I figured it would be nice and easy to store a S3 link to the image files on our end and then just pull it down when we run the service. I remember banging my head against the wall for a while with some funky permissions issues since this was “early days” for AWS and I was new to it. I worked through it and learned a great deal about cloud infrastructure and AWS tools and services in the process.

For a lot of the prep work and a small SPIKE, I used a preset collection of images on my local development environment and wrote a Ruby script to generate the image files using the ImageMagick library. This was going to be the most challenging part of the project given other decisions, so once I was able to generate a proof of concept I was ready to start building out the rest of the tool.

Our internal company application was a standalone, version 4 Ruby on Rails application which had been running on a physical server in a server farm down the street and our Oracle database was running on a Linux server under the desk of my engineering team colleague. We ended up migrating the app over to an AWS virtual server (EC2) and decided to give S3 a try. Our database would continue to be running on a server under my colleague’s desk for a bit longer.

I designed the schema, created all of our database tables, and then started to work on building out a simple interface for our internal tool. The Ruby on Rails framework is really nice as a high-productivity tool for banging out CRUD interfaces so this was a quick process. It had a simple WYSIWIG text editor, image library, and a few other components for entering rating values and creating the graphs. I integrated logging so we could quickly debug issues and placed everything after collaborating a bit with our content team member on workflows. They would be the one using this tool the most initially, so I wanted to make sure they had everything they needed and workflows made sense.

I set up the directories and permissions for our S3 bucket so we could store our images and migrated the business logic from my script into the Rails app so we could trigger the generation workflow from the app and the files would be generated using images stored in a S3 bucket. This also meant these final images needed to be optimized. Since they would be either downloaded to be used by other companies in their content or linked to on web pages directly, they needed to be as small as possible and still look as good as possible. This was simple enough and the step was added to the generative workflow before uploading to S3.

The project ended up a success and we were able to generate a lot of great coverage and links which ultimately drove up our Google rankings. This ultimately helped further the company brand and grow the company.