about
The Project
In March of 2013, Videojuicer decided that it needed to unify its offering to its customers into a single easy to use application. It had disjoined and sometimes manual workflows, to allow its clients to get the most out of their platforms features it was decided that a single but easy to use application would allow the business to grow. I was brought back on board to support the lead developer in building an application that met these new requirements.
My roles included adding new features to the player, some to add functionality that was missing, and others to allow integration with the new platform.
I would also need to build a way for the platform to talk to one of the other key parts of the Videojuicer offering that was not going to get rebuilt.
The last and properly the largest responsibility is given to me was to design and build a way for Videojuicer’s unique in player apps to be configured from within the platform. Until now this was a very manual process that had to be carried out by a developer, or someone with experience in building JSON based configuration files.
The Challenges
One of the biggest challenges is dealing with code that already exists; this is because you have to get into the head of the developer the original created it to understand what they were trying to do and why they made the design choices they did.
The most important and already existing code was the Videojuicer JS (AKA HTML5) player. This was because it already contains a large amount of complex code to handle the revolutionary in-player apps that are unique to Videojuicer. The other reason was that the player is a key piece of software and is mission critical to the Videojuicer offering. Therefore it any changes made to the player could A) not break it and B) not affect its performance. This meant that all design decisions concerning the player had to be made keeping performance and stability in mind.
The other big challenge I faced personally was that the new platform had been authored in Java, a language that I had very little knowledge of. This would mean that I would need to get up to speed with at least the language basics and also its workflows and toolchains. Growing my understanding of Java would be key in such a small team, as when others were on vacation, I would need to be able to diagnose and solve any issues that arise.
As with most projects that are rebuilding, refactors or redesigns Videojuicer had a current client list that had to be maintained and migrated to the new platform.
The last challenge that we faced as a team was that the business needed delivery of the new platform as soon as physically possible. This meant that we had to work with speed in mind, design decisions had to consider their time implication.
Skills used
One of the most important skills in this project was time management. This is an important skill in any project but due to the time constraints, it was vital to this project. We were also working as a remote team; this meant that time management was very much a personal thing. I had to remain disciplined and able to work on my own. The developers stayed in constant contact using Hipchat as well as the project management tool Atlassian Jira. We also stayed in contact with the business using the Skype platform.
I had to draw on all my UX skills to design features that were easy to use. This was a focus of this project to build a platform that was easier to use than the previous offering. This involved researching similar platforms such as Vimeo, Brightcove, and of course the mighty video platform Youtube. It also involved using both the internet and traditional media to understand UX and UI best practises, such resources that become very useful where sites like Creative Blog and Smashing Magazine.
Development mainly took place in Javascript, as I was working with a lot of front-end elements. In the platform side, the Javascript requirements were relatively loose, but the player had very specific requirements around performance and size. The player had to remain small so that it could boot quickly and use very few libraries so that the code performed faster, was smaller and could work anywhere. This meant that I had to dig deep into my pure JS knowledge, although jQuery was present it could not be used unless it was needed. This was because of the performance related issues over using pure JS
Backend development for me involved mainly Ruby as that is where my main focus is. This wasn’t application development as that was to be done in Java, but tool development. Videojuicer already had systems that it could not dispose of easily and quickly. These systems need to be integrated into the new platform and the new application this involved building tools and services that could bridge the gap between the Java environment that we were using now and the previous environment. It was decided that it would be quicker, and more efficient if these new bridging services were created using Ruby.
I did become familiar with Java workflows and Toolchains, including using Maven, Eclipse and IntelliJ. I also become familiar enough with the Java language that I could understand the codebase been created for the backend of the application. As well as the Mustache templating language been used.
Work
Unify the Company Offering
This for me was mainly a research excise, I had to understand what the company already had in play. Although I was rejoining the company the new role was very different to the previous one. The new role involved working with the core platform, whereas previously I had mainly been doing integration work and building solutions for clients.
This meant when building new features we had to consider what we had already and what we wanted to keep, what we HAD to keep and what we could throw away. These decisions normally involved both the development team and the business team, in order to get the best understanding of the implications of any design decisions. This was mainly because we couldn’t afford to loose the current client base and so didn’t want to cut features that clients had come to depend on.
I then worked with the lead developer in order to refine both the architectural and visual design of the application.
Add new features to the player
The player is the core of the Videojuicer platform , it contains a lot of the logic needed to make the companies offerings work. It also is the most customer facing part of the platform. Most of the end users will never see the the actual platform or website but rather the embedded player.
The player is the core of the Videojuicer platform; it contains a lot of the logic needed to make the companies offerings work. It also is the most customer-facing part of the platform. Most of the end users will never see the-the actual platform or website but rather the embedded player. This means that any platform changes are likely to affect the player in some way. It also means that the player is the MOST important part of the application stack and so cannot be adversely affected by any changes.
I had to alter the player to include new ways of interacting with the new platforms configuration format. It was also missing some features of the previous generation player that had to be added so that clients could be migrated to the new player without causing any loss of functionality. The player makes use of a lot of very pure Javascript, this is because using libraries may cause performance issues (see The Challenges). I, therefore, had to make sure that I didn’t add anything to the player that may cause even small delays in its boot up or functionality. These delays could cause users and clients to avoid the platform altogether.
One of the most interesting aspects was implementing a post message API so that the containing page could communicate and control the player which was embedded ver an iFrame. This was interesting because it was a new technology to me, having not previously used the post message API. It also meant I had to create a tool in order to test the players API.
Part of Videojuicer’s core offering is its in-player apps, these run in a backend custom JS environment and communicate with the player over the wire using multiple methods such as WebSockets, HTTP and AMF. This service already excited in the Videojuicer infrastructure (written in the Scala language). Due to the time constraints and the fact that the code was working perfectly well, it was decided that this service would not be integrated into the new platform directly, rather would remain a discreet service.
This design decision meant that a bridge had to be built between the platform and the app server. The bridge would allow the platform to install and manage apps running in the app servers JS environment.
I was the product owner for the Addons so this responsibility fell to me. I choose to build a small Ruby app, as that's where my expertise lay and with time constraints it would be faster for me to write a ruby application rather than a Java one.
The service made heavy use of Amazon Web Services (AWS), especially services such as the Simple Queuing Service (SQS), the Simple Notification Service (SQS) and the Simple Storage Service (S3). I built the application on top of the AWS Ruby SDK as this already includes an easy to use API to all the above services.
Design and Build a UI for configuration of apps
This was properly the most complex area that I had to work with. Not so much technically, though it did have some technical challenges in building functionality such a Dragging and Drag and Drop. The main challenge was, however, a design challenge. Videojuicer did have a basic app configuring application that it had built previously but that involved a lot of custom work based on the app. This meant that it was slow for Videojuicer developers to roll out a new app, as well as impossible for a third party to do it. Although Third-party app integration, i.e. apps that were developed by someone outside Videojuicer, was a future consideration. We felt that it was important to consider it in the design decisions now because this would make it easier to integrate in the future. We also wanted to add the ability for the end user to decide the position in space of there in player apps.
This meant that we were basically starting from scratch building a complex UI that could allow users to both position apps, and configure app variables. It had to be easy to use, able to be implemented and controlled by a third party app developer and flexible enough that any application could be used with it. This meant that as a development team we spend the time to decide on the best way forward, what was the best end user experience, and also what was quickest to build.
The biggest technical challenges came from making the application both flexible (it had to cope with being used in many different ways, as well as adapt for the app been configured) and stable. This meant a lot of end-user testing to get all the bugs ironed out.