Last modified Sunday, June 26, 2011 6:48:43 PM
This document provides an overview of some of the web application development work that I have done in the past few years, particularly during my tenure at Stickam Worldwide. Stickam.com, the primary site, allows users to broadcast their own streaming video shows and interact with their viewers both on camera and via text chat. My primary role at the company has been the development of the Flash player client applications that allow the users to broadcast and view live streams on the site, as well as oversee the maintenance of the server side applications that reside on Flash Media Server boxes. With limited resources, this has often meant that I would be largely responsible for taking a general concept and flushing it out, then determining user and technical requirements before building the actual application. In the past year, my role in leading most of the client side development has attributed to my promotion this year to the Team Lead. In my lead role, I have been taking more an active part in product development in addition to my development and managerial duties.
My initial project after starting at Stickam was the development of client applications for a white-label streaming video service that would become StreamAPI.com. The concept for StreamAPI was that it should be a paid service with which users could create their own custom streaming video chat applications which they could then embed on their own site. Since Stickam already supported much of what was needed, I was given the task of creating the editing system which would be used to create the custom players. This system was to be something akin to an Adobe Illustrator type editor that would allow for creating and saving data files that would describe the documents created by the user. I worked with another Flash developer to sync the document requirements with a modification of the existing Stickam chat player and a Java developer who was responsible for the site requirements and the saving and retrieval of the user custom player documents.
The final product supports both vector and bitmap "skinning" of elements, undo history, a simple "windowing" system with notification popups, dialogs, and palettes, a visual way of sorting layered elements (similar to the photoshop layers palette), edge-snapping and element alignment, and image file import.
Figure 1: A basic stream show layout, showing a rollover tooltip for the video element, theme details, and custom watermark. (click to enlarge)
Figure 2: The introduction to the design of the viewer count element, which displays live viewer count information in the player. Note also the element guides that, with edge snapping, allow the user to align elements on the design. (click to enlarge)
Figure 3: Multiple item selection. (click to enlarge)
Figure 4: "Crawling ants" style multiple element selection. Note the reflection of the same selected elements in the Player Components palette, and restriction of the Selection Info palette. (click to enlarge)
Figure 5: Custom eyedropper tool allows the user to match colors used in their player to other colors present in the design. (click to enlarge)
Figure 6: Video settings dialog. This allows the largely to restrict the quality, and bandwidth required by the broadcaster, for the outgoing broadcaster video. (click to enlarge)
Figure 7: The custom vector button editor dialog. This dialog allows the user to create custom vector shaded buttons for use in their custom player. (click to enlarge)
Figure 8: Error dialog with custom message -- the loss of the ability to ping the server results in an error alerting the user that they have lost connection to the server. (click to enlarge)
Figure 9: Shows the ability to toggle visibility in the layered Player Components palette. (click to enlarge)
Figure 10: Host preview. (click to enlarge)
Figure 11: Both host and viewer previews. Note the presence of the "Enter Chat" button for the viewer, since the viewer is required to log in to the text chat for this design. (click to enlarge)
Figure 12: Dialog showing the information that the user can use for embedding the player with the current theme. (click to enlarge)
A few other considerations fall behind the scenes. Because the design editor also allowed for the creation of an image map that would store the bitmap "skin" of a design that would be downloaded by every viewer, a block packing algorithm is used to attempt to make the storage of the image maps more efficient. A testing prototype was built for this purpose to rapidly test various possible image skin sizes.
Figure 13: An example test of the block packing algorithm used in the image map composition.
The Stickam site features several video players, which I have been in the process of updating and maintaining during my employment. The front page player allows users to browse featured video streams on the site as well as featured clients using StreamAPI. The "live streams" page and search page features a very simplified player that displays singular broadcaster (host) streams. The user profile pages can use one of two players -- one is a simple streaming video player that shows only the host's stream, and the other is a fully functional video "chat" application with the host stream, guest video streams, and text chat. In addition, the site also features a more open format "group chat". All players except for the group chat utilize a custom advertising player that supports Adaptv, Tremor Media, and Google IMA video ad technologies. I have been solely responsible for building the advertising module to support the various ad playback technologies and am currently working on final testing for enabling ad revenue sharing using the Google IMA technology, as well as an implementation of the ad module on the group chat player (starting June 27, 2011).
Figure 14: Flowchart demonstrating the flow for the video players, as determined by host's live status, advertising status, user role (the host or a viewer), and others. (click to enlarge)
In mid-late 2010, I was tasked with building the simple video player that can be featured on the user profile pages. This player is a multi-purpose player for displaying the host live stream, showing prerecorded video (via progressive download), showing sets of prerecorded video, and also showing user curated slideshows. Pre-roll video ads are served prior to playback of video content.
Figure 15: Video only player, shown in recorded video mode, playing a 16:9 video. Note the refresh button on the far left for checking to see if the host is live.
As is often the case, the addition of new features often requires the re-adjustment of existing features. One example shown here visits the refactoring of the "caption" functionality in the hosted video chat, which was required due to a change in the chat functionality. A tri-state captioning feature was introduced to make changing the caption easier for the users.
Figure 16: Wireframes for the new tri-state caption dialog.
Figure 17: The new caption dialog in production. (click to enlarge)
Recently, having been promoted to Team Lead for the team responsible for both the server side FMS code and the Flash Player client code, I have been spending more time trying to streamline the way that the team works and focus on setting up build, deployment, and testing processes and conventions. Since the team has been somewhat understaffed historically, deployment of code to dev, staging and production servers (for flash code) has been carried out via ftp and there has never been a very good system for archiving and rollback. I have been working with the systems team and writing scripts to perform simple archiving and deployment of the players and server code to both enable ease of rollback and ease of deployment to multiple system servers. (until we set up a better open-source system) I've also been working with the development team lead to standardize release documentation so that we can better keep up with ongoing changes.
In addition, to facilitate more immediate local testing, I have been putting together a javascript testing script for testing the various players for consistencies and use cases. (Note: it is not very pretty, but it performs the necessary functionality.)
Figure 18: Testing script page. The various elements allow for testing various parameters that change the player use case and allow for viewing both live production streams as well as user pre-recorded media. (click to enlarge)
The testing script allows for testing different users (to test 16:9 vs. 4:3 aspect ratios), different site player designs, advertising technologies, varying sizes (for the players that dynamically resize), and various other player settings.