Rethinking the New Event Dialog
Apr 11, 2022 5:24:31 GMT -8
Post by Uncle Buddy on Apr 11, 2022 5:24:31 GMT -8
Currently Treebard has an input for a new event at the bottom of the conclusions table and an OK button next to that. Actually the button says "NEW EVENT OR ATTRIBUTE". When you start typing an event type such as "residence" or "marriage" into the field, it autofills. When you press the button, a dialog opens for additional details. If it's a generic event such as residence that refers to only the current person, the inputs are for date, place, particulars and age. If it's a couple event, the dialog has those fields as well as fields for the partner's name and age.
The dialog has been problematic from time to time, though in general it has been working for a long time. Today, due to a somewhat unrelated refactoring that touched its code, I had a problem with it that lit up the little old light bulb up in my head. One thing led to another and now I can't wait for tomorrow so I can refactor the new event dialog. I mean completely get rid of it. Here are the notes from my do list, which started with a mere do list item, "Fix this," and grew from there into a mind-blowing revolution of genieware overhaul:
The dialog has been problematic from time to time, though in general it has been working for a long time. Today, due to a somewhat unrelated refactoring that touched its code, I had a problem with it that lit up the little old light bulb up in my head. One thing led to another and now I can't wait for tomorrow so I can refactor the new event dialog. I mean completely get rid of it. Here are the notes from my do list, which started with a mere do list item, "Fix this," and grew from there into a mind-blowing revolution of genieware overhaul:
Make sure it's possible to create a new event of any kind, currently couple events can't be created. REDO THE SYSTEM for predicting the next event id that will be needed, this is the 2nd time in a week it's cost me time. The fix last time was to make it worse (more dependent on a guessed id by incrementing a guessed-at value twice (sometimes): a gambit guaranteed to rot in hell.
THE RIGHT WAY TO FIX THIS IS TO REMOVE THE PLACE INPUT FROM THE NEW EVENT DIALOG COMPLETELY. Then there will not be 2 dialogs opening when the new event dialog closes, in case the place validation dialog is needed, which it will no longer be. The user can easily edit the place once the event is added to the events table. IN FACT, TO KEEP DIALOGS AS SMALL AS POSSIBLE, a new event dialog for example should ONLY CREATE A NEW EVENT and do nothing else, then user can add age, place, etc in events table.
THE REAL PROBLEM THOUGH--the reason a new event id has to be predicted--should be pinpointed as well as the reason the max existing id has to be incremented twice, which is due to an ADD PERSON dialog in case one of those opens too. So there are 3 issues to redesign about the new event dialog: 1) remove place input, 2) WHY CAN'T THE NEW ID BE GOTTEN BY CREATING IT INSTEAD OF GUESSING IT, and 3) if a new person is to be added during the process of inputting a partner to a new couple event dialog, DEFER MAKING OF THE NEW PERSON'S BIRTH EVENT till after the new event is created as it is a secondary thing that's interfering with the primary purpose of the new event dialog.
I'M PRETTY SURE THAT THE ONLY REASON THE ID HAS TO BE PREDICTED is so that a place input can be validated before the dialog closes, so removing the place input will solve a whole collection of problems. Currently the new couple event dialog contains inputs for date, particulars, current person age, partner, partner age, and place.
THE TIME IS NOW TO GET THE POINT: input-dialogs-with-big-forms is not what Treebard is like. Treebard is a story-on-a-page with easy, convenient, fill-in-the blank, display inputs that show you what you input right where you input it, with an absolute minimum of validation pop-ups and clicking needed to go looking for what you had input elsewhere. The only thing the couple event dialog needs is partner info: name and age. The way to keep Treebard's code manageable and its GUI simple is to avoid redundant inputs.
THIS COMPLETELY ELIMINATES THE GENERIC NEW EVENT DIALOG ALTOGETHER: IT WAS NEVER NEEDED. All its inputs already exist in the events table after the new event is created. The dialog shouldn't open at all except to add partners and their age.
The question now is: what's the extreme that this slimming-down attitude could be taken to, and why should I go or not go to the extreme?
The extreme is to find a way to not need the partner name and age at the time the event is created: just create the event. The only thing in the database finding (conclusion/event) table that 1) can't be null or empty and 2) can't have a default value is the event_type_id. Even the partner name and age can be empty. But there's no kin column anymore (and never will be) so what could be dreamt up for adding the partner later?
Obviously the user in this case would just go to a permanent events input in a tab or open a dialog when he wants to edit the event by adding stuff that can't be added in the events table since it has no kin column.
The first thing that occurs to me (since a whole tab for inputting two things is a waste of space and I already rejected the dialog for the same reason) is to add the partner to the families table since adding a couple event with a null partner already creates a blank input for the partner to be added. THEN IT WILL WORK THE SAME AS THE FOSTER PARENT: create an event, then input the partner in the new input that appears in the families table. Let's hear it for symmetrical use-patterns from one functionality to the next.
Also, to augment the id tips which are helpful in correlating event rows with people in the families table, corresponding rows in the families table & events table should BOTH HIGHLIGHT AT THE SAME TIME when either one is pointed to with the mouse. This would make it dead simple to add any event, completely free of dialogs, which gives the user total flexibility to add the partner's info anytime he wants.
THE RIGHT WAY TO FIX THIS IS TO REMOVE THE PLACE INPUT FROM THE NEW EVENT DIALOG COMPLETELY. Then there will not be 2 dialogs opening when the new event dialog closes, in case the place validation dialog is needed, which it will no longer be. The user can easily edit the place once the event is added to the events table. IN FACT, TO KEEP DIALOGS AS SMALL AS POSSIBLE, a new event dialog for example should ONLY CREATE A NEW EVENT and do nothing else, then user can add age, place, etc in events table.
THE REAL PROBLEM THOUGH--the reason a new event id has to be predicted--should be pinpointed as well as the reason the max existing id has to be incremented twice, which is due to an ADD PERSON dialog in case one of those opens too. So there are 3 issues to redesign about the new event dialog: 1) remove place input, 2) WHY CAN'T THE NEW ID BE GOTTEN BY CREATING IT INSTEAD OF GUESSING IT, and 3) if a new person is to be added during the process of inputting a partner to a new couple event dialog, DEFER MAKING OF THE NEW PERSON'S BIRTH EVENT till after the new event is created as it is a secondary thing that's interfering with the primary purpose of the new event dialog.
I'M PRETTY SURE THAT THE ONLY REASON THE ID HAS TO BE PREDICTED is so that a place input can be validated before the dialog closes, so removing the place input will solve a whole collection of problems. Currently the new couple event dialog contains inputs for date, particulars, current person age, partner, partner age, and place.
THE TIME IS NOW TO GET THE POINT: input-dialogs-with-big-forms is not what Treebard is like. Treebard is a story-on-a-page with easy, convenient, fill-in-the blank, display inputs that show you what you input right where you input it, with an absolute minimum of validation pop-ups and clicking needed to go looking for what you had input elsewhere. The only thing the couple event dialog needs is partner info: name and age. The way to keep Treebard's code manageable and its GUI simple is to avoid redundant inputs.
THIS COMPLETELY ELIMINATES THE GENERIC NEW EVENT DIALOG ALTOGETHER: IT WAS NEVER NEEDED. All its inputs already exist in the events table after the new event is created. The dialog shouldn't open at all except to add partners and their age.
The question now is: what's the extreme that this slimming-down attitude could be taken to, and why should I go or not go to the extreme?
The extreme is to find a way to not need the partner name and age at the time the event is created: just create the event. The only thing in the database finding (conclusion/event) table that 1) can't be null or empty and 2) can't have a default value is the event_type_id. Even the partner name and age can be empty. But there's no kin column anymore (and never will be) so what could be dreamt up for adding the partner later?
Obviously the user in this case would just go to a permanent events input in a tab or open a dialog when he wants to edit the event by adding stuff that can't be added in the events table since it has no kin column.
The first thing that occurs to me (since a whole tab for inputting two things is a waste of space and I already rejected the dialog for the same reason) is to add the partner to the families table since adding a couple event with a null partner already creates a blank input for the partner to be added. THEN IT WILL WORK THE SAME AS THE FOSTER PARENT: create an event, then input the partner in the new input that appears in the families table. Let's hear it for symmetrical use-patterns from one functionality to the next.
Also, to augment the id tips which are helpful in correlating event rows with people in the families table, corresponding rows in the families table & events table should BOTH HIGHLIGHT AT THE SAME TIME when either one is pointed to with the mouse. This would make it dead simple to add any event, completely free of dialogs, which gives the user total flexibility to add the partner's info anytime he wants.