I was in a meeting the other day discussing file formats with my colleagues. I was not happy with the outcome.

Long story short, the key point made was that you cannot trust a user to keep the file name relevant to the content, so we need a file extensions for every type of content the file can contain so that the user knows what type of data is in it and so that an icon can be registered for each type (urrrgghh).

For example: *.Data *.DepthData *.FlowData *.PrecisionData *.CompositeData

Data can become composite data by importing PrecisionData and when saved, the extension will change.

My counterpoint was that the application can offer the user a choice of folder in which to save the data, and then present them with the path to the new file, and the option to open it immediately. The application should choose the name of the file, if the name is important and this restriction will impress that importance upon the user - the application itself is not dependent on the file name.

I was told that generally, the user will change the file name after saving. That seemed flaky to me - really flaky. Generally, where is the research to support that?

So I've come here to ask if there is any recommended practice for generating/suggesting or restricting the filenames of exported data. Or if there is any data to support the claim that users will generally change the file names for giggles. Maybe I'm wrong and the man extensions route is acceptable. Let me know!

Bear in mind, I am writing industrial and vertical software. Training is required for the system and is an option (albeit, one i would prefer to avoid) for communicating complex application behavior.

  • Does content get displayed differently if it has a different extension? I could imagine that, in scientific software, the process of capturing raw data and keeping it unchanged, then correlating it with data from other sources in a new file, is such a central part of the workflow and might display them in such substantially different ways that it's actually worth making them separate document types.
    – uliwitness
    Oct 14, 2013 at 16:30
  • This is an engineering problem dressed as a UX problem. You could separate the file structure on the machine from how users organise and name projects. See my answer further down. Oct 14, 2013 at 16:57
  • @StewartDean this is a UX problem. My question asked for patterns in user usage and suggestions in how to coerce behavior. That is UX.
    – Gusdor
    Oct 15, 2013 at 7:07
  • If you solve the user experience then you will have an answer. You are starting from a fixed engineering solution so are putting engineering first. Doing UX right puts the user solution first and then finding a way to engineer the solution. I know this is not helpful but I'm giving you a real UX answer. Oct 15, 2013 at 8:49

4 Answers 4


you cannot trust a user to keep the file name relevant to the content

We should not burden the user with keeping the file name relevant to the content, especially if the same or related content comes in so many forms.

If the user can change the name, and changing the name gives them problems down the road, it doesn't matter whether they usually do or don't.

I see a slight conflict here between two storage models:

  • User owns the files: users name, combine and store them as they like (your collegues)

  • Application owns the files: the user appoints a storage location, but names, relationships, existence etc. is managed by the application (your model seems closer to that)

The latter often requires that all secondary operations - rename, delete, sort into folders, backup, templates etc. - must be provided by your application. That works well in "casual" apps where these needs are limited and well-defined, in industrial environments you always have to deal with automatated tasks and interfacing other applications.

Nontheless, a well-designed schema for file names can make it easier for all involved.

Not knowing more details baout your application, I see the following options:

  • As per your collegues, register a file extension. This gives the file a well-defined "type" string like "AcmeCo Precision Data" and icon. (May I ask where your "Ugh!" comes from?)

  • If the files belong to one data set (e.g. they come from the same test), letting the user specify only the "master file" name, and storing the other files in the same location with a derived name. You'd need to avoid conflicvts (or enforce separate folders for different data sets)

  • A "project file" of sorts, where you can point to a random assembly of flow/precision/combined data files. Needs some provision for moving the whole bunch, e.g. by using relative paths where appropriate.

  • Hi. Thanks for the detailed write up. "ugh" was because my colleagues want one file format to share many file extensions for the sole reasons of providing many icons, despite searchability going out of the window. I should have made that more clear. Personally, I'm in favour of users owning files. If we wanted more control I'd always recommend an embedded database.
    – Gusdor
    Oct 14, 2013 at 13:41
  • 2
    I don't know the actual data, but even if the file format is technically the same, if the interpretation is different - i.e. you can't freely swap FlowData for PrecisionData - they should be treated differently indeed.
    – peterchen
    Oct 14, 2013 at 14:26
  • 1
    when you put it like that, it sounds more rational.
    – Gusdor
    Oct 14, 2013 at 14:39

