Archive for January 25th, 2007

Well, actually, I’ve got some ideas according to the subj, and I’d like to share my opinion about it. Well, lets start…

Sometimes we’ve got a lot ideas for current version of any program. And after we start developing new version of program, we actually can’t stop developing it Funny, isn’t? So, now I’ll try to formalize some kind of project life-cycle not only for Edge Beyond Products, but almost for every dynamic and features full solution.

Project life-cycle

Well, actually while creating new version of product I follow next system:

• Developer Edition release of a product should crawl. This means it should do the bare minimum to be recognizable as what it’s intended to be. If it’s supposed to be a foo, and someone could look at DE and say, “That’s a foo” you’re done.
• Alpha version should walk. This is where you add enough functionality that the product is useful in day-to-day life. This is not the time for polish. Basically, it’s just adding the things that most people insisted should have been in DE version, because without them, they said, the product is completely useless. They were wrong then, but they’re right now.
• Beta version should run. This is where the product hits its stride. What it does it should do well. It should be comfortable to use. It should be strong, polished, and effective.
• Release candidate should fly. This is where all founded major bugs are fixed, all improvements implemented… On that stage you should not add any major feature into the product. It is an RC version and it should to be ready to be shipped in few hours.
• Post release version (directors cut). This is where the, “Oh man, wouldn’t it be awesome if…” features get added. This is where you start implementing things that aren’t necessarily useful now, but have a lot of possibility. That version will never be released externally. This is only for collecting new features for the next version.

Anyway I try to follow it.

Features per update

Sometime we’ve got to decide, which and how many features should be included in the next version of software. After some thinking over that I draw next conclusions:

• For Major Updates:
  • Add not more than 2 major features for each subversion;
  • Fix as many bugs as you can fix for this version (based on your experience and time limit you have). Pay attention for the major/critical and block bugs.
• For Minor Updates:
  • Fix as many minor bugs as you can for this version;
  • Add some improvements and minor features which will not entail serious program rewriting. But don’t add more that 2 features for on sub-sub version.

Major vs. Minor

After reading what I’ve wrote above, I decided to explain what is the major feature/bug and what is minor feature/bug.

As for myself, the main difference between major and minor is functionality. Usually, minor feature is something like “We’ve got two bindings to rise this action, but in new version we’ll have one more”. The major feature is like “now you have one more new action”. Basically new feature is extremely new feature with basically new bindings.

According to the bugs… Minor bug is like misspells, “unclear” descriptions, some miss-function, that will not entail 3rd party software be crashed. All other bugs is a major. All bugs, that will crash 3rd party software I call “blocker” or “critical”.

Updates per ….. Thoughts about updates rate

Well, what I want to tell you about updates rates? As for me, the optiomal is one month between every release. It doesn’t metter if previous release of this software was half a year ago.

If you’ve released any software less than month ago you should wait a little. Why? First of all - its better for your users and for your especially - not all of your users check you site every day and will download new software in the day it was released. Usually, it take about 1-3 weeks for all your users to get new version. I don’t think that customers will be happy to find out, that you’ve released new versions for many of your products ’cause they need to download it, test it, customize for them it. Yep…

The second point is - search engine ratings. If you’ll release all your updates in one short period - your rating will be increased extremely, but will fail extremely too Pity, isn’t it?

Any the last point - if you have anything for the fast update - why didn’t you included in the previous release?
Well, now thats it. If I’ll have any to add - I’ll do it.

Well… As I told we’re on the way of product upgrading… What is already implemented in new version of XSwitch?

• Skins support.
• Live window preview

Tune it up to you

Well… as far XSwitch now support skins, I disclose few moments about it. We support two types of skins: parted and solid. The difference between it is in layout of XSwitch screen parts.

In parted layout general window consists of few logically divided areas:

• window preview area;
• windows selector area;
• window information area;
• and misc area.

Every area has its own skin settings and can be customized as well…

Skins itself

Skin is a set of images and configuration file. It is clear and well known term. While developing skin subsystem we faced with problem of images types. Which types we should support for the skins? How does skinned window should look like?

So, looking through the existing OS features we’ve made a deal - we support many types of images, but prefer .png images. Why? Using .png images you can easily create gradient alpha channel for the image. So, using that image as skin you’ll create semi-transparent window. In one word it is enhanced image format

I’ll keep you informed about developing process of XSwitch.

Best regards,
Pavel.