5

Recently, while discussing the design of a user interface for a web app, I noticed a phenomenon in which people only think of a few simple user interactions like "type text there", "select an item from a drop-down list" and "click save". In other words, the only buttons on the screen should have labels "save", "cancel" or "back". Even if the action to be performed is to send or delete something, they would prefer a drop-down list of possible statuses like "sent" or "deleted" and a save button by default, instead of e.g. a button which says "send" or "delete".

It occured to me that this is analogous to the Anemic Domain Model (Anti-)Pattern, only that it concerns the user interface and not the design of the model itself. Sadly, I haven't found any useful resources on the web about this kind of pattern in the context of user interface design. So, any links would be appreciated. :)

I also would like to know whether you have experienced the same. Would you consinder this an anti-pattern on its own?

4

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).

  • "A command button makes it clear that Something Will Happen." Yes! Great point. It's been bothering me the most: it's not always just open, edit and save, and the ui should reflect that, or at least somehow indicate that there is an process going on. – proskor Jun 10 '15 at 14:44
2

The style of UX you are describing is one embraced by companies like Google and Apple, and the objective is to hide complexity.

Basically, the design objective is to present a calmer and clearer interface by hiding less common functions into dropdowns, so the user is presented with fewer choices.

Personally I'm not a fan of this trend, especially when it comes to office applications like Gmail or Google Docs...because these interfaces hide far too much.

Nonetheless, this is not similar to the anemic domain model (ADM) programming antipattern you describe.

The ADM is an antipattern because it introduces unnecessary complexity into object models: e.g. objects exist just to get and set attributes which is (according to the pattern) not a good use of classic OO programming.

By comparison, UX design that hides complexity is trying to do the philosophical opposite...the attempt here is to reduce, not increase complexity and entropy in the interface by hiding less used features. I don't think this is really comparable with ADM.

hope that helps

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.