Ideum’s New Portfolio: Technical Aspects

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.

Considering our strong focus on video and exhibit development Flash was perfect for our portfolio. Things have changed dramatically in the past year, though. Server-side libraries are making client-side programming easy – the limitations of the infamous XMLHttpRequest object are more readily apparent, and mature libraries such as prototype and make programming responsive desktop-like Web applications a breeze. An integration with Flash where we need to show video (like our Fuel Cell Q & A exhibit) fills multimedia voids that HTML/Javascript have yet to deliver. We decided things had advanced enough to make the Ideum portfolio a Web 2.0 application, and to create it we utilized some powerful, freely available software.

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.

Javascript plays an important, albeit relatively transparent role on the site. You’ll notice the “Screen Width” option in the upper right hand corner of the page. We made some adjustments to the standard prototype library to include stylesheet swapping and a few extra DOM functions. At first we determined that the “Screen Width” link would simply route to the javascript function which would swap between two stylesheets, the regular one and a smaller version. After the function was implemented we found that both Windows and Linux would resize the images without anti aliasing. A small script on the server now creates a second set of images, sized (with anti-aliasing) for the smaller screen, and a new routine swaps the image source when the screen width is changed.

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.

ideum-cms.jpgOur 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.

Each piece of data on the page is tagged and aware of its relation to the database. Sound familiar? It’s pretty much the core concept of an ORM (Object-relational mapping system). ORM’s will take a database table, and transform it into a representation native to whatever language you’re programming in. SQLObject (Python), Hibernate (Java), and ActiveRecord (Ruby) are some pretty popular ORM systems for those with interest. To the best of our knowledge we are the first ones to ever create an ORM system that operates via Javascript.

Through a Ruby on Rails layer we’re able to allow Javascript to both pull information from the database, and insert/update the database depending on what changes are made – all via HTML. It’s truly interesting stuff, and allows for the addition of amazing and natural authoring ability to any page we build, while letting the designer maintain styles and certain aspects so the user doesn’t accidentally break the page layout with an edit. We’ll post an introduction to the CMS later this month.

Back To Blog

Recent Posts