Dreamworks: Front and Backend for an In-House Webtool
Background
I worked on this while working as a Python Developer/Technical Resource Administrator at DreamWorks Animation.
The code for this project and screenshots of actual results is proprietary and built for the company, but this case study walks through my process. From identifying the users’ need for a tool, coding the functionality, and testing it out and adding features, I was applying UX Design processes before I was formally taught them.
Understanding the Users and Identifying the Problem
This was a somewhat unique project, because I was building a tool for a very small group of users, of which I was one.
My team was a group of 5 people who were in charge of monitoring the 24/7 render farm at Dreamworks, and we would often get requests and questions throughout the day from artists or other teams within the company. One of our more frequent questions was, “Could you tell me what jobs were running on this host at this time?” Or, “Were there any jobs making really big memory requests on this machine last night?”
And when we would get these questions, we’d have to run a lot of commands in the linux command line, both ssh-ed into the machine and on our own. There was no way we could get the information without doing an epoch time conversion. And sometimes we’d have to dig through the logs of our crons. It was never a hugely difficult task, but it was always tedious and time consuming.
So, as a user in need of a product to help make my job easier, I decided to code a web tool to do the tedium of the task for us.
Developing the Idea
I started out coding the basic functionality in Python. Getting the info was fairly simple to code - I automated all the processes we would use to gather information. Then I focused on getting the information into a format that was human-readable and efficient. I converted the epoch times to human readable, and made sure all the job ids printed out as links to their logs. On my first pass, it only took in a host and a number x and printed out the information for the last x number of jobs that ran on that host.
Then, it was time to build a GUI so that the tool was intuitive and easy to get information from.
I wire-framed out my plan and got to work on the HTML and interactivity of it in Django.
I can’t share actual screenshots of what it looked like, but I’ve included some of the process steps and sketches to the right.
When it was functional, I sent it to my team and asked for their feedback as they began using it.
They enjoyed it and found it made the task a lot easier. But it immediately became clear that I needed to add more functionality - the most important being a way to search within a specific time frame and the ability to search by individual teams.
As I started building out those advanced search capabilities, I also added in user feedback and error-prevention features - I added features like a loading indicator and error response pages, and color coded certain parts of the jobs to make the results more visually clear.
When I got the advanced search working, I sent it to my team again, and we began using it for work.
The output it gave was very easily copy-and-paste-able, often into a shareable Google Sheet. We found that the artists and people we were sending this information to also found it easy to digest, to the level they needed and wanted.
Testing and Iteration
What I Learned and Next Steps
I learned a ton from this project. I hadn’t known Django before starting, and it really forced me to dig into HTML/CSS . It was hugely satisfying to see my tool be immediately useful for the team, and it was great to have automated a process that was such a huge headache before.
The enjoyment I got out of the process of this project was also a big indicator that UX Design was of interest to me. Even in a different job that had nothing to do with the field, I was finding a way to design tools to make life easier for users, no matter how small the user set was.