Flash is a great technology for presenting information to the user in an interesting, fun, functional and predictable way. It’s installed on nearly every internet-capable machine on the planet, and it’s perfect for deploying a rich media-driven experience. Despite its advantages the system has several noticeable drawbacks. Current cross platform support is uneven (although Flash 9 promises support for Linux, Mac, and Windows), textual content is displayed using a flash-specific renderer (native OS/WM text support is more functional, IMHO), and Flash files are impossible for search engines to index.
Re-enter the lingua franca of the Web: HTML. Supported (albeit at different levels) on every Internet-capable machine and utilizing the host system’s native libraries, standard HTML pages are visible to web crawlers, regular surfers, and users requiring special accessibility features. For example, you can link directly or bookmark the Ideum portfolio, or astronomy exhibits, or an individual project like Tour the Solar System. This was simply not possible with our Flash portfolio.
Ruby on rails makes the creation of some remarkable web sites very simple. We learned what Rails was capable of at RailsConf 2006, and decided it was time to give the system a shot. Remember CGI in C++? Validating user input was difficult, buffer overruns were all but avoidable, and actually creating something that looked halfway decent was impossible. When PHP made it’s debut the world (or at least those of us here) breathed a collective sigh of relief. PHP made it possible to quickly take user input and write to the browser. It handled Apache integration for us, and made web programming remarkably easy. Recently things have gotten even better.
If you’ve gotten this far you’ve probably heard of the MVC (Model, view, controller) architecture, as present in Ruby on Rails (and several other frameworks such as Django, CakePHP, and Struts). Instead of grabbing information from the request, looping through that information, and then echoing certain values to the response when the process comes across them, a ‘controller’ (ideally) contains all the application logic, and computed values are sent from it to a ‘view’ – a template that can be designed independently of the controller. Not only does the Ruby on Rails system offer MVC, but it also contains thousands of readily available functions for anything from html sanitizing to file serving. When swapping languages (in this case ActionScript to Ruby), you generally have to re-build your heavily used utility functions. Rails comes with most of what you need, so instead of laboring over input sanitizing and XML parsing, you get started with the real application immediately.
Development of the new portfolio was painless. Database integration, application processing and display is seamless and nearly automatic in rails. We were able to quickly set up a mailing list, a system for sorting portfolio items by category, and several other relatively static pages. Although in future plans, we currently don’t utilize a custom blogging solution. WordPress is a great tool, and we’ve no urgent need to dispose of it and start over. Since the portfolio is integrated with the blog in a number of ways, access to the blog information was essential. Our first attempt was opening a second database connection using the RoR ActiveRecord connection functions. We were successful in opening and querying the WordPress database for recent posts, but after five requests the connection would spontaneously close. This was a MySQL issue on the testing machine, but since one doesn’t always have unobstructed access to MySQL settings we decided to take another approach and simply merged the WordPress and portfolio databases.
Internet Explorer doesn’t like stylesheet changes (or much of anything, really), and refused to re-render the images. We wrote a special case procedure for IE, which sends a request to the server in the background, telling it to send images pre-sized for a specific stylesheet. After forcing a refresh, the new style is applied. As the site neared completion we began to integrate the flash videos, only to realize that we needed a procedure to resize them, as well. Resizing flash videos can be tricky, as the browser tends to cache them immediately. The simple solution? Just copy the HTML from the containing element, set the containing element’s HTML to nothing, and then insert the copied HTML. The browser will refresh the video. The same technique is used during the slide show to prevent and start playback at the appropriate time. Unfortunately, the same problem with image quality appeared with the flash video, and we were forced to resize each one for storage on the server side.
Our custom content management system also witnessed a few core changes during the portfolio build. The CMS is quite simple in concept: 1) track certain collections of components on a web page, and 2) allow those components to contain value maps and react to outside messages. We utilized the CMS in some static sites. The goal in which was to track the changes to the page, strip all unnecessary markup, and save the result to the file which was loaded. The result is an amazingly simple utility which is easily applied to any static page. When it came to utilizing it for the portfolio site we were able to fully explore the opportunities present in what became a very nifty little library.