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.

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.

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.

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.

I’m excited to announce a new open source project created by SitePen and co-sponsored by Adobe: Queued. With Queued, you can manage your Netflix queue anytime, anywhere! It’s no secret that we’re big fans of Dojo here.

With the proliferation of real web browsers on mobile devices (iPhone, Android, Palm Pre, Nokia), an increasing number of browsers (Chrome) or browser-like platforms (AIR, Titanium, Jaxer), portal standards for widgets and gadgets (Caja, AdSafe, work by the OpenAjax Alliance, and much more), are the days numbered for a JavaScript toolkit that uses the same code base across all platforms without a compile step numbered? Consider the following: “We hear your words. Why another JavaScript framework?! When development of PhoneGap was under way we noticed slow load times for modern JavaScript frameworks (such as Prototype, MooTools, YUI, Ext and (yes) even jQuery.