Sep-20-2020, 01:17 PM
(Sep-20-2020, 02:47 AM)Larz60+ Wrote: I think you need to simplify your logic on paper, and then continue.
I got lost after clicking on search in second window.
The code doesn’t show what else happens after search because it wasn't relevant to the question. It also didn't show the rest of the center search section where the user defines what and where they are searching for the datan or does it show the reports that can be created from the data.
Pseudo code for the member search screen
User selects which fields to display via checkboxes in the left sidebar. The fields correspond to sets of fields in the database. Reason for selection is that the user does different reports on different sets and needs more flexibility than a fixed display will allow.
User selects criteria in the top center search section to limit how many result records are returned. These criteria include which registry the user is working in, the status of the member, type of membership, join date, renewal date, name, flock or herd ID, region etc. There are more things that can be used to limit the results. Reason is that reports are nearly always on a subset of current and previous members not on the entire population of the exiting member records. There are multiple registries in each database file each with its own set of members.
Once all selections are made the search button is clicked and the results of the query are displayed in a frame below the top center search section.
To further refine those results, if required, the user can select only individual records of the view to go into the report. reason is that sometimes the user has to create a custom report that give specific informaiton on only a few members of a larger group. For example the user may only want a contact list of memebrs with animals of a certain bloodline within a certain region. So this search gets the members in that region with animals but then it's the knowledge of the user who can say there 6 people have animals of that bloodline ut these 3 other ones do not and only report on the 6 that do.
There are far more subsets of options than it is possible to program in so I have to allow the user to do final selection based on their own knowledge of the individuals and animals contained in the database.
Reports are selected by choosing from among the options that are also on the left sidebar below the selection of what fields to display.
I run this basic workflow many times a month using a software program that is very difficult to use. My program will replace that package and has been designed for a much simpler interface even though it seems convoluted. To do the same thing in the current system requires several screens, selecting items, testing, then writing out the results to an Excel file for further processing into the report formats needed.
I've already tested by hand the query used to get the data and display it and it's much faster to do than it is to describe when I am actually working with the database. There are several of us who actually work with this data regularly and we all agreed on the format of the program I am working on and the UI I describe above as being much simpler to use than the existing system.
The advantage I have in doing this is I have the actual users of which I am one. I can test it in real life on our real data and see how it actually works in practice. I've been mirroring the existing system for the past 6 months but I do all the work to select what fields to displau, edit and create reports by running queries I write by hand directly on the database. Any time I find something I need to do that I haven't dealt with already in my functional spec for the program it's been added. I'm not sure I can make it more simple as it's already a lot simpler than the program I hope to replace and more intuitive to use. It does depend on the user understanding the underlying data, or at least what it contains, not necessarily the structure.
