Crud Screen

A typical set of data-entry forms and search-and-view screens and reports. "Crud" stands for CreateReadUpdateDelete information, often but not necessarily tracking the database schema one-for-one. The term is often associated with, but not exclusive to "business applications".

While many business applications may have need for such screens, it is often a CodeSmell when an application is principally composed of such screens. It often indicates that the DomainModel has been neglected, pushing the business logic up into the GUI layer or the end-user.

Also recently known as [a specific paradigm] by those who think this is programming.

That is not true. CrudScreens can be and are generated in many paradigms. The user cannot tell which paradigm it came from for the most part. This topic is mostly about user requirements, not languages nor language paradigms to bring them about. Perhaps specific scenarios can be brought up. Well, actually I can name one: In MicrosoftWindows one often must use the GUI to make certain configuration changes. There is no API or scripting command to automate it. This generates repetitious busy-work for larger organizations. However, "regular" end-users are not going to be doing most of their work via command scripts such that the GUI interface is necessary even if scripting is an option.

I think "list" should also be included, but perhaps that would be under Query, which is perhaps not meant to be included.

Query is a Read.

Yes, but often it involves fairly complex input to get the desired query that I think it deserves its own category. But I guess the term is too entrenched to adjust now.

Features that typically need to be considered in CrudScreens:

Look-up screens (see QueryByExample) for searching and generating basic reports. May also need various sorting order options.
Editing screens with add, change, and delete capabilities.
Look-up ability when on a current form. For example, ability to look up an employee number without cancelling the current screen. Another example is a pop-up calendar for date entry.
Parent-child screens such as order information and order detail items. Generally this will involve the parent info displayed at top, and grids/tables of details below it.
Access levels or "roles". Some screens or data may be off limits or read-only to some users. CategorySecurityModel

One of the eternal HolyWars surrounding CrudScreens is whether to use coordinate-based element placement or flow-based (hierarchical) placement. (But this is a wider UI design debate; see CoordinateVersusNestedGui.)

The CRUD acronym predates the notion of a CrudScreen, and typically refers to the CrudMatrix (in design) and the CrudLayer (in code).

I don't see where the CRUD acronym comes in. The "too many operations" implies that there is not correspondance with "create, read, update, and delete".

The correspondence comes from the fact that one writes 'C', 'R', 'U', and/or 'D' in each of the cells of a CrudMatrix, representing which of these operations the procedure performs on a table.

CrudScreen work is often stereotyped as being boring and repetitive. (See DomainPissingMatch). However, anything that is boring and repetitive should in theory be relatively easy to automate. Over the years I have been kicking around ways to simplify and automate the process of crud-screen creation by playing with experimental frameworks, both implemented and conceptual.

However, a sufficient system/framework still seems elusive. It is not that they are simple by themselves, but that patterns in them are common and familiar. As an analogy, one might look at all the different car makes on the road, think about the similarities of cars in general, and wonder why the parts are not more interchangeable rather than custom-made per model for the most part. Part of the reason is that technology keeps changing too fast for standardization to catch up, and partly because marketing forces push each model to be unique to "stand out". Similar forces are at work in crud-land.

Here are various observations I have made about automating or simplifying CrudScreen creation:

Almost every attempt at automation suffers from EightyTwentyRule (makes the first 80% of a project easy but the last 20% very difficult or impossible). Special needs or wants almost always creep up for any non-trivial system.
Automation may be more possible if the "customer" would live with certain conventions. The requests that tend to go outside of frameworks often are either esthetic in nature or only a minor improvement over what the conventions can provide. This is a case where TheCustomerIsAlwaysRight? can be expensive. The customer does not like hearing, "Sorry, the framework cannot make a green, rotating ball every 2nd Thursday of odd months."
Messy schemas can greatly complicate the data-integration side of CrudScreens and related frameworks.
Single-column database keys are easier on frameworks than compound keys. I am not necessarily suggesting that compound keys are "bad", but they do have a down-side on the crud-screen side of things.
My favored techniques revolve around DataDictionary's and EventDrivenProgramming architectures. I would like to see a ProgrammingLanguageNeutralGui engine that is HTTP-friendly. But, I have a feeling it will take a couple of failed attempts by multiple companies or projects before it finally comes together.
The ideal system would allow both coordinate-based and flow-based layouts. Each has various strengths under different circumstances and company cultures. (CoordinateVersusNestedGui) Coordinate-based approaches seem best for input-intensive screens and flow-based best for output-intensive, such as QueryByExample output.
Past attempts tend to either focus on external interface power or database connectivity power. Rarely do they both seem to come together. Usually something that makes database dealings easier is limp on the external interface size, and visa versa. I don't yet know whether there is an inherit conflict between these, lack of funding to finish both properly, or if frameworks have not been powerful enough to integrate both.
Any framework will probably require ways to get at the lower-level abstractions for the times where the framework cannot handle very specific needs. Thus, the framework should be semi-transparent and tinker-friendly.

--top

Unfortunately I haven't found anything that automatically generates these for Web/Java development besides Apple's excellent (but proprietary) WebObjects / Direct to Web. Any suggestions?

You may want to take a look at: CodeGenerationIsaDesignSmell or, if you really really like CodeGeneration, perhaps SeamFramework or AppFuse can help you... or if you one DynamicOnRutimeApplicationGeneration? (like that of Direct to Web) then you should take a look at the NakedObjects

I've been looking for a less quirky acronym or phrase I can use for these screens I can put on my resume. Anyone have any ideas? --ChrisMellon?

Human resources is not going to know what "CRUD" means most likely. Thus, maybe just put something like "interactive business forms".

We used to call it "ExBase". Put a picture of the database on the screen and let the user fiddle with it. It lets you deliver an application without worrying overmuch about how it will be used, without wasting a lot of time talking to the user, and without actually having to do any design. --AnonymousDonor

Coming soon to a book store near you: "DBase for the debased" (SCNR)

Somebody trying to start a fight? (See ExBase)

CategoryUserInterface CategoryBusinessDomain CategoryInteractionDesign