Building a ribbon control looks quite a daunting task. I signed up to licence the Office 2007 User Interface Design Guidelines which weigh in at a hefty 119 pages; using up most of the blue ink in my printer because of all the screen shots. The guidelines are excellent and provide the perfect design specification. Certainly better than any actual spec I have ever received when working for a company.
I am going to adopt the same approach I always use when faced with a large chunk of work. Break it down into bite sized pieces and just nibble away. The biggest danger in my experience is trying to solve the entire problem in your head right at the start. But its just too big, your never going to manage it and even if you did the solution will have to change and evolve as you go along anyway. Unless you have written this sort of control before you just cannot anticipate all the little snags your will come across.
No, much better in my experience to combine the benefits of small chunks of work and refactoring. This is the development cycle I always use.
1) Identity a small unit of work, no more than 1 days effort.
2) Implement and refactor the code as needed.
3) Test and fix until the control is fully working.
I always give myself small milestones that take at most 1 day and often much less. Sometimes I will achieve the above cycle several times in a day. I cannot think of a time when I have not been able to break down a task into smaller and smaller chunks until they are less than a day each.
Remember these units of work might not do anything useful as far as users or other developers are concerned, they are for your use only. Knowing that I am hitting my milestones on a daily basis is great for keeping my motivation high and feeling like I am making progress towards a very distant finish line. This approach works especially well for user interface development as you actually get to see something happening on the screen!
The second step is to remember to refactor your design when implementing. This is so important I cannot stress it enough. So I’m going to say it again, refactor your design! At the end of each implementation cycle the code should look as if the entire control was designed that way from the start. It should be impossible for an outsider to look at the code and notice that it was written piece meal and not designed in its entirety up front.
This is tough to achieve because it means you often revisit and rework the same code several times. Resist the temptation to break your own architecture! If you break your own architecture before you finish the first release what chance have you of maintaining and improving it in the future? Not much.
Last up is the testing and fixing of all bugs before starting another cycle of work. Because your completing a work cycle most days it means your control is always in a buildable and even shippable state. Sure, it might not have much functionality after the first week but what you have should be production quality. Your aim is to ensure your code and design is gold standard all the time. Sounds impossible but actually is very easy it you adopt that approach from the outset.
In order to show this in practice and get feedback during developement I will blog regularly about development of the ribbon control. Starting tomorrow you can follow progress as it happens.
