User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my job, I create apps where I'm converting data and frequently need, among other things, an input and an output directory. Obviously, the input directory needs to exist, but for the output directory, should I verify it exists and prompt the user if it doesn't, or try to create it if it doesn't and prompt only if that fails.

For example, if the user inputs c:\output\run1 and there is a c:\output directory but no run1 directory, should I just create that directory and proceed, or should I force the user to enter a directory that actually exists?

share|improve this question
Use a folder selection dialog that also allows for new folder creation. Offer manual input as an alternative. Draw attention to the fact that the specified folder does not exist by whatever non-modal notification means you prefer and offer a checkbox to create it on continuation. – Marjan Venema Apr 29 '13 at 18:48

There is a good chance that someone will want to output content to a directory that exists, but make a typo when entering it. If you don't prompt the user and just create it, they are likely to get frustrated because you aren't saving it into the directory that they think they saved it to.

If on the other hand you let them know that the directory doesn't exist, if they made a typo, and they know that it should exist, they are more likely to double check the directory.

So I would prompt them if the directory doesn't exist and ask whether they want the app to automatically create it, or choose a different directory.

share|improve this answer
+1 Standard pattern in desktop development is to show a dialog allowing the user to select the folder from the OS's folder tree. The dialog can optionally be configured to allow creation of a new folder. End result: folder should exist after dialog is exited. If it turns out it no longer is when you come to save files in that folder that is an error condition of which the user should be notified as it sh/could only happen by somebody deleting an existing (however briefly) folder in the meantime. – Marjan Venema Apr 29 '13 at 18:45
Perfect response - I also think it is key to include a "Would you like to create?" dialog after. – Justin Meiners Apr 29 '13 at 22:58

for the good reasons mentioned above, if the directory was manually typed, but it doesn't exists, the UI should notify the user.

However, I find prompts very intrusive (and archaic). I would suggest in-line validation. When the user finishes typing, and the focus leaves the textbox, you can asynchronously check to for the existence of the directory (or even general validity). If there is a problem, show it next or around the field, to notify about it. But don't bring the user's flow to a complete halt just for the chance there's a mistake.

You can read about the design pattern of in-line validation here:

Just as other input fields, like username or password, were once validated with pop-up dialog, it is time that this input field would also behave in a more modern and subtle manner.

enter image description here

share|improve this answer

In many scenarios, the act of creation of a directory is defaulted when there is no current directory. You can look at several Shell/DOS commands like 'touch' which checks for a directory and creates one in case there isn't one.

However, speaking in UX terms, this is bad, by the fact that the user is unaware of the decisions being made. The core principle of UX is enabling the users and making them feel in control. By that virtue, you should always have a confirmation dialog to get the users permission "There is no run1 directory inside output directory. Should I go ahead and create one?" You can then ask if the user wants to go ahead with the decision or makes some changes.

share|improve this answer
I don't think that users being unaware of decisions being made is necessarily bad. Too often, software doesn't make enough assumptions about a user's intentions. – Brendon Apr 29 '13 at 15:31
Users do not need to know about the inner workings of the software necessarily. But, the output, specially if it is something like creation of a directory, should be run by the user. – rk. Apr 29 '13 at 15:33
Users don't care about 99% of the decisions that are happening. If this were a real pattern we couldn't use Windows without confirming the hundreds of decisions being made constantly by the OS about files, settings, etc. Design is all about abstraction – Justin Meiners Apr 29 '13 at 23:38
@JustinMeiners I just mentioned that the user don't care about inner workings BUT anything that impacts their workspace, they ought to be involved. Now, I do not know where you get your 99% figure, but, I would surely not go so far as to call hiding 99% decisions as an 'abstraction'. – rk. Apr 29 '13 at 23:41
@rk Your computer is constantly moving files, running programs, downloading, uploading, etc (99% made up number). All of these things are real operations that could potentially affect what a user is doing right now. the abstraction is then about determining what decisions a user most likely cares about right now etc. I get what your saying though - you shouldn't silently make a decision that dramatically affects a user. – Justin Meiners Apr 29 '13 at 23:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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