Digital Portfolio

This is one of a few projects that I revisited once the client-side version of the our newest ticket inventory API came out.

Since I was already rebuilding it, I decided it was a good time to try to expand the customization options such that a person could create a whole site around it.

This created a new problem is that there were so many customizations that it was overwhelming and the preview was pushed out of view. It was a UX mess.

I reached out to a coworker, a graphic designer, and together we came up with a format where the customizations were split into steps to create visual bite-size chunks. Condensing the options like this also allowed us to expand the size of the preview and bring it front and center.

This widget builder was based on the ones I had made for affiliates. One of our business directors asked if I could extend the functionality so that our clients could build widgets to put on their non-retail sites (like blogs) to direct traffic to their white label sites.

When the client-side version of our ticket inventory API was released, it allow me to update this widget with search suggestions, a feature that had been sorely lacking.

This was a feature present in the creative director's mockups for the version of TicketLiquidator I was developing (that would become the new TicknetNetwork instead).

I couldn't get the user's location client-side without causing the dreaded geolocation popup, so instead I took advantage of the fact that the CMS stored the user's location as a cookie.

Since this was a feature on the global sidebar, there was one other thing to consider. As the user progressed through the site, the call would be made on each new page, regardless of whether the location changed or not.

As a fix for this, when the call is first made, the venues it returns and the user location are stored in local storage. Then, whenever a subsequent call would be made, it checks to see if the location in the cookie matches the location in local storage first. If it does match, it re-uses the venues in local storage and skips making the call.

One of the dilemmas for ticket retail sites is how to keep content up-to-date. Things like 'featured events' or 'popular performers' should be regularly updated based on whats on tour and what's selling well. The problem arises in the how - curation from a content team, which costs in man(or woman)-hours or auto-generated, which costs in pageload time.

For the newest site I was building, TicketNetwork.com, the navigation dropdowns utilized top seller lists for each non-sport category (almost a dozen) and top-level category pages have 3-4 top seller lists for sub-categories.

Since that was both too much for a content team to reasonably update and would cost too much load time, I devised this tool as a compromise.

To go along with this, I created a document of where the lists were on the site and what category they currently were for, standardized the HTML structure between those two varieties (navigation dropdown, category page) so that the tool could generate the full HTML, and demarcated the replacement spots with comments.

One of the requested features from the retail team for TicketNetwork.com was to have a dynamic page that displays results based on ID's rather than names to serve as a landing page for their email marketing.

Since the CMS had no such functionality, I needed to built it. The page I created made use of our ticket inventory API which had just been updated to allow client-side access. It's able to generate results from ID's for performers, venues, cities, states, categories and any combination thereof.

The page has some notable features I built into it. First, it allows the user to filter the results by date, performer, city, and venue. These filters are context sensitive so that a filter that would not make sense (like city for venue results) and filters that only have a single option are not shown. Applying a filter creates a 'filter tag' so that the user can see what filters are active, and the filters that are shown are updated to reflect the new results.

In addition to simple things like updating the heading and subheading to match the results, there's some more robust situational content. If a performer ID is generated, a performer image will generate, if a venue, a venue image along with venue info and an embedded google map.

Lastly, if there are no results, a modal will appear suggesting related pages for the user to try instead

This was part of a project to improve the sites of clients who had strong domains (redsoxtickets.com) to capitalize on their organic traffic.

The ticket results we had to work with at the time allowed for very little customization, they were directly written to the page by doc.write as a table element.

To make the results more befitting a site for a specific team, I devised some JavaScript that would iterate through that table and tag each event as either home or away depending on what venue it was it. Then I put tabs at the top of the results table that show/hide events based on those tags.

Note: The SSL on this site has expired so you will receive a security warning.

One of the common requests we received was for filters for our 'event results' plugin. The plugin is a simple JavaScript endpoint that outputs to the page using document.write on page load. Because of this, the only way to add filtering parameters to the plugin call was to re-load the page entirely.

As a workaround, I wrote some JavaScript that iterates through the results and adds classes to them based on what the site owner would like to filter by. During this iteration, each new instance of this parameter is stored in an array and any repeats are tallied. This is then appended to HTML on the page to create the actual filter interface.

The simple corresponding classes between the result and filter checkbox didn't work for dates, however. Instead I had the date converted to a number - yyyymmdd - and stored as a data attribute (since classes have to start with a letter). With the dates formatted as numbers, the filter can simply check whether the result"s data attribute is greater than or less than the requested dates.

One of the biggest challenges with ticketing sites is the desire to use images to advertise events without needing to constantly curate the events to keep them up-to-date.

This code takes advantage of NewYorkTheaterTickets being a Broadway specific site since there are a limited set of ongoing Broadway shows, and each show is specific to one theater.

The code takes the data from an 'Event Results' plugin specific for the upcoming week (pictured top left) and arranges it into Event-Venue cards with available showings in the next 7 days. The image is pulled from a collection of Broadway show images kept on AWS S3. The only time an update needs to be made is when a new Broadway show debuts and a image needs to be added for it.

Our company utilizes a licensed third-party CMS to provide pre-built template sites for ticket brokers and marketers. Recently our CEO reviewed the default appearance and was disappointed that the sites looked dated and that the template options didn't provide meaningful enough differentiation.

I was asked to create a new template that addressed these issues which would then be passed on to the CMS developer to implement as the new default.

I built this site on top of the existing template and implemented a quick and dirty configuration menu on it to demonstrate what options we wanted added to the CMS and how they would interact with the template's layout.

Rather than represent the home page in the images, I'm specifically showing and linking to the Octane page to demonstrate the flipping card mechanic I implemented on that page.

Made for the NewYorkTheaterTickets site, this code takes the data from an 'event results' plugin (pictured top left) and maps it to a jQuery UI calendar.