So you have this great community-based website. People are making profiles, uploading images and videos, voting on who's got the hottest dress and 'snagging' each other's cakes. What you need now is an interactive map that not only shows you where all of the parties are and how many people are going to be there, but also links you to the host's profile page so you can check out the car daddy is getting them for their birthday. OMG, you need XML!

Okay, so no one is likely to be squealing over the code behind the party map that Killswitch recently built for one of our entertainment clients—this kind of dynamic user data-driven application isn't even all that new. But I have to admit that I got a little excited over this and other similar projects that we've been doing at Killswitch thanks to the combination of ActionScript 3 and Ruby on Rails and how they handle XML.

These projects usually follow the pattern of users upload some sort of content (party info, images etc. ), data about that stuff gets stored in a database (city, name, longitude, latitude, file paths), then it's packaged up as XML and passed on to the flash movie (map) where that information is dressed up in its party outfit.

The benefit of using Rails on the back end is that it makes accessing the database and generating xml an easy, elegant and painless process. It can be as simple as adding one line of code:

render :xml => @parties.to_xml

Which parties this refers to is of course determined by the find conditions you set when the @parties object is created. If more control is needed—maybe there are fields in the database we don't want to make public or there is some sort of reformatting we want to impose on the data—we can render a template instead. This is done similarly to an html template.

ActionScript 3 is beneficial for the same reason that working with XML in Rails is convenient. It is nearly automatic. In previous versions of ActionScript if I wanted to get the name of the second guest attending a party as represented by this excerpt of XML:

<party>
  <host>Seth</host>
  <location>Chicago</location>
  <guests>
    <guest>Jasper Johns</guest>
    <guest>Julie Mehretu</guest>
    <guest>Robet Rauschenberg</guest>
  </guests>
  <time>9pm sharp</time>
</party>

I would have to write something like this:

//assuming the xml is loaded into partyXML
var second_guests = partyXML.firstChild.childNodes[2].childNodes[1].firstChild;

This is not exactly very legible and becomes less so as we go deeper down the xml tree. What's worse is what happens when someone decides to change the structure of the tree. If time were listed before guests, we'd be looking for a list of names somewhere inside "9pm" and that wouldn't be conducive to anything good. The assignment to second_guest would have to be rewritten.

One alternative would be to write a function that parses the xml and formats it into an object that can be easily referenced later, but I'd rather spend my time animating something. After all, that is what flash is good for. This is where ActionScript 3 wins some praise. These days all it takes to find the second guest coming to my party is:

var second_guest = partyXML.guests.children()[1]
// returns "Julie Meretu"

Finding the time would be:

var start_time = partyXML.time
// returns "9pm sharp"

It is intuitive, legible and clean. I don't need to know the order in which things are listed in the xml. I only need to know how they are nested and what the tag names are. Not only does this save the headaches of maintaining cryptic code when the xml structure is changed, but it also saves a lot of time—time better spent on perfecting shape tweens or tricking out the user interface.

So there it is, your dynamic XML birthday cake fresh from the Rails bakery, ornately decorated with a layer of Flash-icing. Everybody nosh.

Welcome to Perspectives, a collection of articles written by members of the Killswitch staff. These articles will pertain to the individual strengths of the authors, as well as the firm's position on certain issues and outlook for the future. We are starting by writing under four topics: Development, Design, Project Managemment and Running the Business. Here's a quick rundown:

• Development articles will be directed at the development community. Some of these articles will be technical in nature, while others will be commentary on larger development matters.
• Design articles will range in topic, but will be written by our design staff here at Killswitch and will support our design logic, design tasks, challenges and everyday solutions to solving our clients' big design problems.
• Project Management articles will range from Killswitch's unique approach to managing a project, to simple and easy strategies we employ to make our project management the best for our clients.
• Running the Business articles will be written by the Partners at our firm, and will include high-level business and marketing strategy topics, as well as client and relevant business issues.

Overall, we hope this is used as a resource to learn about our practices as a firm, our holistic approach to design and development, and how as a young firm, we have continued to thrive in a competitive market.

One thing that always bothers me, whether I'm building a computer or doing research for other people, is that people don't always know what they want.

I'll explain. Everyone, including myself, has an occasional moment when they think to themselves, "If I would have known this or found out about that, I would have done (fill in the blank) differently."

And because of this, I approach almost every situation with this in mind: "I don't know everything, but if I did, how would I go about this?" Some of the most common questions we get at Killswitch when it comes to our business (other than "How much does it cost?") is "Can you make it work the way WE want it?", and my personal favorite "I have a site and I want to rework it. What do you recommend I do with it?" Here is where I come in (maybe that's why it's my favorite--it's nice to be wanted).

Let me explain the “Can you make it work” question. There are times where the client has an idea about how a site or application is supposed to work, and while the idea is what counts, the technology they want to use is not suitable to the task. We will try to recommend to the client the right solution; after all we always have our client’s best interest in mind. But what if the client is set on a specific technology? Do you tell the client that they don’t know what they're talking about? Do you risk your reputation on a minor technical disagreement? I say no.

The purpose of the research that we do is to provide simple, specialized solutions--elegant design with the best possible user experience at both the client and user levels. That’s why we spend time researching, scrutinizing, putting together the pros and cons of current and upcoming technologies, and making our case to our clients. Most go with our recommendations; others maintain that their approach is the best. Again, we have our client’s best interest in mind and so, before we begin anything, we inform them of any potential pitfalls and shortcomings that might come up. It’s our professional responsibility to also educate the client, whether they go with our recommendations or not, by putting together help and technical documentation and, when we feel it’s necessary, video how to’s. We do this to minimize learning curves and get users up and running.

And while I’m in an explaining mood, let me also touch on the "reworking" aspect of our business. Let’s say that a client has a website that looks outdated, and they want to modernize it. We can do it of course, but does it have to be from scratch? Can old data be reworked so that information can be re-used? Again, we research ways to save data and rework a site or application to satisfy the client. All we do, aside from updating a site, is give it a face lift, so that the client’s message is seen (and heard) in this multimedia-driven world.

In the end that 's the goal. We want to make a dollar and a dime in this business, but we also want give people something useful, and possibly entertaining, something that will make others say, "This is a nice site or application, it's easy to use, looks great and it does what it's supposed to."

A little research comes in handy in our world. It could make the difference between telling a client that their project will be done on time or that it has to be delayed because there were factors that were unaccounted for (servers not equipped to handle the amount of net traffic, site is too complex for users, etc.).

Information is power, and in our world, it's a necessity.