Crud Patterns

Typical patterns and/or design issues to addrress regarding CrudScreens (typical editing, search, and report forms and tools).

TableBrowser - This topic covers table-browser patterns, features, and issues. (Click on topic for more info.)
QueryByExample - Open-ended or semi-open-ended technique using a form-based predicate-like query techniques. (Click on topic for more info.)
Reports with totals and sub-totals, with the detail optionally suppressible.
- Web-based products are often expected to be drill-down-enabled, meaning if you click on a given title or cell's hyperlink, then a more detailed or applicable view/report is displayed.
Look-up lists - Often there is a need for pop-up look-up lists or object "finder" screens that help the user find a given value, such as a product code. Simple lists can be pull-down lists, but often a more complex approach is needed, such as a string-matching or QueryByExample apparatus.
- (PageAnchor lookup-update) One of the trickier issues is when a user wishes to add to a list or another entity that is used for current look-ups while in the middle of a transaction. You can make a policy rule they have to save partial results (which can complicate validation) and go to the other entity to add new item and then come back, but this is a not very friendly. Thus, you may have to allow multiple simultaneous transactions with "list refresh" capabilities so that when the entity used for look-up is finished, the new item is available (visible) to the original transaction by some means, such as an automated refresh or the user doing something to refresh the selection panel(s). Automated refreshes can be tricky to program because the user could be in the middle of scrolling etc. A compromise may be a message that the list/source has been updated, with instructions on how to refresh. Thus, one transaction session must cross-communicate with another.
Edit forms - Forms that allow complex data-entry and editing. A TableBrowser can be used for simpler data editing, but can be cumbersome for complex and involved data. More on this below.
- Validation - On edit forms, error message(s) may if there is a problem with the data inputs.
  - Field-specific error markers or messages - Make sure you leave or make room on the form for them. Some kits block content because space was not allocated.
  - Be flexible on spacing and telephone numbers. For example, don't be picky about whether a "1" or not is entered in the phone number unless there's a good reason. Allow people to put spaces or dashes in credit card numbers.
  - Some error messages will be general to form of multi-field. For example, if the user must enter either a phone number or an email address, it may be better to put the message at the top of the form rather than next to each field to avoid confusion.
Concurrency and/or Versioning
- It's possible that two or more authors may inadvertently attempt to edit the same existing record(s) at the same time. Possible ways to handle this include:
  - Ignore this issue and allow one to over-write the others' "save" without warning.
  - Warn the subsequent writer(s) that the record(s) were recently changed by others and give them a chance to cancel.
  - Allow draft or alternative versions to be saved if there is a conflict, which gives parties time to work out the differences without having to start the input all over again. The options may resemble source-code version managers.
Deletion and Dependencies
- Consider a warning prompt and related dependency investigation reports if deleting children or dependent records
- Cascading deletes (built into many RDBMS)

Cross-cutting Concerns

Security - Certain people/groups may be forbidden access to read or write certain information. The granularity can be as large as application level, form level, or as small as field level. For web-based forms, one must be mindful of injection attacks.
Sub-set display - Often certain groups of people and/or the options selected dictate the hiding or showing of various options/forms/fields. This is often a big source of "tweakiness" in terms of both user "type" management and display issues, and thus can result in convoluted business logic in the code, and developers turning prematurely grey.
Working with legacy databases - Often one doesn't have control over the database design such that an archaic or convoluted schema must be used, and various translations and custom fiddling is needed to map back and forth between the application at hand and the existing database. In other words, there is a very rough match between our application's elements and layout and the database's elements and layout. Working with complex primary keys can be a real headache. Legacy databases also tend to have or need tricky compound keys, which brings us to the next item:
Compound keys that may involve multiple entities. See TheRadBottleneck for specifics.
Updating Look-up "list" sources while in the middle of transactions. See above near PageAnchor lookup-update.

UnderConstruction

Partial Saves - Sometimes for long forms one may not have all necessary information to finish a record or transaction. Rather than reject the whole thing and force the user to start over later, some kind of holding area or "incomplete" status can perhaps be used. An alternative is to break long forms into smaller ones and validate each as a unit. This may not eliminate the need for re-keying, but reduce it using DivideAndConquer.
- Long forms are generally a yellow alert (smell) in my opinion, especially if they are complex. But managing the intermediate or partial input "image" is still a concern that has to be dealt with in some way. The interaction among different segments can get complex such that all-or-nothing validation of sub-forms can be a hindrance. The user may be "stuck" such that they cannot fix A until they fix B, but they cannot fix B until A is fixed. (There may technically be a logical way out, but it may not always be apparent to a user.) Some kind of "soft" validation should be supported until the final "Submit" or "Save" is pressed. Soft validation acts more like warnings while editing is still in progress. The final "Submit" triggers hard validation. -t

Adobe is expending their Adobe Forms products with more validation and database connectivity. You can tie it to a scripting language, but it has many options that can be controlled by menus and dialog boxes without coding, and seems fairly extensive. For example, you can set input masks that differ from display mask and the database's view mask for the same field. (Masks are similar to RegExp's.)

PageAnchor Integration-Complexity

There is a meta-design similarity between CRUD frameworks and WCMS, and perhaps email/calendar/planners/project-tracker suites. If you make a "complete" list of typically requested features, the list will total roughly 40 to 100 feature items, depending on partitioning choices. By themselves, most of these features seem straight-forward conceptually and would be relatively easy to create a demo app that implements them. However, the hard part is the integration of them all: making them all play nice together. Most cannot be simply tacked on in isolation. If you add them incrementally, the effort and risk is non-linear because it impacts more features, which themselves grow more complex in order to integrate.

Generally each new feature will impact roughly 1/3 of existing features. Thus, if you have 12 features already, then adding #13 will impact about 4 features. If you have 21 features already, then adding #22 will impact roughly 7 features, which is about twice the effort of doing it when you had 10 features. It's a form of the NetworkEffect. Further, the coding to each feature grows over time, so modifying a given feature costs more as the project matures. -t

CategoryInteractionDesign, CategoryBusinessDomain