Project CREATE

Web application to support HIV prevention in rural parts of the United States by allowing public-health workers to create posters tailored to local demographics.

More information about Project CREATE and screenshots of it in production are on my portfolio page.

(c) 2010, University of Kentucky Department of Communication

Prerequisites

The browser-based poster maker was built in Flash CS3 and has been tested with CS4. It requires Yahoo's Astra Flash Components to build. It also uses as3corelib, though that code is included in the repo.

The server software is built with PHP and backed by a FileMaker Pro database. It requires the FX.php and Savant3 libraries to be installed. See web/inc/README for more information.

Background

The goal of the project was to give public-health workers in rural areas access to HIV and STD prevention materials that were more closely tailored to their local needs than the materials available from national distributors.

The application was created at the request of researchers in the University of Kentucky Department of Communication, collaborating with the Rural Center for AIDS/STD Prevention. I did most of the software development while working for the department's Office of Research and Instructional Technology.

For the initial version the researchers wanted to focus on creating posters that overlaid prevention messages ("taglines") and statistics on a background image. They gave us a short slide deck describing their vision, and we started development based on that.

With the help of another developer, I coded the Flash-based frontend over the summer of 2009. When the pilot was delayed, we built a backend with PHP and Filemaker to store posters as they’re built and let participants order a favorite.

Why Flash?

We wanted the user experience to include immediate feedback, which meant building the poster preview on the client side. A single feature drove many of our technology choices: support for custom messages. We wanted to draw the text onto the poster as the user typed, possibly in a custom typeface and without the user needing to fiddle with the font size.

We considered several approaches, but our choices were limited because many of our target users in rural health departments would be using older versions of Windows and Internet Explorer. We chose Flash because it provided consistent support for the drawing operations we needed across multiple platforms. While some users might not have Flash because of IT restrictions, we thought it would be easier for them to get permission to install a well-known plugin rather than a custom application or Java applet.

One of the drawbacks to this decision is that no one in our department had much experience with Flash or ActionScript before the project. This ended up not being as much of a hinderance as expected (though an experienced Flash developer might disagree after seeing the code).

Adjusting requirements

The poster-maker frontend was completed by the end-of-summer deadline. The pilot was then delayed while the researchers gathered images and other materials to use with it. We used that extra time to improve the backend code to support individual accounts, which let users build multiple posters and review them before deciding which to order.

Before the pilot launched, we were asked to remove the support for custom messages. The agency funding the research was concerned about who would be liable if a user entered a false or misleading statistic and had it printed by the project. We made the feature a compile-time option and left it disabled for the launch.

What's missing

We had several more components planned for the project in case it received funding after the pilot:

• Expand the admin interface to support holding posters for approval, with the hopes of bringing back custom messages. Posters that used only "stock" messages could still go straight to the printer, while customized ones would be queued for review. Users would be warned when using a custom message that it could delay the order.

• Render the actual high-resolution posters and send them a printer. For the pilot, the information needed to make the posters was stored, but there was nothing to export a printer-ready file. We delayed this part because we didn't know what spec to hit and were waiting for the researchers to make contact with a printer. (We actually had one poster printed before the pilot for a presentation but we cheated: I made it in InDesign to match the preview generated by the application.)

• Build a poster-builder builder. The XML format used by the Flash app is very flexible, but not particularly friendly to non-technical users. For the pilot another developer quickly built a system that let researchers create a spreadsheet that coarsely defined a poster template (e.g., place dark red text in lower left). A better solution would give them a graphical interface for placing text boxes and applying effects.

• Remove the Flash dependency. In only a few years browsers have substantially improved support for Canvas and other APIs that would allow us to replace Flash. At the very least, we could move most of the interface to HTML and only use Flash for rendering previews.

• Add targeting flexibility. Currently the three demographic questions and their options are hardcoded.