Yes. This is an update of part of a QA application. Currently, data is originally entered into one QA database, then certain fields are copied to a QA database called Status. I'm not sure of the full functionality yet, but it is my understanding that at some point certain fields from Status are then copied to a third QA database to do billing and/or they are copied back to the original QA database.
The Sesame application will basically be replacing the Status portion only. At the top of the main form is an "Information Bar" containing three rows of fields equivalent to the form QA Status uses. Data that will be ported back and forth to QA will be entered and updated in those fields.
Below the Information Bar is a set of 9 tabs. The first, 1. Home, contains about 3 additional fields that interact with QA. The main one is a multi-line text field called Status Report.
Tabs 3-8 contain new fields that will not be ported back to QA.
The second tab is 2. Search. This has a second set of LE's tied to the same fields as the LE's in the Information Bar. In other words, the Surname LE in the IB and Surname LE on the search tab page both are tied to the Sesame db's Surname field. The Search page also duplicates ties to some of the new fields. There are no LEs on the Search page that are not on some other page also.
There are a variety of reasons why I have a search tab page:
First, this is a super-political work environment, where if the choice is "showing who's boss" or doing something logical, logic loses. If anyone complains even once, instead of the owner saying, "Let's see what we can do about this or if it's even worth looking into," the immediate reaction is to demand specific changes without looking at the overall form, etc.--from someone who has no idea of how to design or program.
Second, on the Search page (1) I have duplicated the fields they are most likely to actually use for searches, (2) made them longer for easier input to create Retrieve Specs, and (3) grouped them into search criteria types. I.e., Name-related fields are in one group surrounded by a labeled box, File Number/Account Number-related fields are in another group, Activity criteria are in a third group (Last update, Follow-up, Person who updated), and Type/Amount-related fields are in a fourth group.
Third, the logical grouping for data input and for searching will be different, so creating a Retrieve Spec with the data-entry form would be a pain.
Fourth, many of the data-entry LEs on other pages use combo boxes (and I won't be telling them they can add other text). I really don't want people updating records from the LEs on the Search page because that will let them add non-normalized data.
Fifth, I think that if a tab is labeled "Search", it is reasonable for the user to assume that making entries there won't change data.
Sixth, I'm sure the users (including me) will generally want standalone form mode, which is a lot less cluttered. Even just working with a copy during design, I am finding it confusing trying to remember when I'm in search mode and when I'm in update mode. (I do realize that the fields all clear when search mode initializes.) I'm still trying to figure out how to have @Mode() automatically update an indicator.
What I'm probably going to do once I figure out how to do all of it is put two command buttons on the Search page for Prepare Search (equivalent to pressing F7) and Begin Search (equivalent to pressing F10) and have the Search tab automatically switch to Search mode when it receives focus unless the user is already in Search mode.
In other words, with a Search tab, the normal reaction will be to click that to start a search. Doing that will automatically switch to Search mode. Most searches can be set up only using that page's LE's. If the user needs others, she'll click on other tabs and fill in those fields. Then she'll click Search again to get to the Begin Search button. Because it will already be in Search mode, it won't re-initialize Search mode. (Of course, the user will also be able to use F7 and F10--I don't plan on disabling those.)
|