In addition to users, my app has three separate entities. They are all master/detail format in which there is a single master with fields common to the entire entity and many details (typically hundreds) each of which is owned by a single master. All the master and detail records have several fields; one detail record type has dozens. There are four operations: New which allows users to create new records, Update which allows users to change fields on existing records, Display which allows users to see the information but not add, change or delete anything, and Delete which allows users to delete existing records. If they delete a master, the app deletes all its details as well. In this case, the app displays the master fields as well as a message informing the user of the consequences and requires confirmation prior to the delete.
The app has six record types (three masters and three details). My question is:
Should I have four simple, separate pop-ups to handle the four operations with reusable elements where I can or one more complex pop up for each record type that handles all four operations using custom states and conditionals?
The first approach with 6x4 pop-ups is simpler and faster to implement but complicates future maintenance since changes to a single record type may have to be made in four different pop-ups. The second approach has all operations, fields, and editing criteria in one pop up (six pop ups) which should simplify maintenance when fields are added and edit criteria are changed (very likely for this app).
I would appreciate your thoughts on which way I should structure this. Thanks for any guidance you can give me.
tl;dr
Despite the benefits, sharing an common interface has some not-so-obvious hidden costs.
Looks like you are trying to build a ‘CRUD’ app (Create, Read, Update, Delete). I don’t think anyone can answer exactly what is best for you, but many have done this before and so there is some guidance available out there. You may want to search crud design on these forums for more ideas.
You are asking some good questions. It looks like you want to keep it maintainable and D-R-Y (Don’t Repeat Yourself) as is possible.
I’d propose some additional questions which may steer you closer to the direction you are going for.
How many fields could you imagine changing/adding to in your custom types over times? How frequent ? Do you anticipate 5% change to fields? 50% change? If the latter, building a common interface seems like the better choice.
Is a ‘Create’ action truly the same as an ‘Update’ action? Oftentimes, when establishing a new db record there is one-time configuration for a ‘Create’ operation that you don’t necessarily want to present the user again such as with the ‘Read’ or an ‘Update’ interfaces for example.
.
Expanding on this further: You can, of course bury conditional logic for each common page elements and hide/show/lock fields, based on the mode you are in (typically ‘Create’, ‘Read’, ‘Update’), but this can be surprisingly cumbersome to maintain if you don’t have a crystal clear understanding of what you want to achieve ahead of time and a well-built template that won’t require revision over and over (your first attempt at this will likely require revision). So you wind up making the same edits to elements multiple times anyways except its more complex to implement and follow than simply creating multiple popups/pages for each operation. There are a lot of not-so-obvious ‘tricks’ in the editor to making conditional logic and pages scalable, just building it out 3 times is often more straightforward, even if it isn’t as D-R-Y
How good is your memory? One of the biggest things I’ve come to understand with bubble and development in general is that ‘Maintenance’ isn’t just about trying to avoid a few minutes (or even hours) of doing repetitive clicks when adding new fields or making changes to your CRUD app. Its about preserving a crystal-clear intent in your application’s design so that others (and yes, even you) will be able to remember months and years from now what you have created. It is not that building a single CRUD interface is difficult to maintain, just understand has the potential to be far more complex and difficult to remember.
Side note:
Be careful with implementing a lot of popups. There are some gotchas with launching multiple popups at the same time, scrolling, etc. For example. If want to show the user a ‘are you sure?’ popup after clicking a ‘dangerous’ button inside an existing popup, you’ll notice that the background overlay doesn’t apply to the new popup and you can run into UI issues where its not obvious which popup has focus. You can hid an existing popup, but then you’ve got to keep track of that if the user cancels (complex).
Thanks for the thoughtful response. The app is CRUD on three master/detail structures plus some additional operations. Normally there won’t be more than two pop-ups active at one time. This is an MVP so there will be substantial enhancement. Usually, I put a high priority on DRY but in this case, I’m leaning towards many simple rather than few complex. I’ve been experimenting with the logic necessary to have a single multi-operation form and it’s looking ugly.
One of the biggest things I’ve come to understand with bubble and development in general is that ‘Maintenance’ isn’t just about trying to avoid a few minutes (or even hours) of doing repetitive clicks when adding new fields or making changes to your CRUD app. Its about preserving a crystal-clear intent in your application’s design so that others (and yes, even you) will be able to remember months and years from now what you have created. It is not that building a single CRUD interface is difficult to maintain, just understand has the potential to be far more complex and difficult to remember.