You are definitely right that, in general, a user should be permitted to rename and move files as they see fit. If you can do that, do it. That way they can easily make backups, go back to an older version of a file, or switch between documents or document sets.

However, that is not always feasible for every system. Can you elaborate on your app and what it does? Is it more a situation like an Office suite, where you can create a Word Processing document, or a Spreadsheet document, or is it more a situation like a web page where you have an HTML file that ties together a bunch of related resources (images, style sheet files, JavaScript files)?

If it's the former, you should really use different file name type suffixes. That way your app can easily tell apart what stuff is in it, and provide a nice icon that conveys the same information to the user. However, changing the suffix sounds like an odd idea. Is .Data the old extension and it will change just once when they upgrade to a new file format? Files that randomly change extensions based on changes are (generally) not a good idea. Users expect their file names to stay the same. Otherwise e.g. a user's scripts to backup a certain file would constantly break, so try to avoid that.

If the format really only changes for internal reasons to your application, make that part of the file format, e.g. by starting it with a magic character sequence, but leave the name and extension untouched.

If your setup is more like a web page (but not really a web page), one approach you can use is to wrap several files in one. On some platforms, this happens automatically if you put them in a folder that has a file name suffix (e.g. on Mac OS X). That folder then shows up as a single file (well, you also need to associate that suffix with your application, but that's how it generally works). That way, you can have several files internally, but to the user it is a single document.

Other platforms achieve similar things by using ZIP files for their file format. They give them their own, custom suffix, but write several files into that one achive. To the user it's one file, but your application can read/write, control the names of the files inside the archive and even build a folder hierarchy.

Now in the case of an actual web site, it's more difficult: Web site authors these days are used to being able to edit images in Photoshop and the actual HTML and CSS in their favorite text editor. So unless the purpose of your application is to replace all these tools (e.g. because it is a web site builder for non-technical people), you'll have to leave the files separate.

If you're dealing with such a case, your best bet might be to just group those files in a folder, and let the user browse all the sub-files in that folder from your application. Don't worry about the surrounding folder, and just expect the user to not modify the relative positions of each file. If you need to store additional data, put a special file in that folder with that extra information. The question, of course, would be what to name that file. If you can accept an arbitrary name, that's good. If you need e.g. one file per HTML file in the folder, use the same name as the HTML file but a different suffix. But be aware that all of this makes usage very technical and nerdy and increases the potential for a user damaging the files.

While your system may have training, it's always simpler to avoid usability issues in the software design, than to have to continuously train (and remind!) users after the fact. Of course, if your company makes its money off its training contracts, that might undermine your business model, but is that really how you want your users to remember your app, as complicated? Or would you rather train them in advanced things and have them happy?

Now, all the above describes the ideal case. Sometimes, your application is simply so complex that you expect people to be familiar with file naming conventions and folder hierarchies. E.g. the Apache server is an example where there is a good reason for (most of) the complexity. If your system can't be made to fit into one of the simpler file system schemes outlined above, try to at least limit the number of files your users are exposed to.

E.g. on MacOS, the user files for a server are ~/Sites for the user-specific files (rooted at example.com/~username) where any user can mess around all they like and easily host files. There's a /System/Library/WebServer/Documents/ folder for files at the root level (harder to find, but usually under the admin's control anyway), and there are the standard Apache files for CGIs, configuration etc. that are not supposed to be user-serviceable, which are in /etc (a folder hidden in the UI by default), and usually only accessed using the GUI for configuring the server, never directly, unless you're really nerdy.

The only special filenames in the user folders are ".htaccess" (hidden, only for nerds) and "index.html", which, if you know to create it, is the default file shown when you don't give a file name. So not really important to know to view a file from the outside. Everything else keys off file name suffixes.

So, in summary: If you can let the user give their own names, do it. It's their computer, their file system. If the file system is not supposed to be user-serviceable, make sure you hide stuff away in folders, invisible files, folder packages or ZIP archives.

  • The software is data logging and this file format is designed for export and portability of logged data. I like the idea of choosing the uncomplicated root where possible. Backup scripts are not something I had considered - and they will be/are run. The extensions are a well defined set of 5 or so. The importing applications will know ahead of time what to expect.
    – Gusdor
    Oct 15, 2013 at 7:21

