User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I think it might be useful to make file path edit box in my program multi line, because file paths can be quite long, and when they don't fit the user has to scroll text left and right with cursor keys.
Are there any cons to doing a multi-line input in this case?
In response to your comments my answer is this.
If it improves the user experience to be able to see and edit the file name and path by breaking it over multiple lines then I would suggest its sensible to do so.
As long as you keep in mind accuracy.
Perhaps a better suggestion would be to breakdown the file path into it's constituent parts and allow users to select the path from prompts or, perhaps even better, to use an explorer dialogue to allow them to browse to the correct path.
...if the only other choice is a 1-line input box.
One line input boxes are terrible for editing long text (i.e. significant box overflow), for reasons that are almost completely obvious. They're bad on the web and even worse on tablets or mobile phones.
If you have no other way to create space for the long paths, then a multi-line textbox will work better than a 1-line input box. An expanding textbox is better than a fixed-height textbox.
Here is an example of the expanding textbox for editing file names in Windows 8:
Here, Microsoft could have provided more horizontal space or a pop-up edit box, but they likely decided that the benefits of "in-flow", inline editing even with the awkward text wrapping outweighed the costs of providing out-of-flow edit boxes.
If there is a special interraction with this file path that start a special event in your application, you may make it larger.
The multi-line choice can be confusing if the path is totally filled :
So I do not recommend to make it multiline.
If it is a common file path, moreover next to Browse, make it one line and aligned with the rest of the content.
If you're going to allow users to place long paths, I would opt for a paste button of the sort. (make sure they can paste a long path in the text box). In many years using windows I don't remember many times where ctrl+v has failed me.
It opens up too much room for error. The same goes for URLs. Yes, it can be done, but I've never encountered a scenario where a better solution didn't exist.
If your user is highly technical, they'll be familiar with long file paths. In my experience, they will prefer keeping it all on one line. They'll be comfortable with a command line like entry because it will build a sense of confidence.
If you are addressing a typical user, they won't be familiar with long paths at all, whether on one line or many. They want to see some kind of file browser that inserts the name of the selected file in the UI. Don't make them look at the path at all.
