| < Free Open Study > |
|
"Don't plan with a rainy day in mind".
--Oswald ChambersSOMEONE ONCE APTLY SAID, "You only get one chance to make a good first impression". That being the case, the add-in developer needs to give a lot of thought to his or her add-in's user interface (UI), the means through which users access the functionality of the add-in. If the interface is not intuitive and easy to use, users may give up or simply decide not to bother with the add-in. You cannot count on their reading a manual, or even consulting a help file. With regard to reading a manual, for the most part, manuals are not provided, much less printed. This has been the case with most software products for several years now. And as to consulting a help file, my feeling is that if I have to consult a help file to deduce how to use the basic functionality of a program, the UI is not properly designed, and the program has two strikes against it before I even start to try to use it.
Until now, I have used the same basic UI in all of this book's add-ins. The UI has started with one menu item added to the Tools menu. In the book's first add-in, which was developed in Chapters 2, 3, and 5, I launched a form with aTreeView control. The TreeView provides a great menu, especially when you use parent and child nodes so that the menus can be collapsed, thus providing many menu options in a minimal amount of space. So, you have seen two types of add-in interfaces. In this chapter, I expand on both types and introduce some other possibilities.
| < Free Open Study > |
|