Archive for October, 2005

I am home from MAX and curious what you guys thought?

On the positive side:

There seems to be a lot of excitement around Flex Builder 2 and the advantage of ActionScript 3 in Flash.
If you have not already, check it out the new stuff on

Continue reading…

Just because you can do something, does not mean that you should. Tip 3:

This may seem obvious to some, but many of the users who contact support are actually trying to do things Flash was never designed for. We have had users who have hacked the ActiveX plug-in, attempted to circumvent security, tried to combine their C++ application Flas in a way that does not work within the limits of the API, and the most common issues are expectations of performance given applications of enormous scale or the application or built with no mindfulness of system resources. (People tend to forget that Flash is a browser plug-in.)

Before you start a project and before you call support do your research and ask yourself, are you trying to make Flash do something it is not designed for?

Continue reading…

Help us help you Tip 2

Troubleshooting applications can difficult for a support enginner when the application is enormous, even if the problem itself is relatively small. Depending on how an application is archetected and the experience of the developer who wrote it a seemingly small issue can have an unintutive root cause. Which leads me to Tip number 2.

Continue reading…

So this is my first post under what I like to think of as my “help us help you� section of the Blog

So this is my first post under what I like to think of as my “help us help you� section of the Blog. A lot of times users contact us at the tail end of a project sweating and fearful of not meeting their deadline praying we can work a miracle. Hate to spoil your hopes and dreams here but the number cases we can work a miracle on a short deadline are few and far between. We have a saying in Support… “test early- test often�. You have to keep a few things in mind before you seek assistance and ask yourself a few questions to help set your expectations. This is the first…

•  Is you code centralized and documented with comments?
If you think undocumented code scattered across dozens of movie clips and nested in dozens of SWFs is hard for you to read and keep track of, it is virtually impossible for someone to follow it who has never seen it before. The scope of support regarding troubling shooting code is very narrow. Technically, if the support engineer can’t determine that a feature is not working as designed, then they are not in a position to open a bug or develop a workaround to the problem. If the problem in your application can not be isolated due to its complexity, the help you are going to need will be closer to consulting then support and well that is just another service all together. (Oh and that service is not free of charge.)

•  Always use best practices when building your applications (its good for you, its good for your support experience; its good for health and wellness by lowering the stress of all who must look at your code *grin*)

•  Always provide a wealth of comments that describe what each method and function is for and when possible how it works and how it relates to the rest of the application (I can’t tell you how many times I have heard a user say, “I forget what this doesâ€? or “I’m not sure how this works but here is what happensâ€?. Big projects can put a strain on memory, that’s what the comments are for; use them.)

•  Be prepared to walk the support engineer through the logic of the entire application (By the way, if you find yourself having difficultly explaining how your application works, you should probably consider that design is too complex, and accept the possibility that if you don’t understand what is working, you can’t hope to figure out what is not working in a brief amount of time.)

A B & C are key to a good a experience with your support engineer. Remember, if you have not encountered a known bug with a known work around, it can take some time to get to the root of your problem. Clean easy to follow code, and a good explanation of the application logic and design can help the first level of support quickly identify you as an experienced developer. It will help the engineer to quickly rule out likely and common causes for the problem and get your incident escalated to the next level of support quickly and in most cases will let the next level of support start where the previous engineer left off and not from the beginning because of a need to verify the known(s) and unknowns of the issue.

I hope that helps your next support experience.

I welcome any comments on your experiences with Macromedia or other companies’ technical support departments.


Devleoping Flash for Mobile.. Internet reborn or are we going back to basics?

So lots of folks in the community are saying Mobile and Devices Development is the future. Some even say it will be like having a brand new internet. I have to admit, ideas of being able build Flash applications that can run virtually anywhere is an exciting concept but like all things new, we have a fair way to go before we will have Flash as abundant on cell phones as we do on Web Browsers. I can say development on devices is picking up. Slowly but surely developers are reaching out to support with the same sort of challenges they had when they first started making the transition from Flash animation and “Web Toys� to Flash Applications with advantages over existing technology in the medium. How many of you are developing Flash for Mobile Devices? Perhaps a better question, how many folks think they will probably be developing mobile applications in the next 2-3 years? Where is all this going to go, and what do you need to help you get there?