Philip Guo (Phil Guo, Philip J. Guo, Philip Jia Guo, pgbovine)

Computer Literacy Starts with Developing a Mental Model of Filesystems

Summary
To teach computer literacy, first teach how computer filesystems work at a basic level.

As the years pass, I grow more and more convinced that computer literacy starts with developing a working mental model of computer filesystems. This includes concepts such as:

  • files
  • file extensions and types
  • folders (a.k.a. directories)
  • hierarchical tree structure of folders and files
  • what pops up when you plug in a USB stick or hard drive
  • home folder (e.g., ~ on macOS)
  • app folders (e.g., /Applications on macOS)
  • apps can read, write, create, and delete files
  • the difference between moving and copying a file/folder
  • permissions (e.g., why can't I create a file or folder here? why do I need to type in my password? why do I get a pop-up alert?)

I'm not saying everyone needs to know how filesystems are implemented; but everyone does need to learn a mental model that's accurate enough for them to predict what happens as they interact with their favorite apps. Unfortunately this can be really hard to do because GUIs in modern operating systems hide many filesystem details or expose them to users in inconsistent ways.

(But everyone just uses mobile devices nowadays! They don't need to know about filesystems, right? Jump to the end to find out.)

Family Computing Woes

Whenever I visit family for the holidays, I'm the I.T. person in charge of fixing whatever computer problems have piled up over the past few months. But being an HCI/UX researcher, I can't resist first learning about their existing mental models before offering any potential fixes. So I have them walk through what they're trying to do and where exactly they're getting stuck.

Here are four stories from my most recent trip home where I helped a family member who wanted to download, convert, and archive videos.

1. Where does this app place its output files?

First he wanted to use a Mac video converter app to convert videos he downloaded from YouTube (more on this later) into a format that he could play on his TV. He saw that the app was placing the converted output video files into a Downloaded/ folder, which he assumed was the same as the Downloads/ folder that he could access from his Mac desktop. But he couldn't find his videos in Downloads! Of course, that's because they're different folders, and it was really hard to find where Downloaded/ was. It turned out it was nested within some Movies folder that I didn't even know existed and then within the app's own folder in ~/Movies/Wondershare Free Video Converter/Downloaded/. That wasn't at all obvious to me. After digging around the preferences menu, I was able to change the default output folder to something more visible like Desktop/.

Remedy: To prevent such confusion, I imagine that an OS-wide monitoring tool (like a taskbar widget) could automatically detect what files were being written by the currently-active app and visualize exactly where those files are located in the filesystem. This could be implemented atop, say, DTrace for macOS.

2. Why is this app taking forever to launch every time?

The next problem he mentioned was that the video converter app took forever to start each time he clicked on its icon in the dock. That was surprising to me, since he had a fast iMac. The dock icon looked normal, but when I clicked on it, it popped up this “Verifying” dialog which did take forever to finish:

This happened time and time again, so it wasn't a one-time thing that just popped up on the first launch. It wasn't at all obvious what was going on, but then I noticed that the app's compressed disk image .dmg file was still visible on his desktop. When I clicked on it, I saw the following:

What's going on here is that there are two files within this compressed disk image: the video converter app (left) and a shortcut to the computer's /Applications folder. How you normally 'install' macOS apps like this one is by dragging the (left) app icon into /Applications, which will automatically uncompress and place it into there. Then you can navigate to /Applications, launch the app, and add it to your dock. And all should be fine.

However, what he did (which seems perfectly reasonable!) was double-click on the video converter app within the compressed disk image, which uncompressed and launched it. Then he added that running app to the dock, where its icon looks exactly like the app's real icon (because it is!). However, now whenever he clicks that dock icon, he's launching the copy of the app contained within the compressed disk image, which is why it takes forever to uncompress and run that "Verifying" step on it (which may be a recent macOS added security thing) ...

Since this method of 'installing' apps seems to be unique to macOS, I had to demonstrate the proper mental model of .dmg disk images to him, which again wasn't at all intuitive.

Remedy: I'm not sure what the best solution is here, but perhaps the OS should issue a warning when users try to launch an app or add something to the dock that lives on some other mounted drive (like a .dmg compressed disk image or external hard drive).

3. How do I install youtube-dl on macOS?

This family member uses macOS on an iMac, but to my surprise he also had Ubuntu Linux installed on a separate PC. He uses Ubuntu for only one app, youtube-dl, to download videos from YouTube. He then transfers those videos to his iMac to convert them to a format that he can later watch on his TV (see above).

He's not a programmer, but he knew that Ubuntu had a built-in terminal app. He was able to successfully follow these installation instructions from the youtube-dl webpage (screenshot taken in Nov 2019) by copying and running these two commands:

He used Ubuntu for this because he didn't know that macOS also had a terminal. When I told him that it did and showed him how to add the terminal to his dock, he was excited that he could ditch Ubuntu entirely and just use his iMac to do everything he needed.

However, when he followed those exact same instructions (which said that it should work on "OS X", an older name for macOS), he saw the following error message on the macOS terminal:

Warning: Failed to create the file /usr/local/bin/youtube-dl:
Warning: No such file or directory
  0 1711k    0 16360    0     0   4707      0  0:06:12  0:00:03  0:06:09  147k
curl: (23) Failed writing body (0 != 16360)

At first glance, it's not at all obvious what the problem is.

The first line hints at not being able to create the file /usr/local/bin/youtube-dl, which gives us a clue. But the second line is really confusing; why does it say “No such file or directory”?

To debug this issue, I showed him how to break down the path /usr/local/bin/youtube-dl into individual components:

  • /usr is a top-level folder in the filesystem
  • local is a folder inside of /usr
  • bin is a folder inside of local
  • youtube-dl is the file that the app is trying to create

OK let's take a look at those folders with the macOS Finder app:

Wait, there's no way to get to /usr from the Finder! (You can run open /usr from the terminal to get to it, but that's not obvious!) So instead we navigate to it in the terminal. We discover the problem: there's no /usr/local/bin folder on recent versions of macOS. Since that folder doesn't exist, the file /usr/local/bin/youtube-dl can't be created in it.

The fix was simple:

sudo mkdir /usr/local/bin

(Note that this also requires a mental model of permissions; we must have sudo privileges to create a folder inside of /usr/local.)

One could argue that youtube-dl should've updated its installation instructions to work on the latest macOS, or better yet, provided a one-click installer. But this program was exactly what my family member needed, so he had to learn to work with it, warts and all.

Remedy: Again a DTrace-like OS-wide monitoring widget could automatically alert the user when a program (here, curl from the first line of the youtube-dl installation instructions) was trying to create a file like /usr/local/bin/youtube-dl but its parent directory /usr/local/bin doesn't yet exist. It could prompt the user to create that directory and also recognize that they need sudo permissions to do so. This sort of monitoring tool would be application-agnostic and thus work for both command-line and GUI apps without knowing about the details of those apps.

4. Where does youtube-dl download its files?

Finally, now that youtube-dl is installed, he can run it on the command line to download videos. But where are those videos placed on his computer? This is exactly the same problem as the first story above: 1. Where does this app place its output files?

When he opens a new terminal, it defaults to his home directory ~, so youtube-dl will download video files to there. However, there's no obvious way to get to ~ using the macOS Finder so he can't access his downloaded videos!

As shown above, he can get to folders like Desktop, Documents, and Downloads, but not to the home directory! The way to do so is to run open ~ from the terminal to launch a Finder GUI in ~, which again isn't obvious! I taught him to do this and also to first run cd Desktop to change into the Desktop directory before running youtube-dl so that downloaded video files show up on his desktop.

Remedy: Again a DTrace-like OS-wide monitoring tool could automatically alert the user that youtube-dl had created a new file (the downloaded video file) within a certain folder and prompt the user to open it. Ideally such a tool should not only show users the relevant files but also teach them how to form a robust mental model so that they can know what's going on in the future even when such a tool isn't available (e.g., when they're using someone else's computer).

But what about mobile devices?

Now that we're mostly on our mobile devices, do we still need to develop a mental model of filesystems? I would argue yes: Despite the fact that mobile operating systems try to hide filesystems from us, mobile apps are still built on top of them. I think these concepts are even harder to understand on mobile (definitely not easier!), since people are now dealing with distributed filesystems every day due to cloud services and cross-device syncing. When something goes wrong, it's really hard to understand why.

Appendix: Further reading

Keep this website up and running by making a small donation.

Created: 2019-11-11
Last modified: 2019-11-11
Related pages tagged as human-computer interaction:
Related pages tagged as software: