in this example, the selection option is a tour bus. the user can select 1 bus, or as the instructions say, can select multiple buses. after selecting a bus, then they can select one of the several reports. in addition, there is a email button, and word button. selecting the word button launches ms-word in merge mode. selecting the email button launches the email client with all of the email names already inserted to the cc/bc field.

in the following example, i don't use the report listbox trick. the user is simply presented with a bunch of selection options. there is actually only two reports, and depending on what options the user selects, a different report is launched. the fact of a different report being launched is not known by the user. the "edit" list button brings up the *same* selection in a datasheet view (actually a continuous form). this datasheet looks very much like the report, and thus since the report is for someone to work with, they might as well work the list on the screen. the continues form becomes a select list. in fact, each sales rep spends a major portion of their day in this "edit list". while some options are hard coded, several are based on the database.

the following example uses 2 calendar 8 objects to select the date. in fact, i never allow the user to type in the date for report selecting. there is no need when we have such a nice interface available. it also reduces selection errors since mm/dd/yyyy, or dd/mm/yyyy can not be mixed up.

since we are using forms, then you can also make things a bit easier by giving the user some "steps". again, the whole idea here is to make things user friendly. while not quite a wizard, attention is placed to the "order" in which things are to be done. this can reduce the learning curve to a form by a lot. here is an example of my common use of steps.

in some cases i don't have room for the start/end date. in those cases i actually launch a pop up form before the form appears. the user selects two dates, and then the form with options opens. i have a re-useable start/end date form that i use. the dates can still be changed. in the below example, we later added some code to export the data to a palm pilot. again, creating forms that allow the user to select data for reports means i was able to leverage this, and simply add a button for exporting data to the palm pilot.

in all of the above examples, the user never has to type in anything to select options for a report. this approach makes the application easy to use, in fact fun to use. in addition, it also means that very little code needs to be written to check for user input errors. in fact, the user can't make a input error, since the user is only presented with available options.

if you have a text box prompt that searches for a city, then all kinds of things like quotes, a extra comma and several other things the user enters can really mess up the sql search. if you give the user a combo box, then that error can't be made. this is not always practical, but the above examples have no text box prompts.

the other important point here is that i frequently use a list box for the report name. i can in general add new reports to the application, and not have to modify the report form. the table that has this info is only 4 fields. one of the fields defines the form it belongs to, the other field is the report name, and of course the "description" that the user sees.

at the end of the day the goal here is to reduce typing, and hide the complexity of the application to the user.

more rides screen shots?/a>

home