<i><font color="#663300">Could someone briefly explain how to use the devnotes feature of Codebook?</font></i>
If I understand you correctly what you are looking for is outlined in the CB Newsletter Vol.2 Issue 1. I have pasted the section that I think will be helpful to you below. It goes back to FEB 1998 so somethings may work differently now. HTH. "Copy from CB NL Begins"
Rapid Application Development Notes Object
Once the prototype interface is completed, it is time to do one of many walkthroughs with the user. It is very important to capture every concern that they may have with the interface. This object, included in SAVIís version of Ed Leafeís eBizEd.VCX, makes taking notes during these walkthroughs a breeze.
Introduction
The software interface is one of the most critical parts of a successful application. There are many right ways and even more wrong ways to create them. Your users could interpret what seems like a perfectly good interface to you, as a less than optimum. One tried and true method of creating a successful interface is to design a prototype and let the users accept it before you write one single line of code, or design one entity relationship diagram. However, you must prepare yourself to record and implement the changes the users may desire Ö after viewing your prototype.
You have several choices. One is to write all of their requests down on a piece of paper. Another is to Alt+Tab back and forth between Word and your application. Neither of these options was as integrated as I wanted this process to be. So I decided to write a short enhancement to Codebook that tightly integrated the note taking process with the newly created interface.
Using the RAD Notes Object in Development
The use of this object, from the developers point of view, could not be simpler. If you are using SAVI Codebook, simply follow these steps:
1. Populate the .cDescriptiveName property of your business object with a name the user is comfortable seeing. For example, if you are designing the interface for an invoice header business object, populate this property with Customer Invoice Business Object. You may wish to leave the ìBusiness Objectî phrase off of the descriptive name value since your users may not know what a ìbusiness objectî is.
2. Create a text file, named DEVNOTES.TXT in the applicationís main directory. Do this by typing MODI FILE DEVNOTES.TXT, type some gibberish in the file, and save it. The content of the file is not important, only its presence is required to ensure the Development Notes object is available on all business objects in your prototype interface.
3. When the business object appears on its form, it will have a white label with blue lettering that says ìDevelopment Notesî. Click on that and the following form appears. Notice that the descriptive name you gave to the business object appears at the top of the Development Notes form. The record that stores the development notes for this business object is automatically created if it does not already exist. It is automatically displayed if the record already exists from a previous note taking session.
This form consists of a simple business object, which contains a text box, an edit region and a command button. The ìBusiness Objectî text box stores the unique identifier for the notes you will take about this business object. The ìNew Notesî button allows you to create a new date time stamp for a new series of notes by a simple mouse click. This comes in handy when taking additional notes on different days Ö it shows a history of note taking interaction with the user. Finally, the development notes themselves are typed into the ìDevelopment Notesî edit region.
Since this interface was designed around the Codebook standard, you can do anything to these notes that you want, Create new ones, Read, Update or Delete existing notes. Previously, I informed you that a note for a business object is created automatically if it doesnít already exist in the table, but donít think you are limited to creating notes only for corresponding business objects. You can press the File | New button and create a new note that defines your To Do list for this prototype review session as well.
The nice thing about using the Codebook interface is that multiple forms for multiple business objects can be opened at once. You can also use the navigation buttons to navigate between the different notes created for the application. Using this method, you can capture all of the criticisms and suggestions that your users may want to make about the interface you have proposed. Most importantly, these notes can never be accidentally thrown away, or lost. They are always with the application.
Conclusion
The most amazing thing I found out about this process was the massive amount of detail I was able to extract out of the users once they were in front of a ìworkingî application. I have sat in design meetings where white boards were used to ìcreateî interfaces, and I have recently had the chance to use this method. The two cannot be compared. Something happened to the users that sat in front of the ìworkingî application that did not occur in the whiteboard design meeting. It was as if just setting in front of the applicationís interface, viewing an approximation of what they will see in the final application, opened my clients up like flowers. I built a prototype interface, using the previously documented method, from a one page, type written document. Once I was completed with the interview, I had 15 full pages of type written information (in Word) about the same application (it was a small system).
Before a single line of code was written, I had a detailed requirements document that specified exactly what the users wanted. I also had their approval on the first iteration of the interface. Probably one of the greatest benefits of this approach was to make the userís feel like they played a significant part in the design of their own system. They were excited to see the finished product Ö they became champions of their own software. This made my job much easier.
I have said this before and Iíll say it again here. Programming, in itself, is NOT the most difficult work of developing applications Ö getting the users to tell you WHAT they really want is one of the most difficult tasks we are ever faced with. Hopefully, this enhancement will ease the burden of discovering what that what really is Ö at a minimal cost to both you and your client. It will, hopefully, cast the new system in a very favorable light as early in the development process as possible.
If you are interested in receiving the software for this enhancement to Codebook, simply fill out the application form at the end of this issue and mail it to SAVI. You will receive download instructions, complete with passwords, via eMail.
Charles T. Blankenship is president of Software Assets of Virginia, Inc (SAVI), a computer consulting firm that specializes in developing mission critical Visual FoxPro based applications using Codebook technology.. Phone: (757) 853-4465, Internet: ctb .at. savvysolutions .DO.T com, Web Site: www.savvysolutions.com, CompuServe 76132,2575
©2002 Al Lambert |
|
