I have also observed that many UIs are confined to some controls to enter, edit, or select some input, plus Save. Is that bad?
The General User Task
I think the truth is that many user tasks involve changing a few object attributes, and that’s about it. Much of what we do with computers is basically “keeping records.” Most of our apps are literally or effectively the front end of a relational database, with the UI being a form or table of fields. The users’ job is to fill out or edit a few fields, maybe including a “heavy “ attribute (e.g., attaching a file), maybe create a new record first, and, rarely if ever, delete a record.
If there are any other available actions (other than obviously retrieving and saving records), it’s usually a single “done” action that is a variation of declaring the record(s) ready for the next agent to process (e.g., Send, Purchase, Post, Submit, Approve). Let’s call this the General User Task. It describes most e-commerce, enterprise, and social media apps, among others.
A Simple UI
For the General User Task (GUT), it’s hard to fault designing a form or table of fields with, maybe, a single “done” button. It’s a design most users recognize and understand. It fits well with the paper form metaphor that even novice computer users get. The fields with their labels serve as prompts, so users can scan the fields and understand what is expected of them. Information and action are integrated at the field level. It’s direct manipulation, in the sense that the user sees a field and changes it directly (I am assuming edit-in-place). Both the information and available actions can be spatially arranged to communicate their relationships and speed visual searches. It puts most of what the user needs for the task in the center of the page/window where users are likely to look first for their actual work; they only need to look to the periphery for finalizing (the “done” button), navigating (i.e., moving on to the next task), or if they feel like enjoying some advertisements.
So, I wouldn’t call that an “anemic” UI. Maybe it’s a “simple” UI, which has positive connotations (at least a few years ago). I believe we should be able to establish a common UI design standard that specifies how to support the GUT with forms and tables. We should have tools and libraries of prefab components to assemble such UIs, like we used to for PC-based database management systems. I believe that would benefit the users. Maybe such a UI is relatively simple to design, as well as use, so you don’t get much chance for creativity. But then, maybe it should be expected that a GUT implies a GUT design job.
But I think you still have a point.
Buttons for Committing Actions
First of all, I generally recommend that the “done” action be represented with a dedicated command button (or menu item), not a field (e.g., “status”) that the user sets and then saves the record(s). I usually recommend this because:
A command button makes it clear that Something Will Happen. In contrast, a field is just a field, and doesn’t naturally indicate that changing its value will trigger the activity of some agent. How do you indicate to the user that this particular status field means the user is making a commitment?
A command button is faster, saving at least one click.
Placed appropriately in the page/window, a command button more clearly communicates it acts on the entire contents of the page/window than a field does.
However, I may make exceptions if user research indicates users really think of “done” as a status to set, not an action to evoke, and that they naturally anticipate that setting such a field value would trigger an action.
Also, one advantage of the status field is the same place the user sets the status to trigger the processing, is also the same place the user checks the status (e.g., to see if they remembered to trigger the processing or not). If that’s part of the users’ work, it can tip the balance to favor a status field.
I really don’t see much sense in marking a record “Deleted” then saving it to effect the deletion. Kind of a mine waiting to be stepped on (“But I saved it –why can’t I retrieve it anymore?”).
Buttons/Menu for General-Purpose Manipulation Commands
Secondly, at least for heavily used applications, I believe the UI to the General User Task should include controls (as buttons or menu items) to support general data manipulation. These include controls to copy, convert, associate/dissociate/re-associate, sort, export, import, and find (subquery) fields and records. This is in addition to commands to retrieve (navigate), save (if not automatic), add (create a record), and delete. There should also be an Undo and sometimes even a Macro feature.
The controls for these general manipulation commands can also be standardized. Providing such controls gives the user lot of actions in addition to simply “done.” To me, the lack of such controls constitutes an “anemic” UI.
Most users won’t need to use any of these commands most of the time. They are generally not essential for the users’ tasks (e.g., worse comes to worse, the user can manually copy one record to another field by field). So it’s okay, even preferred, that their controls are on the periphery, represented as a menu or bank of buttons. However, the commands save the user time and effort, so I consider them important for usability. They’re also great for dealing with exceptional issues (e.g., fixing a field on 9000 records that everyone was setting wrong for the past month).
