A process I went through a lot in my years as a flash developer went approximately as follows:
The client/agency would supply a finished design of a flash site (with complex interactions specified)
I’d question the interaction ideas, but my questions would be dismissed and I’d have to build the entire site to a full working version
The client/agency would see the finished version, but be unhappy with the interactions (which they had designed)
50+ rounds of changes that involved me rebuilding and refactoring huge chunks of code until the client was satisfied
What caused this problem in most cases was the lack of allowance early on in a project for prototype time.
I love prototyping – it’s great to be able to get a working model of an idea up and running and iron out (or dismiss totally) any issues that arise well before you get in to production.
So… right now I’m working on a few different iPad concepts that involve the same general principles:
Adding items to a scrollable list from the a library of items
rearranging said items
dragging an item onto another area of the interface to update its properties
While I’ve espoused the advantages of paper prototypes in the past – I’m finding it difficult to model complex interactions like multi-touch and drag+drop using lo-fi models. With complex interactions speed, responsiveness, and device limitations are extremely important things to test.
To get around this issue I’m trying a new prototype workflow: as I come up with an interaction that doesn’t suit a paper prototype, I’m building a small, standalone prototype that I can use to test the idea accurately without investing too much time building fully-functional parts of the interface:
The additional advantage of working this way is that while I’m in the design phase of these projects I’m still keeping up my coding practice (I’ve still got a lot to learn with Objective-C) – each little prototype is a discreet programming challenge that I can commit to without worrying or getting overwhelmed. Each prototype I make is also helping me build up a library of interaction code that I can use in the future if I decide that the idea doesn’t suit this particular project.
The problem with being a flash developer from a traditional graphic design background is that there are some things that just don’t come naturally. One of these is working in a command-line environment.
I’ve been using the Flash IDE as my development environment on the Mac since Flash 4. Around the time of Flash 5 I started using BBEdit to edit external .as files, around MX I switched to TextMate for AS2 development, and now use TextMate exclusively for AS3 projects. But I’ve always used the IDE as my compiler, and there was always my designer’s preference to use the IDE to draw and layout objects rather than generate everything programatically. In developing my WordPress library I’ve been forced to bite the bullet and move to MXMLC, for the simple reason that the built in RPC libraries and Ak33m’s XML-RPC are only available for the Flex SDK.
I’m basically a total unix-command-line newbie, and there is a real dearth of information for people like me on how to command line compile in the mac environment. There is this tutorial by Senocular for the PC, and there are plenty of tutorials out there about using MXML, integrating shell commands to use ANT etc etc, but all of these assume you know what you are doing already.
I don’t know what I’m doing though. All I want is to be able to integrate the Flex SDK classes without having to purchase and learn Flex and MXML – I’ve discovered that this is of course not only possible, but easy - not that you’d know it by looking online.
The Flex2 SDK is free! It includes the flex libraries and and the mxmlc compiler you will need to use the command line.
2. Put the Flex2 SDK somewhere sensible
I put mine in ~/Documents/Library/Flex/flex2_sdk_hf1/
3. Open a terminal window
Usually ~/Applications/Utilities/Terminal.app
4. Navigate to your project folder, eg:
cd Documents/Projects/my_flash_project/Development/
5. Run fcsh
Fcsh is the Flex Compiler SHell, a wrapper for MXMLC that makes compiling fast and easy. The simplest way to run this command is use the Finder to navigate to where you put the Flex SDK, find fcsh (in bin/fcsh) and drag and drop this file into your terminal window.
You should now see the following:
Adobe Flex Compiler SHell (fcsh)
Version 2.0.1 build 159086
Copyright (c) 2004-2006 Adobe Systems, Inc. All rights reserved.(fcsh)
fcsh: Assigned 1 as the compile target id
Loading configuration file /Users/absent/Documents/Library/Flex/flex2_sdk_hf1/frameworks/flex-config.xml
../Deployment/main.swf (82769 bytes)
You see that last line ../Deployment/main.swf? If you navigate to this folder, you should see your swf sitting there! That’s it.
As you see above, fcsh Assigned 1 as the compile target id. This is just a shortcut to the compile command you just wrote – it means next time you want to compile you can just entermxmlc 1 instead of typing the whole command again.
Now you can use Flex libraries in your flash projects without learning Flex and MXML.
This took me hours to figure out, so I hope it helps some of you out there.
Recently I was searching around for an easy way to build a flash front-end for a WordPress managed website for a friend of mine. I was incredibly surprised to find that there doesn’t seem to be a properly integrated ActionScript library available for WordPress XML-RPC, or if one is available, Google and the Actionscript community don’t seem to know about it.
So I’ve decided to build one.
I’ve had a little experience building ActionScript API libraries before when I was testing the Artbeat API with AQ – the Artbeat library has its flaws (not the least of which is no documentation of any kind), and I’ve learnt a lot from that experience.
My idea is single library that allows you to easily make all of the WordPress, MovableType, and Metaweblog API calls required to integrate flash with WordPress. I’m using Akeem Phillbert’sxml-rpc as3 library, as a base for the XML-RPC calls.
I’ll be posting my progress here as the library develops.
