Should a user be prevented from making an invalid selection or denied with an error message after the fact?

Question

In my UI, there is an icon for ‘Open File’. When user clicks this icon, a normal file browser window opens. The user selects a file by browsing through the computer.

The user should only select specific type of files through my UI (lets say only file of type ‘.abc’ can be selected).

There are two possible ways to tell this to the user:

1. User can open file on any type and when he tries to select an invalid format, a warning message appears.

2. Only files of type .abc are visible to the user and option to change this file type is not given to the user.

I find option 2 better but I don’t see any examples of his behavior in existing software. Can anyone provide examples or other supporting evidence that shows whether option 1 or 2 is a better experience for the user?

Edit: I just realized that option 2 cannot be used in web browser based application and my application is web based so I cannot use option 2. Have to come up with something other than this option. May be showing all types of files and making unsupported formats un clickable.

Answer 1

The answer is in the 10 Heuristics for User Interface Design by Norman Nielsen, which are a must read if you listen to me.

Error prevention: «Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action»

Following this heuristic it is clear that the second is the best option.

Answer 2

Looking at Nielson's top 10 (despite being written in 1995), and based on some user testing, I actually think there's a case to be made for option 1.

Consider the situation where a user believes the file they have prepared for the program is located at a place on the disk. The file is not of the required type, but most users don't always (often) read instructions all that carefully, so when the user navigates to the appropriate place on the disk, hiding the expected file simply causes confusion and frustration, breaking the rules of Nielson's top 10 of 'visibility of system status', 'user control and freedom', and to some extent 'recognition rather than recall'.

In my own experience of conducting user tests, I found that users expected to see all their files even if the file type was incorrect, and an error message at that stage offered a quicker diagnosis and more actionable fix than simply hiding incompatible file types, which didn't really tell them anything.

I suggest doing some user testing of your own to see what makes the most sense for your users, if you can, or at least run some basic analytics and you could A/B test success rates on the 2 versions if you're really keen.

Answer 3

Errors cause frustration and confusion. Forcing a constraint to avoid an error is the better option.

Forcing functions are a form of physical constraint: situations in which the actions are constrained so that failure at one stage prevents the next step from happening.

In addition to preventing the user error, afford the user a clue about acceptable file types and maybe why some files are not allowed.

Perceived affordances are the actions that you perceive to be able to do. Set clear expectations and you will end up with a more efficient experience.

Answer 4

Option 2 is much closer to the mark than option 1, but having no "option to change [the] file type", especially when the user would normally expect to be given that option, is still wrong.

Ideally, you should not be deciding whether the file in question is valid based on the filename extension, but rather by checking some type of tag at the beginning of the file.

For instance, interpreted executable files of all sorts usually start with a shebang sequence indicating what sort of executable it is, such as a bash script, with #!/bin/bash, or #!/usr/bin/python for a python script. PostScript files all start with %!PS-Adobe-version (encapsulated or not). HTML documents always start with an opening <html> tag. XML file formats have a tag at the start indicating what is described by the file.

Doing this provides three distinct advantages over using the file extension to verify the file:

1. Your application is protected from cases where the user accidentally overwrites a file with invalid data.
2. You allow the user to use different extensions if needed, or more than one, to indicate different things. For instance, .ps and .eps are both used for PostScript files; the difference is that .eps indicates that the file is fit for use as a library graphic. CRIO (a CAD program) appends version numbers to its files (as in mounting-block.prt.4).
3. You give a user who has no knowledge of your program, who has received the file from someone else, to easily determine what type of software is needed, simply by examining the file in a text editor. This is not just something a programmer would do: my parents will do this to unknown file types, and they are not very technical users.

Answer 5

Hiding the incompatible file types completely will cause confusion. Users will wonder if they picked the wrong folder and may spend a while looking for this missing file before they realise it can't be used.

The best option would be to show all the files, but grey out the incompatible ones and make them 'unclickable'. Therefore it's immediately clear that yes, the file is there but no, it can't be used.

A bit of text clarifying which file types are accepted would always be a good idea also :)