microISV, The Product Concept

Building the Foundation

As already mentioned in a post right back at the start of the blog, I already have a pretty clear idea of what the first three product components will be. Our first component is actually quite simple in concept and so don't expect it to blow your socks off!

Although simple it is an essential building block needed for the second and third components that will be built on top of it. So it provides the foundation for the rest of the component suite. Not just as a reusable component but also by providing helper classes and base implementations that can be reused later on.

Classic Controls

After working with several different user interface libraries you being to notice that there are several custom controls that obviously are conceptually related. Yet, to my surprise, they have never been built from the same base class or using the same fundamental building blocks. This makes it difficult to interoperate between them.

Think about the classic TabControl. This allows the user to navigate around a set of pages in a random manner. They can click from page to page by using the appropriate tab header. Now think about the classic Wizard dialog. Again the the user can navigate around a set of pages, but this time in a linear fashion. Another more recent control is the Outlook bar from Microsoft Outlook 2003. Here you can select pages at random by using the large square buttons at the bottom of the control.

Really these are all just controls that allow the user to define a set of display pages and then provide different user interfaces for moving between them. So our first component is going to be called the Navigator and do just that, give a variety of user interface mechanisms to move around pages.

The Navigator

Having a component capable of providing many navigation interfaces has several key advantages. With other libraries you might create a TabControl with a set of TabPage instances. But if user feedback indicates you need to change over to a Wizard you cannot just copy across the TabPage instances. The chances are your Wizard component has a completely different set of classes and you need to go to some effort to copy across your designs.

Although not a huge effort it does still take time to learn about the new component and copy across the controls for each page. With our navigator they just change the mode property and hay presto, it changes over. Better yet they can use the traditional TabControl style appearance when designing, making it easy to randomly move around, and then switch it to Wizard operation when finished.

So our first unique selling point for the component is the provision of multiple modes or user interaction. We provide all your page navigation needs in one handy control that is a piece of cake to learn. You learn how one control works instead of having to understand several.

Separating the Layers

Our second unique selling point is going to come from the architecture of the control. Instead of encapsulating all the drawing inside the control we are going to separate out the functionality into different layers.

Palette Layer - Provides the colors and font for drawing.
Rendering Layer - Draws using a palette in a particular style.
View Layer - Handles the layout of visual elements.
Controller Layer - Responds to events and initiates actions.
Model Layer - Manages the collection of pages.

This is really just an extension of the traditional Model-View-Controller design pattern where the View is split into three separate layers. This makes it easy for us to change over the palette layer to give a different appearance without having to alter the renderer at all.

Before I get stuck into too much of the actual coding, any feedback on the idea would be appreciated. But remember that although the Navigator will be sold as a stand alone product in its own right, it is mainly intended as the building block for other more value added components later on. So don't be too harsh!