Andrew's Kitchen - Sliding Into Cookery

by Andrew Guidroz II

Published 1999-04-26    Printer-friendly version

"Glad to hear you're starting a new magazine, Dave. If there is anything I can do to help, just say the word."

"Well, since you're the official Clarion Cajun chef, how about writing up a DevCon Gumbo recipe?"

And just like that, my mouth got me in trouble again.

Here we are, two months after the launch of Clarion Magazine, and still no recipe. Is it writers' block? Lack of a good subject? I have nothing to say? Me??!! King of thread drift? Nope. Dave with one simple request asked for the hardest thing a cook can do.

You see, it isn't so simple, writing a recipe – especially one of mine. By now, everyone around the Clarion internet community knows I'm a Cajun and I cook. I'm no chef and I'm certainly more gourmand (a pig) than gourmet. I cook in my own style that has been influenced by the cooking of my parents and their parents. But how do I convey what I'm doing in words? How do you teach a non-Cajun what color a roux should be? When I say, "Put three onions in" does the person on the other end know what an average sized onion looks like or whether it should be yellow, white, or purple? Does the person reading my recipe know he/she should peel and chop them?

Each cook out there has different levels of experience and expertise. And certainly the regional influence of my cooking adds one more level of complexity to all of this. I really can't write a generic recipe that works for everyone. I write one style for my Cajun friends that cook. I write another for my Cajun friends who don't. And I write in a variety of styles for people who may or may not cook and may live all over the world. But in every recipe I write there is a common goal: each should give clear directions to produce a good meal. Each recipe might have a different route but they all end up in the same place.

This problem isn't so different from the problem we all have when we write software. We tend to write our software with a certain end user or two in mind. But many different people of various skill levels and backgrounds will use our software. They are all trying to get to the same end product. Software is just a tool, a recipe, to take our users from the point of having nothing but inputs (ingredients) and moving toward a finished product: the gumbo of their completed data. Software is really just a dynamic, intelligent recipe and the data stored in your files is the meal, steaming hot and ready to eat.

In theory, this is all great. But certainly no one is going to write separate applications to distribute to different users. How can one application be easily adapted to different users? An interface is needed that can hide information but be easily adjusted for various skill levels. Sliders are perfect for this.

Jeff Slarve wrote an interesting slider class and template back when Clarion first began to support OOP. I took this software, enhanced it, and wrote a different template interface with some additional features.

Figure 1 shows the example application in all three modes.

Figure 1. The example application with the slider at each of the three settings.

To make this slider interface work first register the slider template (jsslid50.tpl). Then in your application create a form. On the form you need a sheet with the wizard attribute set, with tabs for each skill level of user. You may find it easiest to only set the wizard attribute when you're finished creating the information on each tab.

Then populate the slider control template on the window. In the case of the example app I'm including you'll see that I populated a horizontal slider (see Figure 2). The slider needs a field to keep track of the expertise level and I created a local data element called, imaginatively, Loc:Expertise. You can test for the value stored in this variable when you want to know what expertise level your end user is operating at. The next step is to check "Use Slider for Tabbing" and select the wizard sheet (?ExpertiseSheet) so the template knows which sheet contains the various expertise level tabs. That's all you need to do to add this functionality to your program.

Figure 2. The horizontal slider template prompts.

At runtime, moving the slider will select the different tabs. The experienced user can start at the most complex level or move the slider down to see the form in its simplest level. Or the slider will allow the average user to move up in the complexity of the form as s/he gains more experience and confidence.

How does this apply to your software development? One of the products that I have written and support processes information for consumer credit offices. In laymen's terms these are small loan companies. There are various levels of expertise in these offices. In some, you find a manager who has been loaning money for many years and who knows how every little detail of how a loan can affect a customer. On the opposite end, you may have a clerk who has zero experience in the field. The question each of them faces each day boils down to this:

And what would anything written by me be without thread drift? I wrote an app a few years ago that was basically for point of sale. The industry leaders in this business were well known and dominated this DOS market for years. A customer that used these DOS packages approached me wanting a new custom package primarily because of some unique reporting requirements. I wrote the app from a totally new and foreign viewpoint as I had no experience in this type of business. Because of this, the screens were very different from the packages the end users were familiar with. There was a particular type of transaction that occurred approximately 200 times a day in each office. This transaction could have many subtle variations. Conceptually, the end user could go through 27 different prompts in order to complete the transaction. In standard DOS style, the other packages only required a newline to get through these prompts to accept the default. Let me say that a bit more clearly: the end user had to hit newline 27 times in the best case. After sampling an entire month's business, I discovered the best case scenario occurred over 95% of the time. I designed the entry screen for this type of transaction to: ask for an account number ask if this is a special case (newline meant no) And that was all. If this was a special case, we went to the 27 prompt screen. If not, we completed the transaction in two steps. Now, imagine the end users' reaction to this - especially when there were customers standing 10 deep at their counter. And imagine their customers' reaction when service time was cut so drastically. As programmers, we're confronted with a variety of problems that we tend to standardize and normalize. Don't fall into that trap with your user interface.

If a customer borrows X amount of money for Y months, how much is his/her monthly payment?

The manager realizes that varying interest rates, different insurance coverages, and a variety of fees can all be manipulated to change this figure. But the inexperienced clerk has no idea how all of these things effect loans. The clerk isn't even allowed to give certain allowances that a manager can. So why clutter up the data entry screen for a clerk with the wealth of information and control that a manager needs?

This template handles that problem perfectly. The manager has a very detailed tab. The clerk has one with few details. As the clerk becomes more experienced and takes on more responsibility, he can move the slider in the direction of more detail. The manager, conversely, can decide he doesn't need all that complexity for every loan and start out at a less detailed position.

Of course, this is a simple illustration. In the real world, you would test for security levels of the end user (is the clerk allowed to change the interest rate?). But this template can even handle a complex form requiring multiple tabs. That can be easily implemented by placing sheets on each "expertise level" tab.

Lagniappe Lagniappe (lan – nyap') is a wonderful Cajun word. If you went shopping here years ago, the storekeeper nearly always gave you a little something once you made your purchase. A gentleman might receive a cigar. A lady might receive a spool of thread or a piece of lace. Lagniappe is that little something extra you get that you weren't expecting. So, in that tradition, here are three bits of lagniappe.

First, you get a set of classes that illustrate using OOP in Clarion. This is an ABC independent implementation so you can use it in both ABC apps and Legacy apps. Next, you also get a template with some nice bells and whistles including full control of the graduation marks (size, number, lock to graduations) and range setting prompts so you can use the sliders in nearly any type of app.

And the final bit of lagniappe is an interesting Clarion app that illustrates using the slider for the "expertise level" interface. And it isn't just a boring data entry screen demonstrating an invoice or a loan agreement. It is an application that teaches you to cook gumbo assuming three different levels of experience in cooking. I hope you enjoy the application and the gumbo. Welcome to my kitchen!

Download the source code.

---

Andrew Guidroz II, when he isn't traveling around the countryside watching his 2004 National Champion LSU Fighting Tigers, writes software for all facets of the insurance and finance industries. His famous Cajun cookouts have become a central feature of Clarion conferences throughout the U.S. Andrew's Cajun website is www.coonass.com.

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942