Scale9Bitmap Class
I often use Actionscript's native scale9grid -feature for scaling user interface elements. That's a neat concept as it allows the elements to have crisp borders and shaped corners, and still scale nicely to accommodate the needed space. The sad thing is that the scale9grid -feature only works for vector graphics and I often want to use bitmap graphics for the smaller user elements in order to minimize the amount of vector graphics that has to be rendered for screen, and because that obviously allows more flexibility for design.
For this reason I developed the Scale9Bitmap -class, which allows me to make, for example, a button in Photoshop, define a scale9grid for the image's bitmapData and just scale the button image so that the text or glyph fits nicely inside the button. The solution is to slice the given bitmapData into 9 pieces according to the scale9grid Rectangle, and then just to scale each one in the correct axis.
Here is a sample how the scale9grid affects the bitmap scaling:
So, if this is a feature that you think you would find useful, go ahead and download Scale9Bitmap.
A more detailed specification of the scale9grid functionality is available at Actionscript 3.0 Language Reference.
This class is provided "as is", and still needs some development. In particular, there is one key feature still missing: the bitmap doesn't scale correctly below the given grid border size. So if, for example, you define a grid that has a 10px left column and the 20px right column, the bitmap is not scaled correctly if you set the width below 30px. Besides that, it should work nicely, and I use it very often in my daily work.
Simple software design process
I was recently asked to provide a client an application that would allow users to upload their photos to a web service, and then have an application that would allow users to compose a photo album, or calendar, or other kinds of useful products from their photos. There are of course many ways to achieve this, and it has also been done many times before, so I had the advantage of not being in a pioneer position. I researched the most promising of the existing applications that were designed for this purpose, but found out that none of those were intuitive, easy, quick, nice, scalable or user-friendly. They were just solutions that provided the basic set of tools for the user to technically achieve the outcome, but no help and no guidance for the user to achieve what he or she was actually after, which is a nice looking photo-album.
So I decided that it's better to design and develop the software myself than to use some half-thought engineer type of solution. I started the project by considering the average user's ability to design and compose a nice looking and stylish photo-album. I found out that there are users that have little or no eye for visual design and layout, and then there are users that are proficient in making neat layouts and compositions. There are users that are motivated in using hours or even days composing the product, and there are users that want the process be very quick and effortless. And then, of course, there's everything in between. After a while of thinking I came to conclusion that targeting the application for the "average user" means that it's not probably going to be the best solution for any user.
At this point the thought process came down to a simple math. If I take an equation (the user interface solution), and test it with values 0% and 100% (both ends of the user proficiency/motivation and other parameters) and it works, it probably also works for every value in between, and this gave me basically just two user groups for which to target the solution. So I decided to combine both a quick, easy and effortless way of achieving the desired outcome, as well as a complicated and time-consuming way of achieving a high accuracy of the user's desires. The hasty users can answer couple of simple questions (which kind of covers, which kind of background, which kind of frames for the photos), and the system would layout the album automatically. (The task of automatically placing arbitrary amount of photos on a finite area in an aesthetically pleasing way wasn't too easy, either, but that's another story which I may post a separate post later.) After that, the more studious users can alter the way the photos are laid out, add effects, color correction, rich text and whatnot, but at this point, the hasty user already has a relatively stylish album ready.
So the process of making great Flash applications is not just about programming. It's also about always taking the user's abilities, desires and motivation into account when making the decisions about what the final application should be like. This is, of course, true for every other type of application development, but as Flash is relatively new platform for developing actual software, and the possibilities are truly endless, a good developer should always carry great responsibility for the user experience and not let the bad ideas get through to the final product.
Hello for the first time!
Hi, welcome to the blog of a Finnish Actionscript developer Joonas Mankki. I have been thinking about writing a blog for a long time, and recently I got involved in an inspiring large-scale project that for once has a nice schedule and doesn't take 24/7 of my time. So I thought now I might actually have some time to write about the things that I do. One day I'll probably design a layout of my own for, but for now I just picked one from the stock that looked the best to me (thanks Andrei).
In this blog I'm going to share my views on the Flash-technology, my ways of designing user experiences, some useful Actionscript 3.0 classes I've developed along the way, and I also try to give you a change to learn from my mistakes so you don't have to make them yourself. 
So feel free to debate on the design philosophies, use the AS3 classes I share and suggest topics that you would like to be covered here.