> You still need a BMP editor to put anything meaningful in there. The same is true for a PowerPoint presentation, and an Access database. Although, creating an empty Access database and then opening it will presumably get you the Access program. But if I want to create a new PowerPoint presentation, I will… um… open PowerPoint
I think that really highlights the paradigm-shift that happened in UX in the last decade - what you could call "documents-centric" vs "application-centric".
Until recently, UI was centered around files. You used programs to edit and manage those files, but the programs didn't "own" the files: A file was generally independent of the programs that are used to open them. On the other side, a program does not "know" about a file until you explicitly prompt the program to open the file.
Compare that to the "application-centric" paradigm that dominates on the web, in mobile OSes and recently in desktop OSes as well: Here a program "owns" its data and you are supposed to interact with the data only through the program. It's an implementation detail how the data is physically stored - but from the user's PoV, there is no unified file system. Instead, the assets managed by each program are living in separate universes.
And what a loss it is. Now we must split reminders from the documents they remind of, bookmarks from code repos, product photos from product text, emailed design requirements from design work. It’s enforced organization by format, rather than by subject, and it’s so bad that it’s experienced the ultimate software failure: it’s subconsciously routed around. We copy-paste URLs instead of using bookmarks, we just remember to go back and search for design requirements, we type out document names into our reminders. Personally, I often find myself wholesale abandoning an otherwise excellent program for the sole reason that all its features together aren’t as valuable as simply being able to organize data by subject.
Bookmarks are such a convenient and intuitive way to organize, I'm still baffled how few people actually use them. They exist like forever (1993 according to Wiki), yet there is always someone asking for links to sites/files/Tools/apps they use basically daily.
> Bookmarks are such a convenient and intuitive way to organize
Despite bookmarking websites I find interesting occasionally I almost never visit a site from bookmarks. I don't remember if I bookmarked something, I forget what something was called, I expect I didn't file it in a folder that makes any sense etc. I really want to love bookmarks but like so many people I just find myself not using them for various reasons.
All browsers give very little thought to the UX of bookmarks and what users need of them. It seems to have boiled down to developers thinking that because bookmarks are technically a nested data structure of folders and links that all they need to do is give the ability for the user to manually manage this tree structure and call it a day. I think there's a wealth of missed opportunity with bookmarks but this comment would get very long if I carried on babbling.
I rarely click on my bookmarks, but I use them very frequently. It's a way to pin an important thing into the personal search engine that is my (Firefox) address bar.
The part of the bookmark UX flow I dislike is having to organize them. Especially on mobile chrome. The UX there for folder org is so bad I just have a "log" folder and basically everything goes in there, like a sightly more durable and focused history.
I use the exact same trick - just let the search bar index it.
What I really want is a system like a personal search engine. Bookmarking starts a flow which downloads the page, strips out all the garbage, indexes it in something like Elasticsearch or Bleve, tags some metadata, and organizes it by facets.
Google is decent at getting back to places I once found, but there are still 404s that Archive misses. There's also sites like stackexchange where it's easy to get drowned out by irrelevant results. It would be nice to have a more personally curated view into it.
> Bookmarking starts a flow which downloads the page, strips out all the garbage, indexes it in something like Elasticsearch or Bleve, tags some metadata, and organizes it by facets.
This sounds very useful (especially the downloading part). I don't know how many times I've tried to go back to some obscure page I've bookmarked, only to find the page has been moved or removed. Not daily or weekly, but often enough. Sometimes I'll save the info in a text document, but then I have to run a separate search on the filesystem as well as the bookmarks folder.
I've started leaving myself notes in the name of the bookmark as well, since I find myself forgetting what page names relate to which topics or projects. I know I could organize them into folders, but then I'd have to keep them organized, and I have enough trouble keeping my downloads, documents, and projects in order.
Programs like Devonthink promise such a thing, but I've found their use not quite convenient enough to keep up. Unfortunately - the promise is amazing.
I've been essentially using my start up page and tabs as bookmarks for fifteen years. It's terrible but at least it's _under my nose_ and I'm reminded of those links' existence through my regular habits, which is something bookmarks do not do, out of the way as they are.
People have migrated away from bookmarks (in fact I'd argue that non-technical users never embraced them fully in the first place) because there is no longer any trust in that the URL you used yesterday will still be there today. Link rot is now so prevalent that even the concept of a URL as a destination is starting to become less and less important. Look at Google and it's on-going attempt to de-scope the URL bar in Chrome.
I have a personal Web based Bookmarks app, that I have self hosted for years, but even now I hardly revisit it unless I'm really stuck and a Google search can't find the site/page I need. It's got 1,000s of bookmarks in it, and I dread to think how many no longer work.
That experiment was halted because it didn't move the security metrics as much as they wanted. It is therefore very obvious that the conspiracy surrounding the motivation was ridiculous.
Perhaps, but it's one of the safest bets to make that huge multinationals with billions of private interests do things for profit, rather than for "the customers", "to change the world", and so on.
It takes a special kind of naivety to believe something like Google's early "Don't be evil" slogan.
Actions can have multiple independent influences. For example, aggressively doing searches around the URL bar is decent UI and provides valuable data for search engines. It’s such a central part of the interface that a lot of innovation and experimentation occurs around the search bar.
I used to save a whole web page as HTML when I got started experiencing the early web because the page might be gone next week I had experience and afraid to lose the reference. Now a days I just use bookmarks because there's less chance the page will be gone in a few weeks. Hosting was expensive in the old days and now it's so cheap sites don't suddenly disappear anymore.
I used to have a lot of bookmarks and I used them a lot to return to stuff, but after half a decade a significant amount of them went no where. So I migrated to using note apps + web clipping or screenshots.
I now use bookmarks both as a shortcut to sites or apps that I use frequently and as a sort of process helper: I group bookmarks of apps, documents and even annotated pictures into a folder and open all in new tabs as a means to getting set up for a particular task.
For example when I do my bookkeeping, I can open the finance app, an instructions Google Doc, a spreadsheet for recording stuff that's causing me problems and 1-2 more pages I need in that context literally with one click of my mouse's wheel button (yeah, I'm a mouse person).
Same for when I process my inboxes, GTD-style: with one click, I open Gmail, my calendar, a picture of my notebook, a picture of the spot where I keep paper documents, the Facebook Leads Center etc, and then I just process each tab one by one in order.
Automatically syncing bookmarks were a game changer for me, in Chrome and Safari. The fact that desktop Safari and all my iOS devices have the same bookmarks and automatically sync changes is fantastic.
It would be nice to be able to sync between Safari and Chrome, and I'm sure there are extensions for that, but it's not too much of an issue.
On Chrome, they're little more than an intentional history, with no ability to spatially organise or annotate them. Sometimes Chrome will utilise bookmarks as a type-ahead autocomplete resource, sometimes not. It mostly favours browser history, which may be useful but often is not.
On Fennec Fox, there's a vestigal organisation available (folders), as well as the ability to add descriptive text (but not specifically tags). There's no ability to re-order links within folders, or folders within the overall hierarchy.
On both, text input is so painful that any real organisation is all but impossible.
The tool that I tend to find most useful these days is the old-school "bookmarks page" --- a manually edited listing of sites that I've organised into some ad hoc folksonomy that suits my use at the time.
Desktop and console browsers are still more useful. Firefox has a hierarchical listing that I find useful, and will still occasionally use. w3m effectively creates a hierarchical page I can then further edit and navigate. I actually use that as the basis of some of my freestanding edited bookmarks pages.
Guilty. There's not a great level of abstraction between bookmarks (I definitely want to remember this) and open tabs (I need this in my working memory for a day/week/month, and/or this is interesting but I don't have time to read it).
I guess session savers? Never really got into them because (at the time a few years back) they weren't great for indexing within pages. Might give it a try again.
I had extensive bookmarks when I first surfed[1] the web. Then, that computer broke for one reason or another and I found myself staring at a fresh install of IE with none of my catalog. From then on I never built a bookmark catalog again.
I've replaced the functionality with various tools and tricks, from Google Reader to, nowadays, a simple dump list in Evernote with a loose tagging system. I guess now that you can sync bookmarks with Chrome and Google Account my original problem is solved but that solution came too late and old habits die hard (not to mention private data concerns).
I did take to bookmarking again lately though but mostly for work purposes: obscure pages in our wiki, some internal systems, the system we use to book leaves, etc. But if I have to change my work computer I would definitely have to ask around for those URLs again.
[1] Funny how using this term really dates my actions.
You can set a sync password to encrypt all chrome sync data before uploading it to Google. This will prevent sites like https://passwords.google.com from working because Google can't see your data.
Am I the only person on the planet who drags-and-drops from the location bar into the filesystem (in a folder for a project usually) to create a .webloc file?
Not only that. Your work application is used for personal stuff, it's super difficult to share a bunch of information scattered over many applications.
What we need is a "file server", and applications that can handle files, instead of saas.
SaaS was nice, because of the distribution model. Also because of licensing, but that can be done without servers too.
We now have good distribution and update functionality, so we should go back to self-hosted files, where we are better in control over our own data.
As a comp-sci graduate, as someone who grew into computing through the late 80s and 90s, the files-based paradigm makes a lot of sense to me. But is it really the ideal model/UX for most people? Files are hard to manage. Most people don’t do library work, or habitually create relationship hierarchies. (I do it all the time; I love a taxonomy, but it’s work, and the general pattern for memory is association, not hierarchy).
I worry the “apps” paradigm focuses users on brands and encourages lock-in, walled gardens, and so on.
I'm 100% with this idea. Managing the file system in a decent way is extra effort and a skill in itself. One that is just adjacent to the concept of using a computer for work.
In fact I'd dare to say having the filesystem as first and foremost UI, is bad UX. We just grew with it, so now it feels like the most natural way to work because we've spent decades getting used to it.
This became apparent to me when trying to teach computers to some people who were like a "blank slate" so they brought a fresh perspective to everything. The concept of applications seemed about right for them. But opening the dreaded File Explorer and swim through drive letters, virtual and real folders, having to be well organized, having to worry about backups of specific folders, etc... was (and still is) a daunting task for them. And one that is just tangential to the work they wanted to do in the first place.
> The concept of applications seemed about right for them. But opening the dreaded File Explorer and swim through drive letters, virtual and real folders, having to be well organized, having to worry about backups of specific folders, etc... was (and still is) a daunting task for them.
Dude, I grew up with computers in the mid-90s and that's all a daunting task for me, too. In fact, it may be WORSE for me than for a "blank slate".
I had switched to Linux on my personal machines for a number of years and then tried to help someone with a computer issue they were having with their Windows computer- I had NO IDEA where their "Pictures" folder was, or why I kept seeing the same file in multiple places as I clicked around the file explorer. I also feel like I was confused about something to do with "Desktop", but I don't quite recall what it was. It was honestly pretty disorienting- I thought I was in a weird carnival house of mirrors.
I don't honestly know --right now-- if you can save a file to one of these virtual "Pictures" places or not. Or, if you do, where it would actually go.
To be honest, I don't know either because I avoided them since the first time they got introduced.
Those folders is precisely Microsoft acknowledging there is something wrong about the files-first approach, but as usual, in trying to make it more approachable, they ended up with an even more confusing solution, virtual folders that try to abstract the actual filesystem hierarchy with some virtual collection folders based on file types.
> Those folders is precisely Microsoft acknowledging there is something wrong about the files-first approach, but as usual, in trying to make it more approachable, they ended up with an even more confusing solution, virtual folders that try to abstract the actual filesystem hierarchy with some virtual collection folders based on file types.
I don't think those are "virtual collection folders based on file types"; they're just virtual folders (=directories) that point to two (or more?) actual folders (=directories). AFAICR you can save .JPG or .PNG files in other folders, and they won't show up in any magic "Pictures" folder; you need to save into one of the actual "Pictures" folders -- your personal one, or the shared/public/all users (WETF it's called) one -- for that to happen.
But yeah, it feels like the "solution" is at least as confusing as the problem was to begin with.
> ...tried to help someone with a computer issue they were having with their Windows computer- I had NO IDEA where their "Pictures" folder was, or why I kept seeing the same file in multiple places as I clicked around the file explorer. I also feel like I was confused about something to do with "Desktop", but I don't quite recall what it was. It was honestly pretty disorienting- I thought I was in a weird carnival house of mirrors.
As I understand it, there are actually N+1 of all these categories of "semi-magical" directories on-disk -- where N is the number of different users registered on the machine -- but each user only sees (and has to care about) two of each category. And the confusing bit is that Windows tries to make it look, to each user, as if there is only one of each.
That is: There is a "Pictures" directory for each user, stored in something like C:\Users\<<TheirUserID>>\Pictures. Then there is also a shared C:\Users\All Users\Pictures directory (though see further below at [1]!) for, well, pictures that you want all users to be able to see... And finally, to top it off, there's the "virtual Pictures directory", kind of an alias (or Shortcut, in Windows lingo) to two directories at once: the users own, and the shared one. Just to make it look all un-confusing and user friendly, "here's the Pictures folder, where you keep your pictures". Road, paved, etc...
So, N+1 Pictures directories where each user interacts with their own + the shared one -- and likewise for the other "magical" per-user-plus-a-shared-one directories: Desktop, Start Menu, Music, etc.
> I don't honestly know --right now-- if you can save a file to one of these virtual "Pictures" places or not.
Oh yes, sure you can.
> Or, if you do, where it would actually go.
AFAIK, the default is the user's own directory; if they want to make it shared for all users on their machine, they have to jump through the hoop of explicitly digging out the "All Users\Pictures" directory to save to.
.
[1] Now, that said, this is apparently based on out-of-date information: As I looked through my Windows 10 box to check on the directory names right now, I noticed that "C:\Users\All Users\" is apparently also, in turn a "shortcut" (=alias) nowadays, pointing to somewhere in C:\ProgramData... So the above is as of now an oversimplification. But AFAICR that was actually how it worked, with the shared all-users directory being an actual physical directory on disk, in Windows NT, 2000, and I think XP. Dunno when it changed; maybe with Vista, 7, or 8.
> the general pattern for memory is association, not hierarchy
But we organize our real lives in hierarchies, too. We have our clothes in their own wardrobe maybe, socks in one drawer, underpants in another.. not the green shirts and socks with the green books and the vegetables, and the forks and knives in one box with our screwdrivers, pliers and pencils.
It's never perfect, of course, some people are messier than others, but the general idea everybody knows and sees the merit of. We navigate and create hierarchical taxonomies so much, every waking hour, that we barely acknowledge them as such. The digital version of that is not fundamentally different from that.
IMO the question shouldn't be "where did I put this, so I can have it?", but "if I had this, where would I put it?". If you know your own or an agreed upon structure for something, it's faster and less taxing, both mentally and time-wise.
Also, I don't just look for things I remember, I also remember things by browsing the shelves so to speak, and that becomes more fruitful and enjoyable with some order :)
There's a difference between the way our minds work and the way reality works. In reality a physical object can only exist in one place which naturally leads to hierarchal organization being the dominant paradigm. On the other hand our minds operate associatively.
When we started to build out computer systems we based the UX on metaphors of real-life tool equivalents. I would posture though that as we become more of a computing-literate society and as computing moves closer to becoming an extension of our minds as opposed to an extension of reality, the dominant paradigm will shift towards associate models of organization.
> On the other hand our minds operate associatively.
The mind doesn't just "work" one way or another (certainly in no way that can be boiled down to a single adjective) and does everything it does that one way.
And hey, that we consider a thing a physical object distinct from its environment is a distinction we made with our minds, rather than the other way around, and that I have folders like "docs/images/photos/people/$city/$person" or "docs/images/created/cheatsheets" is also not because I'm used to that it being that way in real life.
The whole point of a taxonomy is for things to belong somewhere in it, roughly or neatly. You don't have to remember the place, you just have to be the same person with the same heuristics. That enables a very fast binary tree search, so to speak, both when looking for a thing and when looking for a place to put it.
That's a positive, not a limitation or baggage from the physical world, that makes it so great and quick. That's why we used them since forever, including for purely platonic ideas even that have no resemblance to physical reality, and way before computers.
And are we really becoming that much more computer literate, or are machines that can read the books for us becoming more widespread? There is a difference between proposing a better way to store and find things, and proposing someone else do it for us (until they don't).
> When we started to build out computer systems we based the UX on metaphors of real-life tool equivalents.
They started out as tools that were sold and learned and used, now they're turning more and more into a foot in the door for companies to capture consumers however they can.
Taking care of one's own documents and personal affects is part of what makes a person an adult, and if these documents and media get moved into the digital realm, where vast amounts of them can be ordered and re-ordered within seconds, that is all the more reason to think about what they are and how to order them. If that's hard, then that's even more reason to not put it off.
How do you tell the difference between a.) the company gets to be the middleman not being good enough to find what you are searching for, b.) that company censoring you, or c.) you having misremembered that thing existing?
You've eloquently expressed something I've been feeling for a long time, but couldn't put into words myself. Bookmarks and file systems are frustrating ways to organize digital thingies.
So what would be a less frustrating way -- tagging everything with as many (or as few?) keywords as possible, and then ad-hoc searches as looking through "virtual folders"[1,2] with the tag as the "folder name"? And more systematic ones as (SQL-style?) queries of tags with "AND" and "OR" logical operators? Or something else?
Yes - extremely rich metadata combined with robust search features.
For example: "I want to see all..."
- excel files
- that I myself have created (not downloaded)
- anywhere on my hard drive
- tagged with a particular project name
- containing a particular word inside the file
- sorted by "last opened" date
Then ideally you'd be able to save this search/filter/view for future use.
This isn't impossible to accomplish today, but it's so painful and slow that you're basically forced to fall back to folder hierarchies for organization.
I've also been using computers since the age of DOS and felt like I loved taxonomies but once I grew up I found out I hate them. A non-system/code file should better only have meaningful (and also easy to view, edit and query) extended attributes (long and short titles only targeting humans, optional description, creation and last update timestamps independent of when you have technically put it into to the file system or changed some metadata about it, content author field, tags letting you "put" it into several categories at once, type-specific properties like the type itself (so we wouldn't have to use stupid "extensions"), picture size, music bitrate etc). Creating strict single-place (symlinks don't help much in this context) short-named taxonomies for real-life non-programmer files is a huge pain and they often feel unnatural. Coming up with file names targeting both humans and traditional file system (e.g. where you can't use colons and have to keep names rather short because of full path length limits) while also optimizing them to leverage searching isn't a pleasure either.
I am sad WinFS never arrived and I am in a constant search of a good cross-platform tagging file manager.
I've been using hash tags in file names (e.g. "eat more veggies #todo.txt").
To group by tags, I use the smart folders functionality on windows/macos/googleDrive to save a search for items with the tag in the name.
Definitely not as smooth as an OS-level tagging feature, but it works in a pinch. Should be easy to port to other systems with some scripts in the future when/if this functionality becomes mainstream.
There is the problem of one document not necessarily being one file. Sometimes you have sidecar files or some meta data that is stored somewhere else in a database of sorts. So it can be messy, especially dealing with antiquated formats like dcim (easy file name conflicts), gopro leaves extra thumbnail files scattered around, wtf is even DS_STORE, etc etc. I also think that file managers are not powerful enough for searching and managing all kinds of data, the fact that we need photo management software proves it.
It's not perfect, but the macOS way of creating "bundles"; where a directory looks like a single file if it has a particular extension is 99% of the way there. The average user double-clicks and it opens in the relevant app. The power user can right-click and choose 'view contents', which opens it like any other directory.
This can also be done via compressed files with an application-specific extension. We use it at work for Python zipapps, and of course everyone probably knows .docx and .xlsx
> file managers are not powerful enough for searching and managing all kinds of data, the fact that we need photo management software proves it.
I don't want to be responsible for manually managing all my photos, copying them off cards or downloading from online services or whatever. I also want to view the photos in various ways: I'm regularly browsing them via the map view, or person tagged in an image, and so on. Hence the photo management software that handles all that for me.
But the photo management could certainly be better integrated into the OS, ie open your Photos folder and rather than seeing raw image files, it would load the photo management.
Something that is evolving for certain common types of files (images, for example) is an application-mediated storage, but where apps "share ownership" (or rather, declare awareness) of files rather than owning them exclusively.
So e.g. my camera roll, Google Photos, and Facebook comments can all give me a window onto my photos.
Those "windows" are currently inconsistent and kind of painful, but I see the germ of an approach there.
> Those "windows" are currently inconsistent and kind of painful, but I see the germ of an approach there.
There is an approach here, but I can't see it as anything other than a hostile takeover.
The "shared ownership" of application-mediated storage is not under user control. Depending on the implementation, it's either controlled by the platform and otherwise sandboxed (i.e. you can't get at the data from outside of a participating app), or - more commonly - it's controlled by mutual business agreements between app vendors. In that latter case, you still can't get at the data directly, and the app you're using can suddenly stop being able to access the data, because the vendor that provides access revoked API access to the vendor of your app.
For a random example, see e.g. Spotify revoking API access to SongShift for no good reason, and then restoring it later, possibly due to GDPR pressure by a fellow HNer[0].
Regular files are bits on your storage. They stay forever independent. Application-mediated storage is just a window into business partnerships.
I don't think your criticism is accurate. The shared Photos folder on my phone is a bit different than the database of photos Google Photos has access too. But don't get me wrong. I want to criticise the shared ownership model. I just think the model the PP intended to mention was different than the one you criticised.
The Photos folder is just a folder. Applications that have requested and been granted permission can access it using a user interface of their choice. This is the "shared ownership" location.
The Google Photos database is stored on Googles servers. Third party applications do not necessarily have access to it. It is thoroughly owned by Google.
The "shared ownership" model somewhat blurs the lines between the two of them. I think this is a considerable part of why this approach is poor: it is considerably more confusing than the old filesystem approach.
With the filesystem, you know exactly where the file lives. Most people know how to copy files and send files and can understand putting something onto a shared drive. The shared ownership notion blurs the lines with exclusive app ownership, and the idea that there are files which I can manipulate becomes obscure. It is hard even for experts to distinguish between local files and remote database entries. The distinction between copying a file and using remote tools to share access to the same file (or a copy of the file) becomes frustrating.
The way forward needs to be about respecting and empowering the user. The user wants to feel in control of their data - that is why we have the GDPR and other comparable laws. The user doesn't want to subordinate usability to data trust; they want companies to fulfil both, and since there is a hole in the market, they have turned to regulation to help plug it. Unfortunately, companies have not responded in ways that give us grounds to trust them.
A new model based on user-controlled resources and programs that can access resources (given to the program by the user) without gratuitously logging in should be the way forward. This doesn't mean a reversion to the old approach. It had its problems. But the future should look more like the past.
File-systems work very well for people who understand how a computer works. And I'm afraid your right about the "apps paradigm", it looks easy within the app but the extended usage is difficult.
Looking at Signal (the messenger app) on iOS we see the problems, they struggle creating save backup. The are not allowed to store the backup on the file-system only inside the app, which counteracts the idea of a backup. The other option is a cloud backup, most likely and third-party servers, which counteracts the idea of security and avability. Okay, but through some weird menus you could copy maybe something the a crippled third party app, let us say Files (not a file-browser!) from Apple.
PS: I still wonder how many people could have grasp how file-systems work, if Microsoft Windows didn't provided that weird desktop metapher. Which was placed within the the "own files", which incluced the "Desktop", all accompanied by the drive letters.
And UNIX? This is a tree!
iOS backs up application data normally. The Signal developers blocked it. And they said it's likely they'll remove file export and import from the Android app once it has history transfer like the iOS app.
Storing an encrypted database in iCloud isn't a problem. And you can back up iOS to a computer instead.
Honestly, I think a third way would be good, but sticking with a way would be even better.
A huge, huge chunk of my last year was spent teaching dozens of teachers (long story) who were used to, and very productive with, the '90s way of using files were everything, how all these new cloud things work. The whole thing was extraordinarily confusing. Lots of things that they depended on didn't quite fit with the "let's do away with files" approach, and the fact that they couldn't do it more than compensated for any productivity gains due to easy collaborative editing and the like.
We're all computer nerds here and love to learn new things about computers but most people aren't. People have treated the sick, built the largest buildings in the world, gone to space and developed new vaccines using this clunky, inefficient, Stone Age file-based interface. I'd say it's not too shabby.
Unless a hypothetical third way enables measurable, verifiable improvements (and I mean measurable, not "we asked 10 interns to rate how easy it is to perform these actions", that's an anecdote, not a usability study), that third way would be a net loss for virtually everyone except us.
FWIW: I think the constant UX churn in our industry is just the symptom of an identity crisis. It's what happens when a company (or, as is often the case, an entire industry) is increasingly unable to produce meaningful fundamental improvements, so it's churning visible, but practically inconsequential changes in an effort to justify the money it burns through. In our bubble we all go ooh and aah over the latest UX improvements of whatever piece of software we run into again, but truth is most people just go aww fsck, how the hell do you do X now, over and over again?
I agree completely. We need a way to facilitate interoperability without requiring normal humans to know/care about bytes on a disk in some hierarchy (directory tree) where, frankly, your hierarchy WILL eventually be wrong.
Remember back in the old days, organizing your music files into a directory hierarchy- often organized by band? Then, inevitably, two bands you listen to release a song where they collaborated. Now your system is fucked- where do you put that song? It's why "tagging" things became a thing (emails, magical "Pictures" directory in your OS's file manager, etc).
There has to be some kind of extension to the idea of "tags"...
From what I’ve observed working with users, a pretty huge chunk of them (if not an outright majority) really struggle with file management. Some might not be motivated enough to organize files, and others just fundamentally do not understand how the abstract concept of hierarchical file systems work (programmers are great at dealing with these abstractions; end users generally are not)
My boomer dad used to hate folders. His home directory was completely trashed with files. Impossible to find anything, and his aversion to folders became a self reinforcing problem.
But with the lockdowns he was spending more time behind the screen and actually started to structure the mess. Now he’s even happily using a NAS to archive stuff.
I guess the principle of having apps manage files is even easier to grok than folders. However if my dad can do it on his own then it’s not like people just can’t learn folders. It’s really only a matter of how do you motivate them.
It doesn't have to be "dump everything in one big folder", traditional file systems are still useful as a way to uniquely identify a file (literally a URL), but more and more, I use search to interact with data.
And that's the way we are going. For example, the Start menu in new Windows versions is best used with search. You can still do it the "old way" but for me, it is clear that it is now secondary.
It's called Search Everything, and it's probably the best and most useful Windows utility ever written. I easily use it a dozen times a day, there's likely been days with over 100 searches.
The long term catastrophe will be in archival: nothing rots faster than an abandoned application.
We already face the same problem with media. I have source tapes for which no reading device has been manufactured this century. This new trend can only magnify the problem.
> Compare that to the "application-centric" paradigm that dominates on the web, in mobile OSes and recently in desktop OSes as well: Here a program "owns" its data and you are supposed to interact with the data only through the program.
> You used programs to edit and manage those files, but the programs didn't "own" the files: A file was generally independent of the programs that are used to open them.
That must be why .XLS(x) files have had the Microsoft Excel icon and the text "Microsoft Excel Document", .DOC(x) the Microsoft Word icon and the text "Microsoft Word Document", and so on and on, in File Explorer for the last three decades or so.
IOW: WTF are you talking about??? It's the absolute other way around; applications have always "owned" their respective files.
Sure, extensions identify the format of a given file but the point is that you can even access the documents as individual files at all, as opposed to having some sqllite db or other combined, binary format that isn't at all portable from the application which owns it.
Depends: do I check the "Set as default app to open Excel files?" check box during the install, or not?[1]
But, anyway, I'm not quite sure how that disproves my point that in general, "applications own file(type)s" on Windows. Actually, I'd say the fact that you can set another app to take over ownership of some type only reinforces it.
___
[1]: OK, I'm actually not sure that's there any more. But many apps that are capable of taking over each other's file formats at least used to have those.
Not that anyone asked, but IMO it’s a problem of our attention-based capitalism.
Now that there is real money to be made from applications that are mediocre at best, every application has to compete for “engagement” and “brand awareness”. Instead of working to be the best utility for File X, they are driven to be the brand with the most installs, likes, and comments. Those are two radically different goals.
> for many users, the way they create a new file is to find an existing file of the same type, copy it, then open the copy and delete everything in it.
Cringe.
> And who among us can say they never created a new class or project by copying an existing one, and then deleting everything inside?
Quick-n-dirty templating. The chances are the old document has all kinds of preferences set up - margins, default font, heading formats, for a word processor document. Line and stroke preferences for a graphics program, whatever. It's not as dumb as it seems.
The New File option on Windows is one thing I really miss on MacOS. I set up a macro or something that added it in for text files years ago, but it got blown away when I changed machines or upgraded a few years ago and I can't remember how I did it. I could google it, but eh. I'll just have a moan about it next time I need to do it instead. Bah, humbug!
That creates files that, when opened, create a copy of themselves in the current directory and open that.
That’s a poor implementation (a good one would open the file as a new document ¿and tell the app the default directory?), but probably the best one an do without cooperation from applications. System 7 did that better, but only for applications that supported it, as did Lisa.
I can relate. I work with CADD software. Throughout the day I will jump between projects in different survey zones. It’s much faster to copy an existing file in a given zone and open it than go through menus and apply certain settings for each file. In fact, the first file I make for a project is projectname_blank. Then this gets copied everywhere.
> It’s interesting because copy and pasting a class gives you something humans love: a template!
That’s exactly what the OS/2 workplace shell did back in the early 90s: You had a “templates” folder where you would drag one of the many notebook-like icons and drop a brand new and empty file of the corresponding type.
When installing OS/2 programs they would register new file types and create a template in this special purpose folder. Man, that were exciting times!
Didn’t Ubuntu also support templates up to a point?
Xcode doesn't go that far but has the plus button in the top-right corner. Clicking it will open a list of snippets. Most language constructs are in there, if/switch/class/struct/etc.
Weird enough I never got used to it. My desire for templates is more on the implementation level. For example when I need to draw a circle, I google for "SwiftUI custom shape", then copy/paste a working example, and from there, edit the "template" until I've got something going.
This sounds an awful lot like prototype inheritance. Turns out people don't seem to like it - it's essentially vestigal in javascript these days, most people seem to use the class system built on top of it and that was true even in the good old days before support for it was added to the language keywords. It was rare to find code that actually used prototypes as prototypes rather than slightly odd ways of defining classes.
I don't think the problem with prototype inheritance comes from whether people like creating things by taking something that already exists and modifying it. In fact, people very often use classical inheritance to emulate prototypical inheritance ("oh, i'll just add an extra method here and override that method there").
The problems normally relate to maintenance and change over time:
1. We reject classical-inheritance-emulating-prototypical-inheritance because it makes it hard to change the original. But copying a file and changing it doesn't have this problem, since the copy and the original are forks. If you need to make changes to both files, then you need to make changes to both files.
2. We prefer classical inheritance because a class is a description of how you can use an instance of that class. The class definition is usually very declarative and lends itself to great tooling support. Prototypical inheritance is imperative by its nature. This means there's no generic answer to the question, "How can I use this object", but only "how can I use this object right now?". But copying a file and changing it doesn't have this problem, since the copy and original are data, whose use is determined by external tools.
Another commenter in this thread specifically claims that prototypical inheritance was derived from this model (with a sense of optimism and joy, I think). But the fact that one extension of this model failed didn't mean the whole model is a failure. In this case, the suggestion is just to recognise what a user is doing and facilitate that. I think that's a lot less trouble than a language feature. (Actually, I think Jet Brains IDEs have a lot of features that tend towards this. They just might not be quite there.)
yeah, even though the 'letus copy and old file and empty it' to me it shows how average users brain sees and wants to see the computer/filesystem. ex-nihilo isn't natural at their level, and copying something they handled is the path of least resistance. MS should jump on the occasion
I think this was discovered by Alan Kay and team in the 80's and resulted in the implementation later of prototype based computer languages like Self an Javascript
Reusing styles is a huge valid reason. Even today Google Docs/Slides has a convenient “Make a copy” button that is easier for me compared to setting up a template.
I just copy -> rename -> open -> select all -> delete
For example, when (being dragged into) making PowerPoint presentations, I tend to manually style two or three slides (e.g. title page, chapter divider, content slide), and then create actual slides through "Right click -> Duplicate Slide".
This rules, honestly. Seeing and making shit like this was what turned me from "CS student" to "genuinely enjoys software engineering." To this day, little stuff that makes a life better is the best part of anything I do.
When I catch myself doing this more than two or three times for a particular document, I save it as a template after I finish clearing everything out. If it's one I'll use often I'll stick it in my templates folder so it shows up in the new file context menu (on Linux/in Caja). I haven't figured out if there's a way to achieve the same workflow in Windows, but if there is I'd love to hear it.
I'd really like to just start making all of my multiplied documents as database forms that just pull from a central data source. I haven't found an easy way to do this that works on both Linux and Windows and can pull from a central source over the network (besides implementing it myself in php/mySQL, which is a few orders of magnitude more work than just making a LibreOffice template).
One of the features I used to love on "classic" MacOS was the Stationery Pad.
Basically you could create a file, then mark it as a "Stationery Pad". Next time you double-clicked it in the Finder, it created a copy and then opened the associated application.
Instant templating in a way that ordinary users understood.
This is why it's important to give any 'new' code a few passes before committing it; it's pretty likely it'll be used as a template by yourself or others for similar code in the future.
"Create a thing here" is a really powerful interaction. You often start the process of creation by navigating near the relevant bit (path in the file system, module in the codebase, etc), and then realize that you need a new file/class/method/whatever in the specific place you're looking. A consistently-available "New" menu seems like a good primitive in the computing experience.
Key insight. One annoying thing in many workflows is different programs and file environments (GUI or CLI) bein gout of sync with the patterns of the work I'm doing; why (I ask myself) am I having to traverse the same routes around my directory tree like a squirrel carrying nuts and and berries back and forth?
There's no flow between the OS and application UI in most instances.
You're welcome, I'm sure. I'm lucky enough to have a decent size yard and I spend a lot of time trying to see things from the perspective of the animal and plant life that inhabits it. A lot of our information problems (imho) come from too much detail of specificity at the wrong scale. You don't look at a tree as a collection of leaves, or draw one by cataloguing all their sizes. Likewise a tree rarely grows as a pure function of its DNA-encoded phyllotaxis patterns, but rather a combination of those and the variations of its environment - soil composition,w ater, other roots, helper fungi, sunlight, prevailing winds, and local animal life. It's truly amazing to watch the interactions between different plants and trees over a period of years.
I think because we're so used being able to catalog, measure, categorize and sort our various files and directory structures, manipulate them programmatically, have our browsers or operating systems identify a particular leaf by reference or just by searching for some of the micro-structure within it (usually words) etc. etc. we tend to overlook the organicess of how a data collection grows and opt instead of producing analytics measuring it. It'd be like trying to describe a tree with tables of vector statistics about the angle and length of branch sections - it's valid in certain ways, but doesn't give you a good sense of the tree's shape or structure. It's as if we've developed a sort of techno-myopia towards the shape of our own output and activities, and approach everything by dissecting it into slices and then ranking them by various criteria.
That goal has been stated and sought repeatedly, usually with poor results.
Microsoft Bob is probably the most infamous example. An early-dot-com-era roommate worked at Xerox PARC which had its own spatial 3D file manager / management interface. There were three principle problems:
- It severely taxed the limits of available consumer hardware at the time.
- It was confusing as hell.
- It didn't solve any real-world problem(s), and made numerous others worse.
Though in fairness it did somewhat resember Doom / Castle Wolfenstein....
File or document management shouldn't be the most intensive process your computer does, it should be one of the least intensive, saving processing power for Real Work, and not being resource-starved when you actually need to use it.
The organisation(s) that seem most useful are lists, lists of lists (hierarchies), tag-based systems, or search-based systems. (The fact that file-based search remains primitive in most system is its own small wonder of modern computing, though yes, the situation is slightly improved over, say, 30 years ago.)
Oh yes, I remember being impressed by its awfulness. by comparison Clippy was...not terrible.
I think part of what made 3d and other very visual file managers so bad (or at best, very slow like Treemappers) is the effort to render everything accurately at once, which is bound to be slow across terabyte scales.
Maybe we would be better off exploring Voronoi/blob/fisheye network diagrams for representing context, with the size indicating the number of files nested within. The Carrot2 search engine implements a variation of this idea which is sometimes very useful for topic exploration.
Render lag and lossyness is part of it, but there's more.
I've had a fair bit of experience with large book archives (university libraries), and have a pretty good sense of what "a million books" looks like (a large on-campus multi-storey building might house 1--5 million books). There's a physical progression, from the words on a page (~250 typewritten, about 500 typeset), to pages in a chapter, chapters in a book, books on a shelf, bookcase, aisle, library floor, building, campus, etc.
A well-organised library gives structure to navigating that space, logically, metaphorically, and literally. And there's a lot of hard work that goes into that organisation.
Simply tossing a 3-D overlay onto a file manager ... isn't that. And most of the projects I've encountered either don't realise that, or don't give that fact its due.
For that matter, the concepts of search and locality (as in, works near each other) have entirely different manifestations online and in a physical archive. Shelf-reading is still one of my favourite pastimes.
What you really want a lot of the time is New for Project (...based on template, or based on copy) with support for projects built into the OS and applications.
So - for example - instead of folders you'd see the same list of popular/recent/alphabetised projects in every app.
And you could link project collections into super-projects with links and/or copies of specific data and working environments.
The nested filing cabinet + aliases metaphor is old and never really worked all that well anyway, but we're stuck with it because it was easy to implement back when all of this was first designed and computers were a thousand times slower.
Sort of… it is the idea of having a bunch of files that are multiple types located in an organized space. E.g. in your home office you may have papers, but also notebooks, envelopes, cds, etc; whatever you find is useful for storing information. You have them organized on your desk in a way that works well for you. If you need a tool to read one (like a cd will need a cd player) you bring the item to the tool in order to use it.
Modern computers are trying to move away from the concept of a “desktop” or filesystem, and instead you open up the file you want from within the program that you use to open it. It would be like you have all your cds in a big jukebox that you can select from, or all your documents in a big binder, or something like that. They become isolated within the devices you use to read them.
It may be better for some people, but that is not how I like to organize things. Particularly when I want to move something from one device to another.
I've gone to a very document-heavy workflow over the last few years. I still program but a lot of what I do is about collecting and curating documents and data on people and organizations and then synthesizing that information in various ways, sorta like business intelligence. So I have maybe 20-30k documents/media and maybe ~100 top- and second-level folders that I access regularly.
Luckily I have the kind of memory to put things somewhere and then know where to look a year or more later, but in the last year or two I've noticed that I'm using the quick access (ie your 20 or 30 most recent files) in a very similar matter to a stack in assembler. Also a lot of my busiest folders are sorted by date rather than filename because I depend heavily on the contextual memory when I learned things.
Sure, it's just a pity there's no kind of shared context, such that if the last 8 or 10 operations were in a particular folder, a new operation with a similar document type might default to looking there.
On Windows, there is a shortcut to recent folders on the left panel. Also, in most open/save dialogs the file name field has a history pop-up list with full paths. You pick one, delete just file name, hit Enter and jump to it's folder.
> There's no flow between the OS and application UI in most instances.
Directory Opus (a file manager for Windows) somehow extends most Windows file pickers so Ctrl+G moves the file picker to whatever folder Directory Opus has open. I still feel a twinge of satisfaction every time this lets me skip re-traversing my file tree. I don't think it does anything for a Qt file picker though.
I use that method or copying an existing item also because I dislike the save process otherwise. Saving something I have open is an instant and silent process. Saving something that's been created new is a pain. I prefer to pick the location via Finder than whatever methods the application has decided might suit me.
It’s like plonking a shovel in the ground and saying this is the spot.
Metaphors for everyday actions don’t need to be about forcing the real world into the computer world. A lot of the ways of thinking feel like they are one and the same.
Another example, for me, off the top of my head: rummaging with find and grep but then scanning the output with less feels identical to hunting for red 4x1 Lego blocks or M8 nylon locking nuts.
IMO browsing to the location first, and then creating the thing in that spot, is fuzzy search. The equivalent to "plonking a shovel" would be knowing exactly where a file should go in the hierarchy and touching/creating it with a single invocation from the top-level.
why? It's basically a poor man's fuzzy search. You do remember some part of the name you are looking for so you filter your data set with what you know for sure and then visually scan the rest.
The status of a non-saved document in all software is always a bit strange too. In Confluence it’s a draft-before-creation, as opposed to a draft of an existing page.
To me, working in a new unsaved document feels uncomfortable. The idea that your Word window would already have an underlying file in the correct folder is reassuring. You can smash Ctrl+S all you need.
It also promotes being able to hit Ctrl+S to save state as soon as any work is entered. Also PLEASE standardize on ONE for each keyboard language!; For English that's Ctrl+S.
Not sure if this is what you’re saying, but macOS no longer needs you to choose to save in order to retain your work. Rebooting after having 50 unsaved documents open means you get the same 50 windows. Most likely with the very last letter you typed still there (other than that: maybe a word or two needs to be retyped)
I'll often use touch just that way, in part because I can also apply standard features / functions in the process, particularly a datestamp:
touch <mnemonic-$(datestamp)>
Where datestamp is a bash function:
datestamp () { date +%Y%m%d; }
In several scripts / tools, the title (and other metadata) are automatically generated and added, with sanity checks for characters, casing (lowercase preferred), and tokenisation (usually '-' between words, '_' between elements, and '--' between repeated elements, e.g., multiple authors. The results can be longish, but descriptive, filenames. With a low collision probability.
There is much redundancy in windows. But it's redundancy that things about edge cases like these. One could even edit it if one wanted to. It'd be nice if Microsoft had a nice and easy front end for it. https://thegeekpage.com/how-to-edit-right-click-new-menu-in-...
Definitely, and not just for creating things. Continuing here allows you to keep your train of thought without a distraction. The button I use most in my file manager is 'Open in Terminal' and I love it because I don't have to re-navigate through the tree.
I use the New context menu exclusively to make new txt files. Everything else is open the app first territory.
Explorer is weird in a few ways.
- doesn't show NTFS alternate data streams.
- hides "copy as path" behind a shift-rightClick context menu. This is handy for running scripts, but why the "shift" modifier? Same for "Open commandline/powershell" when right clicking whitespace of directory.
- copy and paste a file listing. IE a simple "dir". Or checksums to verify downloaded files. Nope, that requires 3rd party extensions.
Thankfully newer explorer has much better UX for copying/overwriting/deleting files these days.
>This is handy for running scripts, but why the "shift" modifier? Same for "Open commandline/powershell" when right clicking whitespace of directory.
Not a solution to your particular gripe but you can actually type "powershell" or "cmd" (minus quotes) into the address bar in windows explorer and it will open in that directory.
Yes, and there is a long standing bug. Once you have done that, if you go back to the folder window in explorer, and try to select/copy the folder path, all you will get is the path to cmd.exe instead.
Further clarification: google and 3 seconds of testing advise you can run any executable in your PATH environment variable.
Though there is some other step going on as "powershell" will set the current working dir on startup. Possibly a class entry in registry defining the full command to run.
Another one that I use from the address bar is "subl -n ." to open a temporary Sublime Text project. I imagine you could do something similar with VS Code.
That didn't work in windows because it tries to open the unix shell wrapper "code" instead of "code.cmd" for some reason.(Because I have wsl2 installed?) Type "code.cmd ." instead works.
I looked into it and it is because I have a folder in "my documents" that is named "powershell". If I rename that folder typing "powershell" opens a new powershell prompt.
Same here. Exclusively for txt files. Especially useful because sometimes you ONLY need a txt file with a title, no content, to act as a crude bit of meta-data for a folder.
The excuse given in the article however just seems like rewarding bad behavior, and explains at least one reason why the Windows GUI is such a disaster (at this point, it's just years and years of junk accumulation as well, but even in 95 there always seemed to be at least 3 ways of doing the same thing).
That sort of multipath convenience is a dying art. That there are so many ways to accomplish a task is one of the things I admire most about Windows (and to a lesser extent Linux) GUI design
Modern app design almost always forces you into the developer's wonky custom save feature, if there is even a manual save at all, and with webapps you are forced to use cloud storage (possibly with a rental fee attached) as opposed to files on your local device. It would be really nice is everyone gave me standard open/save dialog boxes with all the OS accoutrements; I can't emphasize enough just how handy it is to be able to copy/paste, or create a new folder, or even manage files/directories or even launch programs from within a standard dialog... all because it is using the same view controls that Explorer uses!
I'll bet you wish "New Text Document" would be the first choice by now too, using most-recently-used order. Has anyone ever right-clicked and said "Yeah I want to make a new Microsoft Access Database here"?
It's too late, my muscle memory is firmly embedded. I still find myself going to where "Add/Remove Programs" in the old control panel but Windows changed it to "Programs and Features" decades ago.
Since Windows 8 added the ribbon to Explorer I've always put the copy-as-path button in the quick access toolbar (right click on the button -> Add to Quick Access Toolbar) for simple pervasive one-click access.
Apparently Windows 11's Explorer is ditching the ribbon for a simpler looking toolbar. Most people I've seen who've tried it seem to be responding positively due to the less cluttered appearance, which is understandable, but TBH as someone who actually uses a lot of the Explorer functionality I'm not looking forward to more stuff being buried.
In some contexts pasting a copied file pastes the full path to it. For example, copy a file, then paste into the Open dialogs name input, and you’ll get the full path to the file.
I hate that macOS got rid of the textfield for the path. You can display it only using Ctrl+Shift+G, and it opens a second popup with the single text field, but it is not working together with the UI…
An optional -Algorithm flag lets you choose between MD5, SHA256, etc. It's nice to have this built-in.
For 3rd party options I really like HashTab [0] which is free for personal use. It places a configurable list of hashes in right-click > Properties, with a bonus of comparing the hashes against one you might already have on your clipboard and giving you a green "OK" if it matches.
yes, I know. I can't fix the Windows GUI, but I can try to offer workarounds. Not everyone knows all of the little things you can do, including myself.
Throw a new pane into its main content preview frame, tabs on both the new and old, label them "Main stream" and "Alt stream" respectively? Something like that.
I like what they have in some Linux desktop mangers. You get a 'templates' folder in your home directory with default empty files which you can add, change & remove line normal files. Then the new sub context menu lists those files copying them when selected.
And macOS has the "Stationery Pad" file attribute, where a "Stationery Pad" file has the semantics that whenever you open it, you're actually duplicating it and then opening the duplicate. (I believe this results in "Stationery Pad"-derived documents acting much like new blank documents in most programs, in that upon attempting to close the document, the program will force you to choose between discarding or naming the new document.)
Microsoft Office includes similar functionality with its template file types, such as (in Word, for example) .dot or .dotx, in case anyone saw that and wondered what it’s for.
My strategy with those was to make the .dotx read-only and remove delete permissions so it was also in-tact on a network drive, and office workers can double click to start a company form letter.
Thanks, good tip. You can also make the template appear in the “new document” screen under the personal tab if you fiddle with some settings and put the template in the right place.
macOS post 10.7 also has the "Locked" file attribute; and optionally auto-applies "Locked" to documents after a set interval.
"Locked" files behave similar to "Stationery Pad" files, though with slight differences in workflow. You can open a "Locked" document, but when you attempt to make any changes to it, the program will pop a modal informing you that the document is "Locked", and asking whether you want to 1. unlock the document (and then apply your attempted change to the original); 2. duplicate the document (and then apply your attempted change to the duplicate); or 3. cancel your attempted change.
"Locked" documents entirely subsume/obsolete "Stationery Pad" documents, IMHO. Locking gives you all the benefits of edits triggering a duplication of the document; while also offering you the option to edit the original if you so desire (without needing to close out of the document and modify its attributes first); and without creating unnecessary duplicates when all you wanted to do was view the document.
What a weird hill to die on. I gave up trying to navigate the Start Menu to launch programs around Win7 in disgust of Windows' continued "helpful" reorganisation of it.
My main way to create new files is DEFINITELY "rightclick -> New -> *", because I usually have the directory I'm working in already open in Explorer, because that's where I'm doing my work, so I'm already there! ... The alternative to finding Paint in the start menu and then later on finding my folder in whatever convoluted network drive I'm working on to save the file, is just hitting [Enter] to open the file you just made.
Agree on all points, but I just wanted to mention that the "finding my folder" step got a lot easier for me when I noticed I could copy and paste paths. With my folder open in the explorer window, I just click in the path display box, ctrl-c, and then paste it into the save menu's path box.
Much faster than clicking through a web of deeply nested folders.
Although, of course, this doesn't work when some app has rolled their own save/open menu that doesn't allow for navigating directly to a pasted folder path.
Maybe my reading comprehension failed me, but my takeaway was that the article was very much not in support of it. "Why does the New menu even exist for creating new empty files? What’s the point of having a New menu anyway?" Supports my view, I feel.
The rest of the article is a schizophrenic compilation of often single-sentence paragraphs barely relating to each other. Regardless, having your articles' title and opening sentence to mean the opposite of what you intend is pretty bad writing, if that's what you're proposing he's doing.
(edit: Sorry OP, apparently you've touched a nerve here)
That makes the whole article make a lot more sense, thanks. I guess I was reading the body as if it was elaborating on (what I read as) a complaint in the headline, not a question leading to an answer.
The introduction of win+"stub" in Win8 was pretty great, but with Win10 this has been polluted by "search the web for my program" appearing just a fraction of a second before the program itself. Sometimes it even brings up the installer .exe that's still sitting in my downloads folder before it brings up the program itself.
There's a registry setting you can change that completely disables web results. Aside from hiding results your didn't want in the first place, it speeds up start menu search a bit. I'd need to Google it so I'll leave that for you to do yourself if you're interested.
Obviously that's not very helpful to the vast majority of users, who are mostly not techy enough to touch their registry.
> I gave up trying to navigate the Start Menu to launch programs around Win7 in disgust of Windows' continued "helpful" reorganisation of it.
Same, and I was annoyed about it briefly. Then I realized that hitting the Windows key and then typing the beginning of what I wanted (which gives you some combination of the Run command + searching the start menu) was way faster than navigating a menu. If I need a new text file, I can type "[Windows key] n o t e [enter]" in under a second.
> The alternative to finding Paint in the start menu and then later on finding my folder in whatever convoluted network drive I'm working on to save the file, is just hitting [Enter] to open the file you just made.
The real alternative is hitting Win+R and typing mspaint
- Browse to a sub-directory of OneDrive using Explorer
- Right click
- Create new Word document
- Double-click on Word document
- Click title bar to see where document is stored
- Get prompted to save document to OneDrive
- Press Upload
- Copy of document is created in root directory of OneDrive
- Double-click newly created document in root directory of OneDrive
- Click title bar to see where it is located
- Get prompted to save document to OneDrive
- Press Upload
- Another copy of document is created in root directory of OneDrive
- Press file, Save as
- Press Browse
- Browse to subdirectory of OneDrive
- Press save
- Click title bar to see where document is stored
- Get prompted to save document to OneDrive
- Press Share
- Get prompted to save document to OneDrive
- Press Upload
- Copy of document is created in root directory of OneDrive
This shouldn't happen. If you create a Word document within a subfolder of OneDrive, and open it in Word, it should be saving to OneDrive with autosave enabled.
Perhaps you are using an older version of Word and/or the OneDrive client?
The new-menu is the one feature from Windows I wish was present in macOS. Especially for text files. When I’m in a folder, many times I want to open the current folder in some kind of app (terminal, code editor) or I want to create a new text file
Just drag-and-drop, you can pick up the current folder in Finder bij dragging it from the titlebar (with a slight delay, else you move the window) and dragging it to any application in the Dock you like (even the Terminal, which will cd into that folder).
The other way around, if you are in a terminal, use the command open[0] to open the current folder in Finder, or a file in the corresponding application.
Create a folder somewhere. Call it "New documents" or something.
Create blank text file(s) of the type you want within that folder. For example, I have a blank.txt which opens in TextMate, a blank.rb which opens in TextMate, and a blank.rtf which opens in TextEdit.
Lock the folder (by selecting it, Cmd-I, check "Locked").
Put the folder in your Dock.
Hey presto. You can now create a blank text file anywhere simply by dragging it out of this folder in the Dock. Because the folder is locked, you won't delete the original - macOS will make a copy for you, every time. Just rename it before opening and you're done.
The replies to this thread highlight how there are two different camps of computer user.
One camp, full of very able computer users, responds immediately with techniques and suggestions for how to do something, because (1) that's what they'd want to hear, and (2) they're generous with their advice.
The second camp says "Why shouldn't the UI do what my intuition clearly craves? I'm not interested in learning alternate ways to bend my mind just to do something that Apple could have provided with minimal effort."
Back when I used Windows, I actually used the New > Text Document item discussed in the article all the time. It created an empty, 0-byte file, so I'd rename it to whatever file extension I needed. There was a folder that contained the templates for this menu so you could add or remove blank files for any type, but I only ever used the .txt file one.
There are HUNDREDS (not an exaggeration) of Mac OS shortcuts out there.
Take a look at this video. This guy is awesome. Check out his other Mac OS tips videos as well and you are very likely to find what you are looking for and then some.
This brought back memories, maybe Win98, where you would right click then accidentally mouse over the "New" menu and have the computer swap for 15-20 seconds in order to bring up the large list of new things you could possibly create.
Explorer context menu is extensible (via COM), and lots of apps register themselves there for various minor features. The more you have registered, the slower it loads, because it has to instantiate all the components backing those menu items - and they're often registered as out-of-proc servers that require spawning.
Even if it shouldn’t, does it really matter? If you can’t change it, regardless the reasons, and getting an SSD is a fairly cheap/simple solution, then why wouldn’t you just get an SSD? Nobrainer.
> User research shows that for many users, the way they create a new file is to find an existing file of the same type, copy it, then open the copy and delete everything in it.
> For people with a document-centric view of the world, programs aren’t really things that you think about. What you really work on are documents.
Okay, but I don't think people create new paper documents by photocopying an existing document and covering everything with correction fluid. The user interface of those physical document-authoring tools (typewriters, paper and pen, etc.) seem to make it quite clear how to start a new blank document.
The fact that people can't discover any other way of creating a new document on their computer is obviously a legitimate problem, but I can't see how the New menu is a particularly good solution because it doesn't seem any more discoverable than the list of document-authoring programs in the Start menu.
I'm of course in agreement that user research is vital and that not everyone is aware of what you might consider the "obvious" or "best" way to create a document on a computer. I would like to see more details about how and why the New menu came to be (apparently) the primary solution to this UI problem.
> I can't see how the New menu is a particularly good solution because it doesn't seem any more discoverable than the list of document-authoring programs in the Start menu.
I think you’ve missed the key point of this article, which is that a lot of people use computers without a clear idea what programs are. They know they can double-click a spreadsheet file and have a window open that lets them do things with that spreadsheet; but to them, I guess, that’s just “what a spreadsheet file is like” and there is no notion of this thing called Excel which is mediating their experience of the file. To a person like this, “discovering the program in the Start menu” is not something that can happen within the bounds of how their ontology of computers works.
It’s a credit to the designers of Windows that they design to accommodate users like this, though it also goes a long way to explaining why Windows is so annoying to many professional computer users.
This is actually an interesting assessment for me, since smartphones are pretty much the exact opposite (can't even see the filesystem on some of them): There's only apps, and the apps have stuff in them. Sure there's ways of exchanging data between apps, but documents/files aren't really a thing.
Conceptually, that means I feel like I'm using services/tools to interact with this abstract 'data.' By keeping 'data' abstract, it feels less solid who owns it, who's responsible for it, and where it is. Now I'm interested in the opposite system where the 'documents' are the core concept of the device, and programs are just "things your computer/smartphone can do with this document." Really make the data feel like it's /there/ you know?
I understand that completely, and my response again is that discovering the New menu doesn't seem easier to me than discovering the list of programs in the Start menu. I don't think the person's knowledge about what a "program" is is particularly relevant, especially since most of the items in the New menu are of the form "{program name} Document". I think it's pretty clear that in most cases the person must (and likely will) be aware of the names of programs they want to use (like Microsoft Word) even if they don't have explicit knowledge of what a "program" is. (Granted, a couple of the options do not contain the name of the program used to author them, like "Bitmap image" and "Rich text document," but those are the exceptions.)
Most likely, a user of the New dialog was shown “right-click here and select this and now ‘Word Document’ and then…” and thenceforth has followed these instructions essentially as a mystic ritual which achieves a necessary result, without a real understanding of what the steps mean. They don’t know that they’re running a program, they just know they’re making a document appear on the screen. Though they could probably guess the phrase “Microsoft Word” is pertinent to the ritual, they don’t know what it refers to, so transferring that insight would be a matter of guesswork.
You could just as easily show them the steps on the Start menu, it’s true- but then you have the separate question of saving the file somewhere and being able to find it again later. I know from helping elderly relatives with their computer problems that “directories” are another confusing concept for a lot of people. Pointing to the Desktop and saying “save it here” makes intuitive sense and makes the file easy to find later, but to e.g. “Save As” to the Desktop from inside Word requires an understanding of the occult dual nature of the Desktop-as-a-directory and the Desktop-on-the-screen, which is an insight reserved for enlightened wizards. Using the New menu lets the user restrict all their interactions with the file system to, at worst, Windows Explorer, which is a huge simplification!
(Example of where this is coming from; once when my father, a practicing medical doctor in his 70s, needed to e-sign a PDF on an unfamiliar computer I spent about half an hour trying to explain the concept of “close the document in this app and open it in this other (e-signing enabled) app.” I could about as well have been speaking Greek, or telling a Flatlander about flying.)
Real world comparisons don’t help you here - creating a new digital document from an existing document is a very simple four step process. Duplicate, open, select all, delete. If it were that easy in the real world, perhaps we would.
Especially for things like letterhead or forms. Who wants to go to a room filled with thousands of different forms, if they could just get a fresh and clean one with four simple gestures?
It seemed to me that the author was claiming that people copy existing documents on computers only because it's the only (or easiest) way they know of to create a new document of a given type, not because it is actually the easiest way to create a new document of a given type. It seemed to me that the author was decrying the fact that so many people copy existing documents and delete all the contents, and was providing that as justification for why the New menu exists.
Wow, I would never have thought of doing that to get to a new state. I can't think of the number of times that I have opened an existing document to make alt versions of, but forget to Save As before making those changes so my alt is the version. Hopefully undo buffer allows me to go back to start, Save As, redo back to where I was. Too many times.
I love/hate when I hear about the covoluted ways that users use a computer in the most illogical way that apparently makes perfect logical sense to them. It's like the Stupid Criminals bit on the Tonight Show. All you can think at first hearing is surely nobody is that dumb, but yet, here we are looking at someone being that dumb. One co-worker was often heard saying "I can't fix stupid"
Save As is particularly worthless in Windows since Windows goes out of its way to obfuscate the file system. It's far simpler to create a new file in a folder and start from there.
OSX does the same thing, too. I always have to go and turn the setting on just to see my home folder, not even to mention actually seeing file paths anywhere, or God forbid finding root in Finder.
macOS Finder defaults are pretty weird if you think about it. We've gotten used to its quirks but… why is the world isn't the desktop aligned to the grid by default? And why doesn't the grid automatically stretch to fit the screen like Windows does?
Another one is that there's no toolbar button to delete files since they expect you to drag them to the trash. Please I'm not dragging files for 1000px with a trackpad as an entry-level user.
macOS goes further, by not only hiding the path of folders but showing a lot of views that aren't folders. Clicking on "pictures" might very well show only picture files but from anywhere in your home folder and under. Also there are (were?) tags.
“lets you create the file directly where you want it, saving you the trouble of having to navigate through the Save As dialog just to get back to where you started.”
Yes - all the prior arguments seem to fall flat when this simple reason exists. I am frequently already in or near the directory where I want to create the file when I decide to create it. Or at the very least, navigating the filesystem is just easier in whatever tool I'm using than in the save dialogue.
something i wish was the norm would be a list of open folders that would show in the save-as window. a lot of times the folder i want to save to is already open on my desktop but if i open, say notepad, and save then it will start in the user folder and then i have to navigate to the open folder manually or copy and paste the address.
i think it was dreamweaver that had a target icon that you could drag from the save-as window onto a folder and it would change the location. even just a drop down menu would do as well though
I can't agree more. It's ok if the file picker has address bar like standard one, just paste it. It's very frustrating to manually navigate custom file picker without address bar to specific location.
> It’s like making a telephone call in the United States. You don’t think about which telecommunications company serves that number. You just dial the number and let the telephone network figure out which telecommunications company is responsible for that number.
I don't think this is a good comparison. I make a phone call by getting my phone out. I've memorised this, just as I've memorised opening Word to start writing a document.
The right-click option would be fine if it didn't take longer and longer to work, and the list were easier to customise. What the heck is it doing on every right click?
Classic Mac OS had OS-level support for document templates in the form of "Stationary Pads".
You could create a document to to use as a template, then in 'Get Info' (the equivalent of file properties in Explorer) you could check the 'Stationary Pad' checkbox.
Now the file is a template. When opened, the application behaves as if the user created a new document, and pasted in the contents of the template: in particular, the document would be 'Untitled Document' and Save would be unavailable, you'd have to use Save As to save the document to a new file, etc.
I think the file icon even changed to visually indicate its status as a stationary pad.visually.
The template feature being a property on a file means you can arrange your templates in folder structures which is handy if you have a lot, they can be on network shares for groups of users to use, etc. And, of course, it was easy for users to manage this themselves rather than relying on obscure registry keys...
Notepad is an app for viewing and editing text files, which contain characters. It lets you delete, change, and move/copy existing characters, and also add (type) new characters.
Explorer (like other file managers) is an app for viewing and editing folders, which contain files. So it makes sense that besides deleting, changing, and moving/copying existing files, it also lets you add (create) new files.
Maybe not literally true, but a nice mental model to entertain for a few moments’ entertainment! (It also suggests it should be possible to take this a lot further than Windows and Explorer do; does anyone know of any historical or current file managers that do a particularly good or interesting job here?)
I absolutely love this approach to feature inclusion and usability. User research showed that for some number of users (presumably not the majority) this is a familiar and comfortable interaction. All too often we see companies cut features (or whole products) because the metrics/analytics indicate most users don't use them - ignoring the fact that those features may be really important to the small minority.
I understand that every feature and product carries a maintenance burden, but I believe that the barrier to cutting them should be really high (especially when users build workflows around them).
Only slightly related, but I really like the touch command because it's a very good way to initialize files that is also visible in logs as a file-creation moment. I always run an init log next to my project, so that I can recreate all the files from scratch at a later date if I need to scrap stuff.
touch is good also because it stays in the history and can be recalled as a whole. Lately I've just started calling my editor on files I want to create and edit: code my/file.js (the editor will also create the required folders)
Better question: why in the hell doesn't Windows have a central settings menu for deciding what is and is not on the right click menu? Why do I have to search through the settings of fifty different programs if I want to clean it up?
IMO, this « New » paradigm worked best in the past (on Windows 9x) when Explorer was a simple and comprehensive abstraction around « Desktop / Folders / Files ».
Windows explorer evolved from a user friendly implementation of a simple abstraction to a complex file management tool with buttons and menus everywhere. Once you start installing programs, the context menu starts to be bloated and incomprehensible, the ribbon toolbars is full of useless buttons for the vast majority of end users, files organisation is a mess with virtual folders right from the fresh install …
« New > » was a nice and comprehensive feature I could explain to my grandmother two decades ago when this thing was just a window holding files. Now I wouldn’t even try to explain her how she could use that tool.
I have the strange feeling that, as things goes, personal computing is more and more complex.
It is a good approach but lacks presentation to users. Most users require "touch new.ext" and therefore complain about the lack of this item. I've added one template "New file" with no extendsion and not content, exactly what I need to get started. It is better than a hidden registry just for applications but could be improved with well designed default behavior for "empty files".
> Even Unix follows this pattern for process creation! To create a new process, you clone an existing one (fork) and then delete everything inside it (exec).
I always thought fork was one of the biggest design blunders in unix.
Oh if people care about their documents and not programs, then the sure dont care what company wrote the programs! Why is the start menu full of company names and not categories?
End user here. I spend many happy hours creating Word documents. When I use a menu, I tend to use New, and then use one of my templates. I like the way it works in that it shows the last templates I have used. I would prefer if it kept track of the templates I use the most and presented them in that order.
It would be really cool if it could read my mind and knew that on Saturday mornings I normally create two specific types of document.
One of the old versions of Mac operating system (System 7 or 8?) used to have templates on the desktop. I seem to remember I just double clicked on them and it created an empty document with a the selected template. I liked that a lot.
Eventually, I have just bound a function key in Word to creating two of the types of document I use most regularly.
I have been using Emacs with deft to write text notes for some time now. I like the idea of just pressing enter and having a new empty text document. I don't have to worry about the name or where to save it.
It would be fantastic if I did not have to think about where to file documents, create the folders and move them there, and the system magically created virtual folders with content it thought should go there.
Because you've already got the directory open, but might not know how you got there. Especially if your directories are a cluttered mess, like mine are, and you found the directory using the file search feature. And the "save" dialog is not completely standardized, e.g., not all programs start you out at the same place, and some force you to navigate all the way from root.
I'm pretty sure its about time that Windows guessed what I am trying to do when I am looking around inside a folder. Right-click, offer me the shortcut to create a file similar to what is already here.
They already have the obvious yet brilliant use of recent items in Outlook : compose reply, click attach file -> top of the list is that file I just edited and saved over in Word a few seconds ago.
> And who among us can say they never created a new class or project by copying an existing one, and then deleting everything inside?
Why would I do that? Sure, I've copied classes and whole repositories around, then deleted most of the meat but the reason for copying instead of starting fresh is because a lot of the boilerplate and directory structure can be reused.
I don't use Visual Studio but on VS Code it's pretty much the same as everywhere else:
Either:
* Cmd/Ctrl + N to open a new buffer, then Cmd/Ctrl + S to save it using th OS file picker; or
* Right-click on the file browser pane on the directory to create the file, select New File and give it a name.
I 100% forgot how I did it, but somewhere in the Visual Studio installation folders is one containing the empty project files for each type of project. I've replaced my blank 'Command Line' project template with one that already contains a lot of my favourite boilerplate code.
I don't use vim, but can't you just skip the first command? I would guess that the second command would work just fine. Presumably the only difference would be that the file wouldn't be created until you first save the file within vim.
> Presumably the only difference would be that the file wouldn't be created until you first save the file within vim.
And for me anyway, this is a benefit. When I used windows (and the same holds for google docs) I always had "New Folder"s everywhere that I'd created for whatever reason and then changed my mind or got distracted. Same with new documents. In vim, I do like to say, and it I change my mind and don't save it, I never see it again. If I touch'd it first, inevitably I'd have empty files everywhere.
What I find interesting about `vim /path/to/file` is that it is neither document-centric nor application-centric. Or in a way it is both: You need to know which application you want to use, but you select the location of the document before launching the application.
I wonder why this feels so natural in the terminal but so annoying in GUIs. I cannot remember any specific examples, but I think there are some GUI applications that require you to select a location before you start editing a new document (maybe some audio workstations?). I remember feeling annoyed by that.
Then again, the difference between "document-centric" and "application-centric" doesn't make a lot of sense in the context of the command line because 90% of files you work with are text files anyway. There is much less coupling between document types and applications than in the GUI world.
Maybe it takes into account if the user doesn't have write access to the folder? If the user didn't have access, the touch command would fail, whereas going directly to vim, it would only fail when trying to save (potentially losing the work done in the file)?
Depends a bit on your shell. That works great in bash. Other shells have different semantics. For example, zsh will wait for input until you type ^D or ^C and tcsh will complain about an invalid null command.
The variant I know that works identically in pretty much every shell I've ever tried is:
:>myfile.txt
And if you don't want to overwrite the file if it exists:
I've done a similar thing, but not with touch. I open the file in vim and then save it immediately. Keeps me from being sad if permissions are going to stop me after I've put some work creating the file content.
The only device this work flow seems to be natural in is Iphone (which is barely a computer). Nothing else works like that. So no, computers are not at all "app-centric". They are always file-centric.
I believe the "New" menu of the file manager is mostly used by newbies and that's great it is there for them. For more experienced people the usefulness of an option in this menu probably varies from type to type. Being able to create a plain text file at any given place makes a lot of sense even for advanced users (especially if displaying file name extensions is enabled, I actually believe making hiding them even an option, let alone the default is the worst decision of whole Windows UX design). Word/Excel documents also make sense. BMPs make notably less (today). Some types make zero sense to be there yet get there occasionally.
Historically they have always been just template files in a special directory. Perhaps this has changed recently, I don't really know about Windows 10.
I recall that back when I was still using Windows (which was sometime in the XP days) opening the New menu could result in quite a bit of a pause, if you had lots of programs installed. It was really enfuriating, as the pause could be on the order of a second or more. IIRC I only used the New menu for creating folders, and creating some nested folder structure became an exercise in frustration.
I never understood how this could take so long but it seems the list of possible new filetypes was dynamically generated everytime by querying a dB of installed programs. Maybe it was so slow to encourage people to not use the new menu?
I frequently use the right click -> new menu in Windows to create new text files in a given folder (the only thing I use it for). It would be exceptionally obnoxious if they removed that feature.
Microsoft .POT templates are so infuriating to use on OSX that almost every OSX user of Office I know has routinely ignored .POT and copies an integrally complete .PPT and strips out the slides.
the whole "apply template" idea is broken.
If I made an empty file via classic shell :> file.ppt and it was a valid powerpoint, I would be surprised. But for many systems, a valid empty instance can be passed around. I don't like 8.3 magic override "if its .txt its a text file" but I know it exists (eg for icon assignment in the GUI)
Such bikeshedding ^_^ clearly something everyone can have an opinion about, and every one of them (mine included) will be insuficciently informed to contribute any value.
I've used and found every possible way of creating new files useful, maybe except for copying and then emptying (except for some times when being a lazy programmer). Working in Windows95 explorer, the context menu from right-clicking seemed extremely reasonable, and I'd probably still use that if I worked on windows.
I would love if Microsoft replaced the contents of that menu from being Windows Registry entries to being contents in %USERPROFILE%\Templates. So one could not only easily manipulate those oneself if needed but also add actual templates to create, i.e. not only truly empty documents. The menu entries would share names with the file names.
Certain other operating systems/distros do it like this and I always found it a better idea than the current Windows way.
i use it as a way to generate template folder structures that are to contain files to be populated throughout their work. this shares with my team how I do my work, and supports them following my formula should they want to follow it themselves, which in experience shortcuts their onboarding time. I mean, I just touch files with extensions into existence rather than use a menu, but it's basically the same idea.
As a heavy Mac use I love this Windows feature so much I have installed a Finder extension that does just that.
It is so much better than opening an app, writing something and then deciding awkwardly where to put the file. Like, when you write something you don't usually scribble on a piece of paper and then glue it to your notebook.
That goes if I am using a GUI. touch, echo, cat, vim and >> redirection are my friends in the terminal.
I don't understand this article. Is Microsoft criticizing it's own UI decisions?
I had no idea Windows worked this way, it seems like such an odd way of working to me. As for 'hidden' applications, all of my applications are hidden on my Mac. I exclusively use spotlight or Alfred to open an app, I can't imagine working any other way with any semblance of productivity.
First you had applications and the file menu. Then you had folders and the file explorer with context menu for new.
But now you don't really care about file and folder structure since you have your documents in the cloud or use search on desktop, so the folders don't make sense either.
So you really mostly create new documents from some portal like thing, like google drive or sharepoint front page.
I never liked the new submenu in Windows and dislike when others copy it because it takes extra clicks. Typically the correct type for me is not even in there.
I’d rather have a menu item instead that simply makes new empty files, what I do 98% of the time. There could be a standard set of blanks according to extension, while obscure programs would need to handle zero byte files.
If only there was a shortcut to create a new file in Windows. New folder works, why not new file?
CTRL + N would be nice, as it would match the create new folder shortcut CTRL + SHIFT + N, but that is already in use by 'create new window'. WIN + N comes to mind, with a selection box highlighting the most commonly used New file (in my case, a txt file).
I think it's useful for creating empty text files. It saves you to have to navigate back to the folder in the text editor. What I don't understand is why you have to press shift to get "copy file path" in the same menu. Why should such a useful feature be hidden?
I usually enter the folder and click in the white area to the right of the 'folder breadcrumbs' bar. That transforms the 'folder breadcrumbs' into an (already selected) path. Ctrl+C and I have copied my file path.
I never knew there was a "copy file path" in the context menu until this topic.
> Not everybody knows that the way to create a new BMP file is to open this program called Paint that is hidden in the Accessories folder of your Start menu.
That's a valid point, these same users also get confused by having a right button and context menu.
I have always thought the fork() interface was convoluted, perhaps it is more intuitive to some folks than me; using a old document to create a new one by copying it, opening it, and deleting its contents is not something I had considered.
I wish save/select files depute the system file browser to do that, maybe even reuse recently open window. I was annoyed by 3 distinct file selector with their unique faults in a KDE distro.
Reading some comments I realised I might be one of the few who _never ever_ used that functionality. I see it’s benefits for some. But always wondered about the menu estate taken away from me…
I use the terminal and the touch command all the time to create empty files before adding them to a project (for example touch include/MyClass.h src/MyClass.cpp )
> Even Unix follows this pattern for process creation! To create a new process, you clone an existing one (fork) and then delete everything inside it (exec).
> For people with a document-centric view of the world, programs aren’t really things that you think about. What you really work on are documents.
As a Mac user long before a windows user, this is bizarre and I’ve always been frustrated that closing a windows document quits the program. It’s dumb.
> "closing a windows document quits the program. It’s dumb."
It's not necessarily true; Excel holds a parent window open when you close the last spreadsheet, Paint.Net does as well, VS Code goes to a 'front page' screen, Visual Studio does, Adobe Reader does, Audacity restarts a blank file if you File -> Close what you're working on.
It's not a "Windows" thing, it's a program choice what happens.
That isn't how windows apps work. Even if you believe its better, even if you are correct working different than other apps on the same platform is confusing.
What do you mean? That is how many (most?) Windows apps work:
* Before you start them, an icon for them is somewhere (possibly several somewheres) in your Start Menu. You can also (usually) start them from the actual .EXE file, which you can find with the file Explorer, or even from the command line. After you have started the app, it gets an icon on the task bar. (Let's disregard, for the purposes of this discussion, the option to set up a permanent icon on the taskbar, i.e. one that's present even before the app is running, to start it running from, for those of us who can't be bothered to use the Start Menu.)
* Now that the app is running, it gets an icon on the task bar. If you open several documents in the app, it usually gets several icons; one per document. Depending on which icon in the task bar you click, the app brings the corresponding document to the foreground of your screen. Start closing some documents, and the icons go away. In the end you're down to a single icon on the task bar again.
* Close the last open document, and some apps go fully away: No window on your screen, no icon on the task bar. Others, though, don't do that -- an "empty" window remains on-screen, and the lone icon on the task bar usually changes its caption from "document name" or "document name - app name" to just "app name". Minimize this window, and the icon on the task bar remains.
Ergo, when you close the last document, the app "lives" on the task bar. Q.E.D.
(Sure, not all apps, but so many of them I think it may be the majority nowadays. Certainly the most used ones: Microsoft Office, for instance, behaves this way.)
> Even if you believe its better,
I don't have much of an opinion; I was just answering a question by stating a fact.
> even if you are correct working different than other apps on the same platform is confusing.
A) But it's not "different than other apps"; this is how many / most apps work nowadays.
B) Microsoft has apparently been betting for a decade or two now that it won't be too confusing for a majority of their users, and they show no sign of being about to change it, so I'd guess haven't had too many complaints about it being confusing.
There is the question of whether in a multi document interface to show an empty window when the last document is closed and the question of whether to keep the application running when its last window closes on a single document interface as was the topic of the original discussion.
The majority of multiple document applications on windows choose to close their application when the last item is closed rather than displaying an empty window but all or virtually all choose to die when their last window or tray icon dies.
You said
> On the task bar.
No app on windows displays an indicator on the task bar for an application that has no windows. Doing so would be broken.
In a multi document window like this browser window there is a clear delineation between closing a document by clicking the x on the tabs interface and closing the window by clicking the x on the window. On a single document interface like say a document app as per the original discussion there is only one action in the evident interface the x on the window which ought to have a predictable result.
If one wanted instead reuse the window one would do File->Open or File->New or some such. One may also particularly use File->close on some such resulting in any empty window but this would be awfully odd given that the only way to reuse the window effectively would be to thereafter follow up with file->open or file->new.
The current behavior on windows of closing the window when the last document in a multiple document interface is closed and closing the app when the last window is closed is both standard and appropriate for the windows platform.
> > > Without a global menu where does the app live when the last document closes? [Again, my emphasis -- CRC]
The document-handling apps I have here on my work PC consist mainly of Microsoft Office 2016. Of those, at least Word, Excel, and PowerPoint all behave as I said: When you close the last document, the window reverts to an empty state, ready for you to open another or create a new document. AFAIK this is how they have behaved since Microsoft abandoned the MDI some decades ago, and still do in newer versions. I think (but am not sure) that this is also how other applications, like those in the LibreOffice suite, behave.
Sure, that window doesn't automagically minimize itself to the task bar, but at least I usually minimize it at that point -- don't you; who wants an empty window cluttering up their screen when they don't use it? Anyway, even if you don't minimize it, unless you immediately open or create another document, you presumably switch to another application, and then perhaps another and another, so after a while it's hidden behind other windows anyway -- all you see of it is its task bar icon.
So when you want to switch back to the app, unless you belong to the alt-tab faction, you click its task bar icon to bring it to the foreground again. Even I, who do belong to that (smallish and ever-shrinking, I think) group, often do that, because it's a visible and predictable place to find it. Ergo: When the last document closes, the application "lives" on the task bar.
> The current behavior on windows of closing the window when the last document in a multiple document interface is closed and closing the app when the last window is closed is both standard and appropriate for the windows platform.
On the first, I agree for modern "tabbed" windows; disagree if we're talking about the traditional Multiple Document Interface model ( https://en.wikipedia.org/wiki/Multiple-document_interface ). On the second, yes, of course, but I didn't know that was what we were talking about, because that wasn't what you said.
I think that really highlights the paradigm-shift that happened in UX in the last decade - what you could call "documents-centric" vs "application-centric".
Until recently, UI was centered around files. You used programs to edit and manage those files, but the programs didn't "own" the files: A file was generally independent of the programs that are used to open them. On the other side, a program does not "know" about a file until you explicitly prompt the program to open the file.
Compare that to the "application-centric" paradigm that dominates on the web, in mobile OSes and recently in desktop OSes as well: Here a program "owns" its data and you are supposed to interact with the data only through the program. It's an implementation detail how the data is physically stored - but from the user's PoV, there is no unified file system. Instead, the assets managed by each program are living in separate universes.