During the interaction design phase, we determined that Netflix’s current drag and drop reordering feature was well thought out — so we set out to create the same reordering behavior in Queued. As Revin mentioned before, we also wanted to keep Queued as light as possible; because of this, we decided early on to not use any of the Dijit infrastructure to create the queue listings. Not only that, but the Dojo Grid would not work for the queues because it doesn’t support drag and drop reordering of rows. This meant we would have to come up with something which would be flexible (yet fast) to render the queue.
In the user interface design phase, we decided that each of the lists in the “Your Queue” section would be based on HTML tables. In Queued, only the DVD queue and the Instant list can be reordered, so we’ll focus on the DVD queue.
In Part I of Queued and AIR issues, I talked about some of the challenges we faced during the development of Queued, our AIR application that allows you to manage your Netflix queues. In this post, I’ll discuss five other issues we ran across.
As part of our series on how we built Queued, today we’re going to talk about theming the Queued application, and touch on a few examples of what made putting the skin on Queued so much fun.
The foundation for the beautiful theme for Queued was laid down by colleagues Damon Dimmick and Torrey Rice, and their amazing wireframe and mockup work (respectively) provided the building blocks for laying down Queued’s skin.
During the course of developing Queued, we ran across a number of challenges developing with AIR that we needed to solve. Some were very difficult to get around, while others were the result of our team needing to think outside the web-based paradigm. In this post, I’ll talk about four issues we ran across that ended up shaping part of the Queued codebase.
At SitePen, we work very hard to to provide our customers and fellow developers with useful web app development services. We’re currently deconstructing the development of Queued, our Netflix Queue management application built with Dojo and Adobe AIR. Having presented on dojo.deferred and related topics at the Ajax Experience, and having heard that the Queued team ran into a few problems with them, I thought it would be interesting to review problems that are sometimes encountered when using Deferreds. What is the source of these problems, are these problems related to bugs or because there are misunderstandings, and how should we address this going forward?
Dojo is a very flexible toolkit; it doesn’t dictate how you organize your code or create your widgets. It simply provides tools, and it’s up to you to decide how you want to fit them together. Developing with AIR puts you squarely in the browser-based application model, but aside from that it mostly stays out of your way as well. As part of our series on the Queued development process, I’m going to take a look at the decisions we made and the philosophies we adopted for the project. It should provide some insight into our process.
As with every SitePen project, we started out Queued with a set of written requirements that defined what the app should do. From that set of requirements, the design team began to define common user goals and create wireframes that detailed how the user would achieve these goals.
We created a set of wireframes for every screen in the app and then the visual fun began. What should it look like?
SitePen’s new Queued application works very well with the Netflix API, but the smoothness of this functionality was the result of a lot of research, and trial and error. In fact, this experience led me to propose that future project timelines should budget extra time when working with an unfamiliar API—and even more time when that API is brand new and untested. Netflix released one of the more exciting APIs in recent months and SitePen began to work with it right away. The Netflix team did great work on their API and they were also very helpful with us when we had questions or there was a bug on their end. I can imagine the challenges of setting up a (Netflix) REST API with an existing system and a large and complex library of items was not simple. Integration with the Netflix API presented its own set of challenges to us.
Sometimes building an application from scratch is easier than building on an already existing interaction model. For Queued, our goal was to take the Netflix user experience and port it to a lightweight desktop application, while adding some modest enhancements.
Creating an alternate interface for an already well-known web site carries some unique responsibilities. First, unless there is something seriously wrong with the original site, straying too far from the established model can be counterproductive. Second, innovating on existing features becomes more important than replacing them. And third, adding new interface functionality without obstructing existing interactions remains a crucial consideration.
For the Queued project, SitePen faced the additional challenge of showing off features of Adobe AIR that might not necessarily lead to the most fluid interaction, but which were powerful enough to merit inclusion as a demonstration of AIR’s powerful capabilities. We’ll discuss a few of our interaction changes here, though these aren’t the only modifications that we decided to implement.
Last month, we announced Queued, an open-source application for managing your Netflix Queue. Queued is a desktop application created with web technologies and techniques including the Dojo Toolkit, and it is distributed as an Adobe AIR application to provide several performance boosting benefits from living on the desktop.
At SitePen, we help our clients build great web applications. Most are not available for public consumption as they live behind company firewalls and/or require licensing. On the other hand, Queued is free and open-source software, BSD-licensed, and hosted on Google Code.