...
Implementation Description:
Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
The interface was implemented on top of Django, with user-side UI code making use of jQuery and Bootstrap, as well as a number of UI-related libraries such as LESS to manage CSS styles, X-Editable for in-place editing, and Tablesorter for sorting tables.
Django enforces a model-view-controller-like design strategy, which was mirrored in the Javascript code. Each conceptual function (listing uploads, editing uploads, and reporting plays) was divided into separate JavaScript code and HTML templates for ease of maintenance, with server-side manipulation using separate controller functions ("views" in Django). Django models such as UploadGroups, Albums, and Tracks were mirrored in the JavaScript code with corresponding classes and objects used to help maintain UI consistency by posting events relating to those objects to the window (to allow list entries to dynamically update when the contents of in-place editors are saved, for example), and limited model-specific functionality (such as parsing metadata out of music files) was implemented as model functions.
Javascript functions were largely written as flat functions that strongly depended on the HTML event model to fire them and appropriately chain them to meaningful events to perform relevant actions both in the UI and on the server (e.g. drag & drop, in-place editing of server-side data, and XMLHttpRequest upload events).
Because the code was initially written to map to the existing WMBR music database schema, a number of limitations arose from requirements imposed by Django (such as the requirement of exactly one primary key column, and an inability to use Django's custom column types like FileFields). Some of these issues were resolved by simply migrating to an appropriate object design and backing table, while others were not resolved at this time (e.g. genres are stored as comma-delimited strings rather than as separate models using a join table, which meant that JavaScript code currently splits a string for handling as separate tag buttons).
...