Handling validation discrepancies between user mental model and domain model

Question

I am implementing an image editing feature in a mobile productivity app. The feature is used to crop and rectify a camera image of a document. (This is also known as dewarping, straightening, or perspective correction.)

In particular, I am implementing the user-guided cropping mode, where the user can select the four corners of the document on the image, and proceed to see the cropped and rectified result.

Here, I face the following dilemma about discrepancies between the mental model and domain (mathematical) model.

For the four corners to be valid for the domain model, it must be a convex quadrilateral. Therefore, concave and "bow-tie" quadrilaterals are not valid for the domain model. See this article for illustration.

However, recently the UX team tells me that the application should not stop the user from using a concave or bow-tie quadrilateral. Their reason is that:

• Users may not be able to understand the error message that will be shown to them.
• Any error message or constraints that prevent user from proceeding to see the result will induce a negative emotion in the user. The app's current design philosophy is to minimize such sources of negative reaction.

Initially I am surprised by this request because:

• It is a mathematically impossible operation to try to rectify an image with a concave quadrilateral. It is comparable to asking a spreadsheet to perform a division-by-zero and still give a meaningful output.
• The underlying backend performs validation according to the domain model, therefore it is not something that can be workaround (bypassed).

Upon reflecting, I noticed that the request arises because the UX design is based on a different user mental model: a rubber-band on a peg board. See this page for illustration.

There are a number of discrepancies between these two models:

• Convex quadrilateral
  • Valid in both models
• Concave quadrilateral
  • Valid as a rubber-band;
  • Not valid for the image rectification domain model.
• Triangle, Pentagon, or polygon with any number of sides
  • Valid as a rubber-band;
  • Not valid for the image rectification domain model.
• A convex quadrilateral with some corners outside the image
  • Not valid as a rubber-band on a peg board;
  • Valid as an image rectification domain model

The mobile app is designed for general public, therefore I cannot make assumptions about the user's mathematical knowledge. Therefore, it makes sense to use the simplest mental model that is widely understood by general users.

However, it is impossible to produce a valid output because of the backend (domain validation) requirements. The UX is adamant about avoiding negativities in the app design. Are there any solutions?

Related readings

I did some online search and found this article about the trends in data validation. It raises some points that modern UI designers must consider, in a way that departs from the traditional viewpoint which holds the domain validation as gold standard.

Here's my understanding from this article:

• First and foremost, anything that doesn't proceed smoothly will cause frustration (negative emotion).
• The user may ignore, or dismiss too quickly, or poorly comprehend any error messages that will be shown to them.
• Even if the user understands that there is an error, the user may not know what corrective action needs to be taken.
• For online forms, navigating between the invalid fields throughout a long page will be overwhelming for the user. (This does not apply to my situation; I'm just mentioning it for completeness.)

Answer 1

Here are a few possible strategies:

Do nothing.

Since the cropping corners are automatically placed in initial positions, you don't have to worry about concave polygons being created accidentally. The only way you will get invalid shapes is if the user deliberately drags a corner to create one. Since there is no objective reason to create such a shape in the first place (it would be badly distorted at best, and mathematically impossible at worst), it will likely only happen when the user is testing the system to see what's possible, and not when they are trying to carry out an actual task.

Most users, most of the time will carry out their rectify task and never encounter the error message. Those that do have a high probability of operating in "I wonder what happens if I do this..." mode, and won't be too frustrated by an error message.

Disable the 'Finish' button as needed.

When you detect an invalid shape, simply disable the Finish button so that they can't try to rectify when it's impossible. This has a small risk that the user won't notice the button becoming disabled as they drag a corner to an invalid position, but as noted above, they are likely only trying to see what happens, and not really trying to fix the image.

Prevent the concave polygons from being created.

This is the method Photoshop uses.

When using some of the transform tools, you are given a grid similar to the one you describe, but the software prevents the polygon from becoming concave. If you try dragging a corner into the triangle defined by the other three points, the corner simply stops at the edge. The corners have complete freedom of movement otherwise, and this method requires no error messages, or disabling controls, just passive collision detection.

Show the 'After' instead of the 'Before'.

This is a more out of the box approach. Instead of showing the before image with the cropping controls and making the user guess what the result might look like, carry out the rectify operation based on the initial position of the cropping tools and show the user the after image with controls to manipulate it. They will be able to see what the result is in real-time, and the controls would no longer directly map to the original image meaning you can put limits on how far they can be manipulated and thus prevent invalid shapes.

This obviously requires that the rectify operation is fast enough to show updates in around 0.1 seconds, though a low-res preview would also suffice.

In addition to solving the concave polygon problem, this addresses a possible issue where the user is unhappy with their rectify choice and has to undo and repeat the steps. It can be very hard to judge if the lines you are focusing on will end up straight enough when you remove the perspective, and I know it can take me a lot of trial and error to get it just right.