The key part of that last statement is <i>have to</i>.<p>You&#x27;re right that as a matter of routine, having recent documents worked with in an app come up on opening it (and an easy visual list of all the files the app has touched) is a great interaction pattern.<p>That says nothing about whether or not there should be some kind of file browser, or other means for users to become aware and able to interact with files outside an app.<p>Particularly because at some point, single-app workflows hit their limits, and getting stuff done either becomes a matter of using multiple apps or waiting for an app to grow the new feature you need (the latter of which is not just getting stuff done).<p>And I&#x27;m not just talking about Power Users -- I&#x27;ve seen this happen with my mom (proverbial disinterested computer user), who generally is quite happy to be completely unaware of the file system, but still periodically runs into corner cases where she needs to do something no single app will let her do (usually audio-file related).<p>This all reminds me of the discussion around hiding URLs in browsers:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7677898" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7677898</a><p>For decades, we had a system where people who didn&#x27;t care to pay any attention to URL bars could ignore them, and people who were incidentally curious could learn useful things by paying attention, people who needed to discover them could, and people found them regularly useful had them at the ready.<p>Then somebody who got caught up in a shallow idea of simplicity that neglects utility and discoverability decided they&#x27;d make a UX change that was hostile to all of latter two groups. After all... the first group doesn&#x27;t care, they just want to navigate the web and get stuff done.<p>The right principle here is to make the simple case easy and obvious, and the more complex case discoverably possible.