We tend not to think of UX as a technical field - a softer set of skills than software engineering. There’s some truth to that - in traditional UX roles, we seek out interactions with users. We try to understand what they want and how they feel. True, UX can involve poring over analytics - understanding bounce rates and conversions, but these are poor substitutes for the interview and usability test.
However, the technical side of a website plays an integral role in the user’s experience, and cannot be overlooked.
Crimson Hexagon is a social media analytics company in Boston that deals mainly in Twitter data. They hired me primarily as a designer. I had some significant experience with HTML and CSS, and had even built some simple PHP/MySQL web applications, but I was hardly an engineer. They had a redesign of their customer dashboard almost ready to go and I was tasked to help finish it as part of a larger team of developers.
Because of some personnel changes, I had to take over the role of front-end developer. It was a challenge - I’d not spent much time working with frameworks or complex web applications. (Obligatory shout-out to the Freemarker Java templating language)
Scale was one of the primary challenges on the dashboard. Customers built tools called monitors which allowed them to track items of interest across social media. But for the purpose of this story, they’re just widgets. Some customers had 5 or 10 widgets, others had hundreds. For the former, easy - you display them all on the dashboard and you’re done. For the latter, it’s a more complicated ask - what tools do you build for finding a particular widget? How can a customer see them at a glance?
Pagination is obviously an option - but it makes browsing more onerous, and often you incur a load time to advance to the next page of results. Not ideal. Alright - so we want to display all the results at once, but make searching and filtering easier. The issue there quickly became page load times, and the performance of the search functions. The best searches start to show you results before you’ve finished typing. This typically means that you’re filtering and revising your results a few times before the user is done. It worked great in small scales, but was atrociously slow for customers with 100+ widgets. We isolated the problem to the front end. I wanted to know why, so I started researching how browsers actually work.
Fun fact - this may come in handy in a survival situation - if you’re trying to calm a shark, flip it over onto its back and rub its belly - or start talking to it about the Document Object Model. This also works for marketers. Maybe cats.
Browsers display web pages in different stages: construction, layout, and paint. The TL;DR of it is that each time anything changes, the page gets redrawn. A poor solution: if you’re looping through n widgets and deciding whether each one should be shown or hidden based on your filter parameters, you are redrawing the page n times. This is a problem when n is a large number. A better solution: you’re looping through n widgets, but you start by hiding all of them and then deciding which ones will be shown or hidden at the end, and then you show all of the correct ones. You’ve redrawn the page twice - once to hide everything, and once to show the correct widgets. Suddenly n doesn’t matter so much. We made the change, and the page load and search times improved tenfold or better for customers with a lot of widgets.
It was a better experience - but the way there was by looking under the hood and optimizing what we already had.
I worked with Rob very closely for several months at Crimson Hexagon. He is by far the most talented UI/UX Designer I've ever worked with, and an expert in modern web standards (HTML5, CSS3, SVG, &c.), software tools (Adobe Creative Suite), and data visualizations. He also is a very talented artist, with a keen creative eye that helps his design work immensely, and is a friendly, professional coworker. I cannot recommend him more highly.