For this project, I made a data visualization to display a history of the chemical spills affecting the Hudson River, and had a lot of fun using the Google Maps API. I originally updated the DOM with jQuery, and later refactored the code into React.js. As for the data, if you go to data.ny.gov, you can find an open JSON feed with all the documented chemical spills in New York. There are hundreds of thousands spills listed, but by including a query to the SODA API, you can narrow this down to only request the spills affecting the Hudson River.
Throughout the project, I faced a variety of challenges, from dealing with unreliable data, to making the map both square and proportional to the screen size, implementing Google Maps in the React lifecycle method componentDidMount(), rather than immediately, and many other issues. The one I’d like to focus on, however, is a simple, clever solution to display the spill markers.
The first thing I had to think about when designing the markers, was how to display the data. I decided that the color would indicate the type of spill: black indicated petroleum; red, hazardous material; and brown would be “other” which was often raw sewage. The size of the marker, on the other hand, would be directly proportional to the number of gallons that spilled. The size and general type were what I was most interested in conveying quickly, and I could include more details in an info element on the side, when the user hovered or clicked on a marker.
It looked pretty good, but when a larger (or equally sized) marker was on top of a smaller one, it would hide the one underneath, and you couldn’t see or click on the hidden spill. By making the marker fill translucent, you could visualize the density of the spills in a specific area through the density of the color, and it clearly exposed the hidden spills. But, there was still an issue of not being able to click on the spills underneath.
First, I decided to find a way to make the smaller spills always stack on top of the bigger spills, so they wouldn’t be buried. Luckily, z-index is one of the parameters in the Google Maps Marker constructor. So, I set the z-index to be 20 minus the marker radius. In effect, the z-index varied from about 15 to -5, and the smaller ones were always on top.
Now the only issue came about when two markers had the same size and location. You might not think this would come up often, but as I mentioned, the data was “unreliable” at times, and there were times when the amount spilled wasn’t listed, and in those cases I used a smallish default size for the marker. Regardless, I decided that if the markers jumped to the bottom of the z-index stack every time you clicked on one, they would expose any buried makers, allowing them to be clicked on next. To do this, I had to keep track of the lowest z-index (I do so in the prototype of the class I created to manage the markers, and their associated data). Then, every time a user clicks a marker, I decrement the “lowest z-index” variable, and update the z-index of the clicked marker to the new value. And voila! It turned out to be a pretty great way to display markers of varying sizes on a map. With a little fiddling, it even works on laptops and mobile devices alike. Try it out for yourself!
For this project, I was tasked with creating a professional website primarily for showcasing the custom made furniture of a local furniture builder. After working with the client to determine the best way to break up the content for the site, the next step was to create a unique feel for the navigation. Making a site totally unique helps it stand out, but it also almost inevitably comes with challenges.
To really personalize it, we decided that the different menu items should be on 3d interlocking pieces of wood, connected by wooden bowties, a woodworking technique my client had employed to repair split wood. He suggested having the menu item rise up from the interlocking bowties when selected. I told him this would probably be possible, but I had no idea how I’d implement it at the time. The problem with this idea is that when one wooden menu item rises up, it should block the front of its connected bowties, but the same bowties should block a different part of the menu item when the tab is not selected. Would it be possible to break the blocks into two parts, one that is behind the bowtie and one in front? Not only would that be difficult to implement, but the woodgrain texture of the elements made it even trickier.
Eventually I thought of a relatively simple solution. I realized if I swapped out the bowtie image with one that was missing the very bottom of the bowtie, it looked like it was being covered up by whatever was underneath it. Then, I added a strip of dark brown to the top of the bowtie that looked like it was the side of the wooden menu-item poking out from behind. Each bowtie was given a class that determined if its adjacent pieces of wood were unselected, or if the left or right menu item or both were selected. That’s four classes total, each with its own associated image. This way the menu item elements appear to be interlocked with the bowties, when in reality, the bowties are placed above the menu items using absolute positioning.
Figuring out how to get the pieces to interlock was, by far, the biggest hurtle. After that, I also had to be sure that to preload all the different images, so there’s no lag when the tabs rise up for the first time. (I used this preloading technique) Secondly, when you have buttons that move on mouse-over, you have to careful. If you mouse over the edge of a button causing it to move off your mouse, it will loop between the selected and unselected states in a glitchy manner. To make sure the mouse area doesn’t change on selection, I increased the size of the element when it’s raised using the before pseudo-selector as follows:
There were many other unique challenges caused by my approach of designing first and figuring out implementation second, but the interlocking element illusion was one of the most fun solutions. And even though there always seems to be more hurtles than you first imagine, I find that it’s always satisfying to not limit yourself to designs you know how to implement.
When I was tasked to create a schedule web-app for a DC DIY music festival (InItTogetherFest 2014), I knew I wanted to make it as dynamic and interactive as possible. A music festival schedule is a perfect example of data that users want to sort and filter different ways. And AngularJS was the perfect framework to provide that kind of functionality.
There are 4 questions a festival-goer might want ask at any point:
1. What are all my choices of bands playing now, or some specific time in the future?
2. Should I stay at a venue for a stretch of time? What are all the bands playing a specific venue?
3. What are all the bands in a specific genre?
4. What do the bands sound like?
To address the first two questions, I used AngularJS’s filters and directives to easily sort the schedule data by either time or venue. To allow you to see all the bands in a specific genre, I assigned an array of descriptive tags to each band. Then, not only did Angular allow me to easily filter the results to a specified tag, but its automatic data-binding made it update in in real-time as a user types a search term. I didn’t have to worry about event handlers or even jQuery for that matter. It was nice to have the logic in the HTML file itself, as opposed to using jQuery to update elements.
The only time using Angular posed a problem was while answering the fourth question of “what do the bands sound like?”. One huge benefit of designing an online music festival schedule, as opposed to a physical handout, is that you can stream music online, and hear exactly what bands sound like. So, I picked a small MP3 player javascript plugin that I could fit inline in each event description. It was very important that the user be able to stream the music as quickly as possible in the schedule listing itself, without having to follow a link that would take you away from the schedule. SoundManager 2’s inline MP3 players were perfect for the job and lightweight to boot. However, using them in Angular was problematic. After a bit of debugging, I eventually realized that the players weren’t playing because SoundManager2 expects the page to be static. When the page loads, it counts the MP3players, and if the count is 0, it won’t bother to listen for any events. Unfortunately, since the MP3players are added dynamically with AngularJS, the count on page load is in fact 0. It was a little annoying to have to go into the plugin’s code and change it to work in an environment where mp3players could be added and removed, but if you want to have a dynamic website, that sort of problem just comes with the territory.
Over all, AngularJS proved to be a very useful and powerful tool, especially for a project like this festival schedule app, and I look forward to using it again in the future.
http://dvdklngr.com/dsApp.html
For this project, I made an interactive animated version of the band, Deleted Scenes’ album artwork. It was used as their landing page. Here’s the original artwork for their album “Lithium Burn” for reference:
I used javascript to turn the art interactive, and relied heavily on the EaselJS libraries. The main challenge here was recreating the effect of cutting up and putting back together the band members’ faces while keeping the performance fast.
Since there are four members, it made sense to have each corner represent a different band member. When the cursor is in a corner, the strips are taken from one band member’s photo, but as it moves closer to the middle, the strips blend all four together, creating the effect seen on the album cover. To give it a handmade feel, each strip has very subtle random x-offset, y-offset, and rotation transformations applied to them.
Originally, I created a new strip with a randomly selected x-position, every tick. But, since it was random, the strips would sometimes pile up on certain x-positions and leave other positions bare. In order to prevent these gaps in the picture from appearing frequently, I had to make the number of strips allowed on screen huge, before finally removing the strip from the strip queue. But managing so many bitmaps on stage ended up hurting performance a lot and ate up the user’s CPU. So after a little thought, I realized the obvious solution was to have a predetermined sequence containing one of each of the positions, and simply shuffle the sequence every time you go through it. That way, the maximum number of strips allowed on stage only had to be twice that of the number of x-positions to prevent gaps from occurring.
The final design challenge was to make it be somewhat intuitive on both a mobile/touchscreen device and a computer with a cursor. On a mobile device there was no clear indication that touching the screen in different positions was changing anything. So, I decided to design a customized “thumbnail cursor” that blended together the members faces in a similar ratio to the likelihood of the next strip being each member. So, if the cursor was all the way in a corner, only one face would show in the thumbnail cursor, and in the middle, the members faces would be blended evenly. I designed the cursor to disappear after a couple seconds and reappear on cursor movement or touch. Additionally, to keep the thumbnail from being covered up by a user’s finger, I offset it to the top right of its location.
Unfortunately, the band broke up shortly after this album came out, and they let their domain expire, but I’ve archived the landing page, so it can live on somewhere.
I made this website for my old band, Frau Eva. It's entirely made in Flash using Action Script 3.0, which was easy to learn as it is almost identical to Java, but with libraries that are more specific to the flash environment. Of all the sites I've made, this one has by far the most unique design.
I like to break up the functionality of art websites into two categories: "important content" and "fun content". Important content are things that someone might come to the site looking for, or things you especially want them to do. In this case, they include the band's music, a listing of upcoming shows, a way to join the mailing list, contact the band, and buy merchandise online. The important content should be easy to find and access, while the rest of the content gives the website depth, creating a world worth exploring for those users who have time to kill.
Luckily, my band had a wealth of content for these hypothetical bored users to discover. We had designed dozens of show flyers, video flyers, band photos, an unusual band bio and some other written thoughts, as well as song lyrics. On top of that, I thought of different visually interactive elements I could add to the site. I wanted this content to be more of a challenge to access than the "important content", so I hid the art, videos, and writing in leaves that fell from the sky. In contrast, all the "important content" is very accessible; the music automatically plays, and is controlled at the bottom of the page, while the other important content is all clearly labeled on dangling signs. Though this "important content" is the only necessary part of the site, most of the site's complexity lies in the weird unnecessary elements.
In all, there are 44 leaves, defined in an external XML file, containing various random content that can be revealed by clicking on the leaf as it falls. The content ranges from impressive animated videos to pretty ordinary show flyers. The only problem with having so much content was that I worried that if I made the leaves totally random, users might click on leaves with less impressive content first, get bored, and stop before discovering the really cool stuff. So, I decided to make a starting line-up of nine leaves to loop through in the beginning. After a leaf was clicked on, instead of looping back to the top of the screen, it would tag itself out and be replaced by the next "coolest" leaf, as ordered in the XML file. Additionally, I designated one leaf to always contain the lyrics to the current song being played.
Besides the leaves, I included other hidden easter eggs that allow users to explore the site if they are feeling curious. Hidden at the top of the page are mysterious labels reading "moon" and "sun". When clicked, they reveal drawings of the two celestial bodies (as well as a star), that also happen to control the visual feel of the entire site. By controlling the opacity and blend mode of an originally transparent layer, the sun controller adds brightness to the Frau Eva site, the moon casts a shadow on the land, and the star makes all the colors inversed/other-worldly. There are other nuanced complexities to the logic of these controllers I won't get into, but I think they perfectly illustrate the hidden charm that can be added with non-essential and relatively non-intuitive elements.
To wrap this up with a happy ending, I will say that all the work I put into making the site unique paid off. It was well received and even got some local press, garnering the headline, "D.C. Band Frau Eva Creates Unique Leafy Digital Portal For its Music." Unfortunately, the band broke up soon after releasing the website, but I'm at least glad we have our music and art documented in an appropriately whimsical online setting. Hopefully the Frau Eva website can serve as proof that breaking boring web conventions and defying expectations can be worth the extra effort.
