Phil Wright : Component Factory

Monday, June 13, 2005

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!


  • Not so much in reference to your first control idea, but a separate suggestion. How about creating a decent date/time picker. I have yet to find a high quality .net control that allows for easy selection of both date AND time. There are lots of decent date controls, a few ok time controls, but very few that I have found that can do both with a nice easy to use interface.

    By Anonymous Mark Langille, at 10:43 pm  

  • I wonder if you can make your generic "navigator" component also have a fourth, web-browser-like mode using "forward" and "back" buttons, and even a navigation box where the user can type the name of or select a page from a drop-down.

    The browser is easily my favourite interface for navigating within a set of related "pages".

    By Blogger phil jones, at 6:12 am  

  • Good idea. I will certainly add an ability to have a title bar/header bar. Then you could specify just left and right navigation buttons to move forwards and backwards through the list of pages. Also the ability to just have a button that then shows a popup menu with a list of pages to choose from.

    By Blogger Phil Wright, at 8:14 am  

  • great idea on separating the view layers in to three - that will make a lot of UI designers very happy (myself included).

    from experience you gotta have a great set of default renderer's/look and feels. also a lot of controls out there lack keyboard support for navigation between screens/tabs/pages.

    Also you might want to change the name:

    also if you want a beta tester :)

    By Anonymous Dave Wraight, at 12:35 pm  

  • The idea sounds look a good one, and the suggestions you have got so far will only MAKE IT BETTER. Nothing like listening to your users, except for listening to POTENTIAL users BEFORE building something.

    Sounds like you are going in the right direction.

    By Anonymous MikeScott8, at 12:50 pm  

  • Sounds interesting. It might be nice to have a pluggable, interface based callback mechanism. For instance, with wizard and browser style navigation there is generally a lot of validation for pre/post page transitions. Since you are starting with a MVC pattern internally, perhaps exposing something similar to consumers might be useful?

    Having event handlers for this stuff works, but makes testing and substitution harder I think.

    Just my random 2 pennies... good luck!

    By Anonymous Anonymous, at 12:32 am  

Post a Comment

<< Home