View source for Best Technical Achievement (Show Planner)

URY's [[Show Planner]] Technology was entered into the 2013 [[Student Radio Awards]]. It was a successful entry, receiving developers [[Lloyd Wallis]] and [[Andy Durant]] a Silver award.

The feedback was largely positive, and the criticism was constructive and helpful, which was unexpected after the [[Less black and more graphics]] saga of 2012. The feedback was as expected in terms of whether it was the technical side that was actually the problem. However, it is incredibly interesting to see that the biggest obstacle was that commercial radio simply doesn't expect presenters to plan their shows, or the workflows are otherwise completely different to what you get in community radio.

== Feedback ==
*Wow, this seems to be quite an involved project, but I'm a bit at a loss for what it actually does. I'm assuming you use it to create your show logs, scheduling music, planning links etc (equivalent to selector by RCS) - if so, does it do scheduling based on rules etc. or is it purely a case of picking items from a library and adding to a list? I like the fact this can be used outside the studio, as this seems an excellent innovation for students who are rarely away from a computer, and the multi-user angle seems exciting. I'd like to know a bit more about where it actually fits into a presenter or producers workflow though.

* This has a well thought out architecture, overcame problems and improved the station.

* To be honest, the concept of a 'show planner' is slightly alien to me. It is not the way of working we normally use in commercial radio, but it does look like it is a very powerful tool! The fact it is web based and does not require the presenters to be physically in the studio is excellent, and I can imagine extremely useful for a small station with loads of different presenters. Looking at the screen shots, and reading your blurb, I don't really have any idea how it actually works, but it seems very clever! Plus points for getting your presenters to think about their show more than 12 seconds before they go to air!

* This is an excellent way of allowing a whole range of show to get their audio ready for the radio using HTML 5 & J Query as an effective solution to a common problem that many other broadcasters have not mastered. We particularly liked the fact the system has evolved and has been used by a significant number of shows and teams allowing collaboration across shows

* Great tenacity in starting from scratch. Making the layout similar to the playout system to aide workflow is a clever idea. Clear roadmap for the future and feedback suggests that it is being well received and liked by its users. Well done to the team and thank you for your entry!

== Entry ==
The URY Show Planner is an HTML5 web application developed in the 2012-2013 academic year by the URY Computing Team to enable presenters to prepare for their shows in advance from the comfort of their own home (or the library!).

In Summer 2012, URY’s online system for planning shows, written way back in 2003, gave its last breath and we suddenly needed a replacement. The solution that was built over a weekend was simple, but the lessons learned served as a proof of what we could potentially do, given not quite enough time. So this year we went the whole way and redesigned the Show Planner from scratch.

The major issue with the old solution was that it was entirely text based, was very unintuitive and required navigating multiple menus and pages to accomplish simple tasks. This helped provide our biggest design decision: the system should look, feel and act like BAPS, our in-studio playout system. This would reduce the learning curve for presenters to next to nothing, whilst allowing them to experiment with the way BAPS worked, without having to be in the studio. This would also hopefully mean we would be able to one day expand further and use the interface to replace the in-studio one.

Adding tracks to our music library was slow, outdated and prone to user error. We thought that we’d refresh this as well, as well as add “My Beds” and “My Jingles”, two folders of non-music resources unique to each presenter. This needed to convert tracks appropriately, as well as ensure personal folders were not used for storing music.

Our final requirement was that shows with multiple presenters would be able to be collaboratively edited from multiple devices at once. This kind of feature is expected as standard of all modern online systems and we weren’t going to be the exception.

With all this in mind, we dove into the project, opting for HTML5 with jQuery and jQueryUI to provide the best cross-platform experience through a web browser. The backend would be Twig, PHP and PostgreSQL, our standard stack for members’ services. Using these, we created a replica of the BAPS interface with a design that fitted our website branding, and included almost all of the in-studio functionality, with context menus, keyboard shortcuts and a cool drag and drop channel organising system. The only major difference is that the online version doesn’t support multiple sound cards, so all three channels would come out of the client’s main output.

To manage our music library, we continued the drag and drop theme with a dialog box where you simply selected which library you wanted the file to go into and dragged it in. For our main music library, we then use Last.fm to detect the track metadata (we wanted to use MusicBrainz, but it turned out not to be very extensive, or support FreeBSD), before converting it into the formats needed by our systems. For beds, jingles, adverts and other non-music libraries, the user is simply asked for a title and an expiry date. For good measure with our music library, we used the new analysis capabilities to automatically scan our existing library, automatically detecting and fixing minor typographical errors and reporting larger anomalies.

Collaboration was a particularly interesting challenge. Every time any item in any of the channels is moved or change, the server is notified of exactly what events are needed to replay this. It does this itself on the database and also re-transmits these changes to any other client currently editing the show, which also replays the actions to enable multiple real time clients on the same plan.

Our major issue surfaced in the form of storing the information, as the backend database used by BAPS proved to be unable to do a lot of the things we wanted, so we opted for creating an entirely new database schema, with automatic exports from this to the old system to enable presenters to still be able to load their shows.

At the end of the 2012/2013 academic year, the new solution has been made available to all of URY’s presenters, with our committee expected to use it when planning shows. From the start of Autumn 2013, all presenters will be asked to use it when planning any of their shows, an event which we are looking forward to as feedback so far has been very positive. Over 900 shows were created using the Show Planner over the academic year, with over 8000 collaborative changes since that feature was activated in the Summer term. Our music team have said “Now our database detects and adds new music into the system automatically, my show is going to get much more interesting”, whilst a presenter feedback has included “I keep finding new things it can do and new ways I can mix things together. It’s a level of preparation I thought I could only dream of,” and "My show is ready and waiting for me when I sit down in the studio".

A challenge that was discovered late into the development was the format of audio supported by different HTML5 browsers - we needed both MP3 and OGG versions of all of our tracks, which meant re-encoding all of our files. In addition, for special events such as URY’s 40 Hour Show and Roses, presenters requested an ability to break these down further, so we also added the ability to create “blocks” within a show, for a time period within the main show, which can then be delegated to other members.

From this success we have already started work on how we would make this system integrated with the BAPS Server to enable it to control three soundcards and thereby replace our studio playout system.

Figure 1: Show Selection screen. Figure 2: 3-Channel main Show Planner screen, with library search pane. Figure 3: Uploading songs to the central music library.

[[Category: Awards]]
[[Category: Computing]]