Usually, when saving a file to the file system the user is prompted, and he can choose the file name he wants. If you must keep such prompt, of course you can no longer rely on the file names. I would also say that you can not rely on the file extensions neither. My point is that it's inconsistent to let user a choice (the file name), while asking him not to change it.

I propose you two options:

  1. You do not open the usual prompt window, and just save the file with the name it must have. Many applications use such way, for example Firefox stores the profile data in a file without prompting for the file name.
  2. You prompt user for a name in a custom window, and you work with a matching table that will help your application to make correspondence between user customized name and actual file name.
  • Hi, thanks for your answer! I hoped I'd made it clear but the software does not rely on file names. As far as I'm concerned, your format fails if you need to do that. Rather, personnel rely on file names to deescribe contents. I consider that to be exactly what file names are for but I am in a minority at my end. Apparently we cannot trust users to a) names files well or b) leave well named files alone.
    – Gusdor
    Oct 14, 2013 at 12:39
  • 1
    There's certainly something to be said for picking good default names, if your data allows generating ameaningful name. E.g. when you dump a web site, you can name it "en.wikipedia.org Snapshot Jan 15th 2004.sitedump". But when in doubt I'd say the user always knows better, so let them at least change it after the fact. It is true that users forced to name files at the wrong time will often use default names like "Untitled" so they don't have to type the same junk each day, though. So it helps to remember previous names.
    – uliwitness
    Oct 14, 2013 at 16:23

It's impossible to give you the right answer without understanding who your users are. You say from your research...

the key point made was that you cannot trust a user to keep the file name relevant to the content,

I would say that for the average user they don't worry too much where the files providing they can get to them for what they need. All software can be made easier to use if you understand what the users do outside of the system and how that system fits into it. If your company has done no user research then you'll just be guessing.

Having said that many systems provide a way to handle projects and files within the application, regardless of what they system they sit on is. They provide ways to share files and ways to rename and organise files. That way the user never has to worry about where the system keeps the files. In short the filing system on the computer and the way the users see the files in the application does not have to be the same. For example if you use google drive it is just a bunch of files with tags on them, the actual directory structure at the other end the user does not need to know about, nor is it possible to access.

In short what you're attempting to do is solve an engineering problem here but if you solve the users problem first then the engineering problem is likely to be very different and can possibly be optimised in ways previously unexplored.

  • The engineering is not a problem. Either path is trivial to implement. As noted in the question, the software is industrial and vertical. The users are trained, internal operatives. Files are intended to be transferred across machines. This is not a social application, it will be emails and network drives.
    – Gusdor
    Oct 15, 2013 at 7:08
  • UX is universal as people are people. Any lesson learnt in one aspect of solving a problem is transferable to any new problem. For example saying the software is industrial and vertical does not change the users. You have picked a certain implementation bases upon other solutions it appears. This does not need to be the case. You are letting engineering drive the solution, therefore engineering is the problem. Oct 15, 2013 at 8:45
  • You are mistaken, this is very much a user focused problem. It just so happens that we are dealing with the file system and that is a nerdy thing. Vertical software certainly does change the users. These are trained individuals. I made clear to my colleagues that the file name should describe content to the user, not the extension. Like a text file - you dont name it 'sometext.txt'. You name it 'finance_notes.txt'. I was told explicitly that trained users change filenames 'generally', implying that trained individuals will deliberately delete descriptive file names because they can.
    – Gusdor
    Oct 15, 2013 at 8:56
  • 1
    No amount of research will give you a definite answer on this one I'm afraid. If the operating system you're using warns the user when they change file endings, that's one thing. Most systems won't bat an eye lid when they change the file name. So - once again - the engineering solution has dictated what the user should not do even if they're likely to do it. Can you think of a couple of scenarios where users will legitimately change the name of the file? If so why not make it so the file name is not critical? Unless the engineering is fixed you can solve the UX problem in the engineering. Oct 15, 2013 at 9:25
  • 1
    One other thing - training and instructions in an application should are often ignored or forgotten so can't be relied upon. It's better to try and make the UX make sense rather than fixing it through training. Oct 15, 2013 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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