One To Many Forms (or Thinking Differently Adds Value)
Category Domino
I recently redesigned one of my organization's earliest Notes/Domino apps. We use Domino as a home base for a lot of our work and this particular application is a sort of contact manager/customer account information repository. It is the single point of 'truth' about any of our customers.
Anyway, the redesigned feature that I am most proud of in this application is how I handle data entry for customer addresses.
This is not a ground breaking Notes application development technique, I know I have seen many applications that use the general concept quite frequently. But I present it here so that others that haven't seen it done have a reference. A little bit of thought, a good understanding of your users' usage patterns, and a little coding thrown together can generate a bunch of good will from your users.
Each customer we have a corporate policy of requiring entry of four addresses (legal/physical/street, mailing, accounts payable, and accounts receivable;) but we accept more if we need them. Examples of additional records might be plant locations, deductible billing address, safety office, etc.
In the old app the addresses where stored as separate Notes documents, and each one had a reference value ( the organization document's original UNID) as a foreign key. The primary complaint about this requirement was not that we didn't need the addresses, but rather that the data entry process was cumbersome at best.
First, the user would create the customer document and save and close it. Then, they would open it back up, and click a button to add each of the required addresses (note that there is nothing other than a corporate policy that requires the addresses get entered.) The addresses were accessible via a single category embedded view on the customer document. Originally, there was no way to 'copy' the data from one address to another...almost immediately after I was hired, I added a button that allowed the user to select an already entered address as the basis for the new address being entered. I would estimate that ~50% of the customers have the same address for all four required addresses and this button caused great joy in the company. But my users hadn't seen nuttin' yet!
Because the address documents are so important to a variety of other applications (both Notes and traditional development based), my redesign had to create individual documents for each address. But I had to come up with a better way of managing the data entry process and I wanted to add a validation mechanism to ensure that the addresses actually got entered and created.
Here is what I came up with:
On my customer form, there was already a tabbed table that had a tab for 'Addresses'...it was where the embedded view sat. To maintain consistency with the old application, that was where I planned for all address entry/maintenance to occur.
First, I pulled the embedded view off and placed it on a subform (AddressDisplay) all by itself.
Next, I created a new subform (AddressEntry) that has four sets of address entry fields (Address1, Address2, AttentionLine, City, State, Zipcode, PhoneNumber, TollFreeNumber, FaxNumber.) Each of those field names were extended with a three character 'type identifier' (_LG for Legal Address, _MA for Mailing Address, _AP for Accounts Payable and _AR for Accounts Receivable.) I added default values, field validation, and input translation where appropriate.
(There is actually more to this subform (the fourth address set) but it didn't fit in the screen capture.)
Back on the customer form, I added a computed subform resource identifier that calculated to AddressEntry when the document was new, and to AddressDisplay at all other times.
Also, on the AddressEntry subform is a button, immediately following the first address set that, when clicked, will copy the first address' info to the other three sets.
Finally, on the customer form, I added code to the PostSave event that reads the address sets and creates individual documents from each address set, and then deletes the fields from the customer document.
I use this same basic technique for associated people as well; from the same customer document.
Here is a Wink created SWF that demos this technique (this is my first attempt at using Wink...pretty nice for a 'free' tool...but I gotta figure out the timing stuff.)
I recently redesigned one of my organization's earliest Notes/Domino apps. We use Domino as a home base for a lot of our work and this particular application is a sort of contact manager/customer account information repository. It is the single point of 'truth' about any of our customers.
Anyway, the redesigned feature that I am most proud of in this application is how I handle data entry for customer addresses.
This is not a ground breaking Notes application development technique, I know I have seen many applications that use the general concept quite frequently. But I present it here so that others that haven't seen it done have a reference. A little bit of thought, a good understanding of your users' usage patterns, and a little coding thrown together can generate a bunch of good will from your users.
Each customer we have a corporate policy of requiring entry of four addresses (legal/physical/street, mailing, accounts payable, and accounts receivable;) but we accept more if we need them. Examples of additional records might be plant locations, deductible billing address, safety office, etc.
In the old app the addresses where stored as separate Notes documents, and each one had a reference value ( the organization document's original UNID) as a foreign key. The primary complaint about this requirement was not that we didn't need the addresses, but rather that the data entry process was cumbersome at best.
First, the user would create the customer document and save and close it. Then, they would open it back up, and click a button to add each of the required addresses (note that there is nothing other than a corporate policy that requires the addresses get entered.) The addresses were accessible via a single category embedded view on the customer document. Originally, there was no way to 'copy' the data from one address to another...almost immediately after I was hired, I added a button that allowed the user to select an already entered address as the basis for the new address being entered. I would estimate that ~50% of the customers have the same address for all four required addresses and this button caused great joy in the company. But my users hadn't seen nuttin' yet!
Because the address documents are so important to a variety of other applications (both Notes and traditional development based), my redesign had to create individual documents for each address. But I had to come up with a better way of managing the data entry process and I wanted to add a validation mechanism to ensure that the addresses actually got entered and created.
Here is what I came up with:
On my customer form, there was already a tabbed table that had a tab for 'Addresses'...it was where the embedded view sat. To maintain consistency with the old application, that was where I planned for all address entry/maintenance to occur.
First, I pulled the embedded view off and placed it on a subform (AddressDisplay) all by itself.
Next, I created a new subform (AddressEntry) that has four sets of address entry fields (Address1, Address2, AttentionLine, City, State, Zipcode, PhoneNumber, TollFreeNumber, FaxNumber.) Each of those field names were extended with a three character 'type identifier' (_LG for Legal Address, _MA for Mailing Address, _AP for Accounts Payable and _AR for Accounts Receivable.) I added default values, field validation, and input translation where appropriate.
(There is actually more to this subform (the fourth address set) but it didn't fit in the screen capture.)
Back on the customer form, I added a computed subform resource identifier that calculated to AddressEntry when the document was new, and to AddressDisplay at all other times.
Also, on the AddressEntry subform is a button, immediately following the first address set that, when clicked, will copy the first address' info to the other three sets.
Finally, on the customer form, I added code to the PostSave event that reads the address sets and creates individual documents from each address set, and then deletes the fields from the customer document.
I use this same basic technique for associated people as well; from the same customer document.
Here is a Wink created SWF that demos this technique (this is my first attempt at using Wink...pretty nice for a 'free' tool...but I gotta figure out the timing stuff.)
|
Permalink
| Comments (2)
| TrackBacks (0)
Bookmark :
Comments
Posted by Charles Robinson at 12:57:32 PM on 05/21/2007 | - Website - |
First, and most important, the users didn't like the idea...it was too different from what they were used to doing.
Second, we have a very odd set of rules about who can edit what and the business rules regarding editing is built into the PostOpen (only a little bit here) and QueryModeChange (mostly here)events. I realize that those event fire in the embedded editor as expected, but our particular usage in this particular case presented some 'problems' that could have been over come, but it would have broken consistency with how we do other like processes elsewhere in the application.
But ultimately you are correct and the result makes for a very nice UI.
Posted by Andy at 02:08:29 PM on 05/21/2007 | - Website - |