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.
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.
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. TheRadBottleneck describes some of the tricky questions involved with primary key management.
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