I just sent this out to subscribers of the DotComIt newsletter:

Every once in a while someone says to me, "I would have bought your component if it was priced at X, but it is too expensive." Now I'm giving those people the chance to put their money where their mouth is.

In conjunction with the upcoming 360|Flex conference, we've launched a name your own price promotion. Radiohead did it to promote In Rainbows! 2D Boy did it to promote their casual game, World of Goo! Why not us? We couldn't think of a reason.

If you want to jump right to the promotion, do it. Otherwise you can read ahead about our thoughts on this.

Where Do We Start?

It is up to us to add value to our customers above and beyond what they get by replicating digital bits. One of the items we offer is support. When you buy a Flextras component, you're buying access to us to help you solve your problems. You're buying the ability to have us tweak the API for your specific needs. You're buying peace of mind in the unlikely event that things go wrong.

Sometimes when you're dealing with random digital bits you find on the Internet they are not as polished, thought out, or bullet proof as you need them to be. Another value we can offer is our ability to continue to build and test high quality components. Your support, however you give it, helps us do that.

How do we judge success?

There are two ways we can judge this promotion as a success; one is by the number of people who participate. We'd love to reach one thousand new customers with this promotion. You can help. First, get your own set of our components. Then tell your friends. Blog about it! Post it on Twitter and Facebook. You can help us spread the word.

A second measure of success is the monetary one. I ran the numbers; and discovered that it takes $99.72 a day to keep Flextras running. That does not include non-routine marketing expenses, such as sponsorship costs of 360|Flex or Flash and The City. If we were to generate $15,000 of new revenue it would cover our conference sponsorship costs; and we'd consider it a smashing success.

Can you help us spread the word? We'd appreciate it?

A new year is always a great time to look forward and to look back. This is a modified version of January's DotComIt newsletter to discuss the "State of Flextras."

A Look Back

Flextras launched in January 2009 with a single component to our library. I had the five year goal of generating a half a million dollars in yearly sales and employing 5-6 people all focused on building a line of User Interface Flex Components that save Flex Developers time. The success of Flextras could be calculated in many ways, and I thought I'd share some of the metrics we use internally to evaluate our progress.

First, there is our Mailing List. Entering January, there were 239 people on this mailing list; now there are 662. That is a 277% increase in people interested in the stuff we do. We must be doing something right. I'll count that as a success. You can get on our mailing list by registering on our site and opting in.

Next, I take a look at our Developer Edition Downloads. We had 390 downloads of our AutoCompleteComboBox, and 189 of our DataSorter. While we're happy that 390 people are interested in finding out about the stuff we build, not everyone who registers on the site goes on to download a Developer Edition. We'll have to review our process to make sure it is not causing issues. This is a half success.

In a perfect world, Flextras would be releasing 6-12 components a year. That pace requires more than one developer. I was hoping to release four in 2009, but have fallen short. Building a Calendar has turned out to be a lot less trivial than I thought, and I didn't think it would be trivial. But, I've learned a lot and continue to keep moving forward. This is a half success.

Cash Flow is perhaps the most important indicator of the lifeblood of a business. From that perspective, DotComIt has had a rough year. Flextras has only generated 6 paying customers. Sales have been slowly increasing, though. I have a lot of my own thoughts as to why we don't have more sales, but if you want to chime in with yours, I'd love to hear them.

DotComIt brought in some money through other avenues including The Flex Show Pledge Drive, some small consulting projects, and some one-on-one mentoring. Unfortunately, we're still hovering near a $3K loss this year and I haven't taken any salary in ten months. These are fun times that we live in!

A Look Forward

My top priority is going to be finishing up our Calendar Component and getting that available for sale. I believe this is a big hole in the Flex community that is not appropriately filled; and I think I can be the one to fill it. You can watch The Flex Show video series for a good understanding of how we have approached our development of the component.

I expect to start offering some premium support options; and a subscription service where you can get our whole component set for a single price. I'll need to rework our web site to support such things, and may need another lawyer visit. I believe that selling a mix of support and services is one step to reaching our end goal.

I'm also thinking about our first employee. It will have to be funded by sales, but If Flextras can generate 40 sales a month, and keep up the pace consistently for six months, I'll be looking to add my first employee. It sounds like a big goal, but I plan to make that happen this year.

I'm also working on some non-Flextras ventures that should come out sometime this year.

Final Words

I'm sure that we'll have many other adventures in 2010. My own personal year in review is up on my blog now. The Flex Show's review episode will be released on Wednesday January 6th. So, tell me, what can I do to bring you on as a customer in 2010?

Lately we''ve been getting a lot of questions about the proper way to use the methods in the Flex 3 Component LifeCycle. I wrote about this in the December Flextras newsletter and thought I'd turn it into a post here too.

The Flex Component Lifecycle is a set of methods and events that Flex uses to setup, size, and position the components that make up your Flex Application. There four lifecycle methods that you'll use when creating Flex Components: createChildren(), commitProperties(), measure(), and updateDisplayList(). I'll discuss each one individually.

createChildren()

The createChildren() method is aptly named. It is intended to create the children of the component. This is run as part of the initial component setup and is never run again. In our Calendar component's MonthDisplay class we use createChildren() to create the day name headers to display the day of the week and the month header which displays forward / next buttons, the month name and the year.

commitProperties()

I consider the commitProperties() method is a wild card method. You'll use commitProperties() to coordinate component changes all at once. However, the exact use of this is a bit of a gray area. It depends what properties have changed and how they affect the component.

In many of the custom components I've built I find that I'm using commitProperties() as an alternative for createChildren(). In our Calendar component, I use it to create the month's days from a dayRenderer. This can't be done in createChildren() because we may not know the displayedMonth or displayedYear yet, and therefore can't determine the number of days in the week.

measure()

The measure() method will determine the ideal size of this component. Its' purpose is the most concretely defined of all the component lifecycle methods. This will set the measuredWidth, measuredHeight, measuredMinWidth, and measuredMinHeight properties on your component. A component is always sized by its' parent; but if these properties are suggestions to that parent.

How you calculate the meauredWidth and measuredHeight is open to interpretation and depends on your component. In most cases, you'll examine each of the component's children and keeping some type of running tally. For our Calendar component's 'month display, we set measuredWidth to the width of the longest week. MeasuredHeight is calculated using sum of the heights of the largest day in each week. The calculations take into account localization features, such as the first day of week.

I've experienced a few gotchas with the measure() method. First, if you specify an explicit height and width, the measure method will not be run. This is done for performance reasons. If you already know the height and width, why does the parent need suggestions from the child? It doesn't!

Second, the documentation states that measuredMinWidth and measuredMinHeight are optional, but I have found this not to be the case. If these values are not set I've experienced situations where the width or height ended up being set to NaN, which interferes with sizing calculations up the component chain.

updateDisplayList()

The updateDisplayList() method is intended for changing the visual pieces of the component. It is great for setting the height and width of your children and positioning those children with the x and y coordinates. In the Calendar's MonthDisplay this will size and position all the days. Even though the measure() method assumes that individual days can contain have different height or widths, updateDisplayList() forces all days to the same size. You may also use updateDisplayList for changing styles.

Final Words

• createChildre(): Creates the component's children
• commitProperties(): Coordinates property changes
• measure(): Determines the ideal size of a component's children
• updateDisplayList(): Positions and sizes the children