Archive for November, 2004

Best Practices chapter on Dev Center

A chapter from Using ActionScript has been put on the Developer Center.

Oh, and it isn’t just any chapter (suuuuuuuuure dehaan, you say). It’s the Best Practices chapter, that includes coding conventions and the like. I’ll quote what it says on Dev Center (well, I did write it initially… so I suppose it’s acceptable to plagiarize myself).

Best practices are particularly useful when you share FLA files with other Flash developers, or you want to create consistent and readable ActionScript. Adopting best practices can help you increase productivity and improve your workflow whether you’re working solo or on a team. The “Using Best Practices” chapter covers recommended practices and naming conventions in Flash development, as well as best practices for writing ActionScript 2.0.

There are many other best practices that you might adopt when developing projects and writing ActionScript, and the Macromedia documentation team would love to hear about them. One way to submit feedback is by using the LiveDocs system. You can browse to the beginning of the “Using Best Practices” chapter here:

Alternatively, you can find a page of this chapter in the Flash Help panel and click the View Comments on LiveDocs link at the bottom of the page. This opens a browser window where you can submit your own “best practice” recommendations into the LiveDocs system.

Sure, this stuff is already in the docs. Why put it up on the Dev Center?! Truth be told, many people didn’t know it was there. Many people were still sayin’ “Flash documentation people, Macromedia, why aren’t there best practices/code conventions in the docs? You’re missing something important!!” — well… it was already in the docs! But no one found it. So here it is up on the dev center, so perhaps people will find it.

But it’s hard to agree on best practices. Trust me, I know – there were many conflicting opinions that were no fun to deal with when compiling practices. And yes, best practicing Behaviors is no easy task. So let us know what you think or what to add. This is one behemoth document already (partly why some areas might not feel as fleshed out as they could be, and why other topics might not be in there– yet), but your feedback will help form future documents. So – let’s hear it.

Thanks and merry Thanksgiving!

Survey day: What are your thoughts about Help systems?

Today is Thursday survey day! Let’s think about our favorite, and least favorite, help systems and help system features.

First of all, there are internal and external help systems. An example of an internal help system is what you find in Flash MX 2004 – the Help panel. External help systems might use a browser window — essentially, this help lives outside of the program you seek information about. Fireworks MX 2004 has an external help system.

So what do you like and/or dislike about these kinds of Help systems? Which system do you prefer to use when you work with Flash?

Lastly, let’s think about the features you find in each of these kinds of Help systems. Which features do you use the most? What do you consider vitally important features of a Help system? What features are “nice to have”? What kinds of features speed up, or slow down, your search?

Your feedback is appreciated!

Welcome to the Flash documentation blog

Hello and welcome to the new Flash documentation blog. Just a quick introduction before we get going. I’ve been around the Flash community for awhile, and started writing books on Flash a few years ago. I started the website (we still blog there too), a forum, and submitted a number of Developer Center articles and tutorials. So in addition to writing, I use (and love) Flash.

After writing full time for a few years, I started contracting as a technical writer for Macromedia (for the 7.2 updater release) and moved from Calgary to San Francisco about 6 weeks ago to start working at Macromedia full time. This city (and the green-colored Macromedia basement) are great places to hang out.

So the purpose of this blog is to do the following:

– listen to feedback on the current documentation structure and content (of course!)
– listen to what you want to see in future documentation (particular examples and so on)
– elaborate upon certain elements of the documentation (such as explaining how some of the Help Example FLA files were built… have you found them yet?)
– demonstrate bits of new documentation you might not have seen yet
– answer and address FAQs (from feedback on the LiveDocs system)

Big thanks to Mike Chambers for setting up this blog, and I look forward to hearing your feedback and sharing ideas.