Flash developers are usually the last line of defense (meaning that we are the last ones to touch the project before the client sees it) and there is a lot of pressure put on us to deliver a polished product. At the point we start, chances are the deadline has already been stretched due to hang ups in the process before we ever see what we’re about to get ourselves into and being organized and receiving well-organized assets/direction is the key to success. Ideally, you should really bring the developer in during the kick-off meetings as it will ease the process down the line and make everyone’s lives easier. Even with the list below, it’s always good to explain to the developer during the early stages your vision and concept for the site, the animation style, demographic, and similar items that will aid during the process of development. Sadly, this usually never happens and we’ve got to buckle down and micro-manage everything to make sure all systems are go.
I’ve gone through this on every project it seems. I am ready to code and get the assets/necessary files from a designer/producer/back-end developer. I start opening stuff up and am underwhelmed at how much is provided. I’m missing a bunch of stuff and there are underlying questions about what needs to be done. In the interest of saving time, I thought I’d write a little guide as to what I (personally, at least) would love to get every time I start a new project so I can reference this in the future as well as hopefully get some input on stuff I may have missed or never realized in my process. This is an ideal scenario, of course, and a lot of times you won’t receive this entire list (and in some tragic cases, any of it), but it makes life so much easier on a Flash developer to actually have all of these things ready to go when the project is handed to you for the final stretch and you want to hit that deadline.
- Copy Deck
- External Assets
- Rollover States
- Error Handling
- “No Flash” Page
NICE TO HAVES
- Layer Comps
- Interaction/Motion Guide
- Scripting Guide
- Asset Organization
Every project has different requirements. You can’t start coding unless you know that the project is supposed to run in Flash Player 8, 9, or 10+. The target Flash Player is huge because it will make the difference between AS2 (8 and below, please don’t do this to us!) and AS3 (9+), which makes a HUGE difference. You also need to know what the target file size is (if you’re doing banners or something that needs to be kept relatively small) and physical dimensions (is this full screen, a set size, liquid, or need to fit into a small part of a hybrid site?). It’s also imperative at this time to make sure the designer is designing for whatever the target resolution is (hopefully nobody is designing for lower than 1024×768 at this point) and what the target audience is.
No matter what project you’re on, there is a 99.9% chance that you will be adding copy to it (probably closer to 100%, but you get the idea). Lots of times you are handed Photoshop PSD files that have copy in them because the designer obviously used the copy to aid in designing the appropriate sections. Sometimes, however, there is no one single document that holds all the copy on the site. This is problematic for two reasons:
- You can’t easily scan the document and rip out sections that may not be visible in the comps.
- Editing site copy becomes a chore because now you have to have the designer make new comps of site changes and somehow show them on the comp to make sure the developer catches what has been changed.
With a separate Word document that has all the copy you can easily make a change and highlight it in a different color or background for the developer to quickly scan the file and find what has been changed. Word-savvy power users can us also use the snappy little comment tool to add comments (only issue I’ve seen with this approach is that after a lot of edits, the file starts to have lines pointing to a bunch of things in the document and is hard to follow, let alone the margins filled with comment bubbles). Be sure to remember to version the file as well, as ideally you’ll want to remove all color changes/highlights when making new revisions and add the newest ones in. That way, if you hand off a bunch of edits to the developer, then make more edits, he can look at each version separately and go back and make the appropriate changes while still easily finding what has been changed by a quick color scan. Even better, if you have a change log at the top of your file (unrealistic usually, but awesome if done right) you can track changes that way as well. If your developer is color blind, however, this causes another issue that is outside of the scope of this article.
Everybody loves fonts! There has not been one single project that I’ve worked on where we have not run into some type of font issues. Whether it’s Mac to PC, PC to Mac, OpenType to TrueType, not delivering the fonts at all, or whatever the heck else, there is always some kind of issue with fonts. Designers have to be absolutely sure they keep track of all fonts used in a set of designs and package those up for a developer. Ideally, you want to use cross-platform fonts that are OpenType, as it works on both Mac and PC.
There are all kinds of external assets that get used in a project and it all depends on what the job calls for. Nine times out of ten, however, they will fall into these three categories:
- Images – Make sure you size these (yes, all of them) to whatever the final output in the project should be. You would also be wise to speak with the developer at this point to see if, for instance, you have a product shot that is repeated on the site but sized differently, if you can make it one size (the larger size) and scale proportionately down to whatever size it needs to be in the other area. It is also a good practice, I have found, to save them as JPGs in Photoshop using the Save for Web dialog and setting the quality to 60 while checking “Optimized”. This has always worked great for me and I don’t see much of a difference between this and the other, higher settings, while retaining a manageable size. Again, though, it’s a good idea to speak with your developer at this point so he can tell you how they want the files saved out in case they want to control the compression through Flash rather than during the saving process. (NOTE: This is for external images that get loaded in to the Flash, NOT for images that are part of the design/layout of the project. Those should not be saved out as the developer or whoever is preparing the files for the developer will handle this accordingly)
- Sounds – I normally prefer them to be saved out in the .mp3 format. This is native to Flash and it handles MP3s relatively well. Just as with images, speak with your developer and see if you should compress your sounds or if they will handle it on their end.
- Video – Flash does not have video editing capabilities so it is imperative to output the file in the state that it is supposed to look like when the project is finalized. This means that all cropping/post-production should be done in other programs like Final Cut/Premiere/After Effects and output as an uncompressed .mov file at Millions of colors. If alpha transparency is involved, use Millions+ as this will allow the encoder (which is normally the Adobe Media Encoder that ships with the Creative Suites) to preserve the alpha channel.
Flash is great and compression is fun (NOT!), but exporting a bunch of transparent PNGs and putting them in your application is bound to cause performance issues. I like to use vectors wherever possible because they preserve their editing capabilities and because I can always set them to act like bitmaps if necessary. A few things to note on this topic:
- A lot of designers like to draw a vector in Photoshop. This isn’t really a true vector in terms of what Flash sees. If you export it out of Photoshop, you will be exporting a bitmap unless you go back and trace the path, make a selection, export whatever, etc. It gets messy. You should really be creating the vectors in Illustrator, which is a TON easier to create vectors with in the first place, and importing them into your Photoshop designs as smart objects.
- While on the topic of smart objects, these are insanely helpful for a developer and take only seconds to create. PLEASE use smart objects in your designs. If you’re unfamiliar with them, there are tons of tutorials on smart objects out there. You would do wise for yourself as well as the developer to Google it real quick and incorporate it into your workflow.
This is another item that always seems to be forgotten. You should be creating rollover states for all of your interactive objects as you go along. One of the great things about Flash is interactivity, and what better way to go interactive than to show the user some kind of feedback that they’re rolling over an object that is clickable/selectable/etc? Isn’t that the whole point of using Flash in the first place? It’s always very helpful to the developer to show the rollover states of buttons and other such items along with layer comps (see below).
Sadly, preloaders are like the forgotten stepchildren of the Flash world. It’s a shame, really, that they become an afterthought because it’s usually the first thing a user sees when they come to your site and you want to set a good first impression. I’ve been captivated by many awesome preloaders in the past and so have others, so much so that there is a site dedicated to show off the coolest preloaders out there (Pretty Loaded). Most of my projects I never even get designs for a preloader and thus I end up creating the good ole boring line loader when everything else is said and done. Please remember as well that when you talk preloaders you’re not only talking about the main site but external assets that are being loaded in as well. This includes images, sounds, and video, and usually you also need (if different) a buffer animation for those. It’s such a small treatment but can add so much to a site’s overall look and feel.
In today’s day and age a lot of the projects you will be working on have some type of user input, be it a log in page, a registration form, or a contact page. Designers almost always deliver these but do not show scenarios for when errors occur. What happens if the user enters an invalid email address? What happens if the user doesn’t fill in all of the required fields? Where does this error show up and how does it look? Is there different error treatments for different input fields or do they all show up in the same spot depending on what portion the user is currently filling out? Are they inline errors or do they appear when you press submit? These are all questions that the developer will undoubtedly have so they need to be accounted for in the user experience as well as the design process.
“No Flash” Page
NICE TO HAVES
Normally, this isn’t a requirement. Some projects are small enough that just looking at the comps is feasible (although not recommended). For larger projects, it’s really handy to have a nice set of wireframes that clearly illustrate the project’s roadmap and are detailed enough so that most of the usability questions are answered within the wireframes themselves. These are like a site map and show processes, such as logging in and the resulting pages for each possible scenario (success, fail, server failure, etc). This is also a great place to show error handling (see above).
Much like smart objects, layer comps take only seconds to make and could save a developer a ton of showing/hiding layers/folders in a PSD. For those unfamiliar, a layer comp is basically a snap shot of your PSD at the current state. A designer who is familiar with the layers of the PSD can quickly go through and show/hide each set of layers necessary for each state of the application and take a layer comp (snapshot) of it and save it into the layer comps palette. The developer can then quickly show whatever state was defined and see all the states of the application without having to fumble through layers and folders. Of course, you should be organizing your layers as you go along as well, but this is even more effective in the hand-off process. Just make sure to name the layer comps (just like you do actual layers) so you can recognize what’s what at a glance. Of important notice here is also that if you change your design after creating layer comps, you will have to re-create the layer comp or Photoshop gets confused and doesn’t know what has been changed and what it needs to show. In this instance there will be a notification icon on the layer comp in the layer comps palette notifying you that something has been changed and that Photoshop doesn’t know what to render for this layer comp any longer. For this reason, layer comps should ALWAYS be the last thing you do before hand off. Don’t forget to make layer comps for rollovers as well if everything is contained in one file. This will make your developer so happy that you’ll be recommended for future work with them, guaranteed!
Let’s face it. Developers are not super creative, and those that are and have some kind of background in motion/design come few and far between. Most developers come from a computer science background where graphics were just ones and zeros on a screen. Even I have a degree in “Multimedia and Web Design” and experimented with 3D Studio Max, After Effects, and a slew of other programs where motion was a plenty and have lost my touch in animation as I’ve come along as a programmer. It is SUPER helpful to see the designer’s vision in a nice and clear document that possibly shows frames of an animation or even a description of what it should do. You can even send example links of something you may have seen before if applicable to help the developer picture your vision. Just remember, not everything you’ve seen before on another design applies to your design. A flat rectangle in 3D space won’t animate the same in perspective as an oddly shaped image of an animal or some other type of organic shape so make sure to keep those details in mind when figuring out animations for your project.
If you’re working closely with a database programmer or a back-end developer in general, it’s always nice to know what methods they are writing, what parameters those methods expect, and what the output results for all operations is. For instance, if you’re sending along some information into a database, it’s good to know what variables you need to send. Then, when those items are added to the database, you normally get a result. It could be an XML/JSON output of a query or something along those lines and seeing that result clearly laid out in an example is extremely helpful to a Flash developer so they know how to treat it and what to expect. This is usually one of the easiest steps to achieve as developers usually speak the same language and can understand each other more clearly.
If you’re providing external assets, organization is VERY important (it’s always important, but the importance here is even greater). Speak with the developer and figure out a good folder structure/naming convention for your assets so that they can easily pick them up and transfer them right in to the project’s folder structure without having to make many (if any at all) changes. I’ve been in a situation before where I’ve spent literally one or two whole days organizing assets and re-saving things because they were not very easy to find or not compressed properly. Everyone has his or her own preferences on this so I won’t get too specific here, but just know that you will be loved for handling this from the get-go.
That concludes my list of things that you would be considered a genius for if you delivered to a Flash developer at the start of each project. This is certainly open for discussion as well as revisions and I encourage others to give input so I can add them to the list and make this an ever-growing resource for Flash developers to send others at a kick-off to ease the pain.