Here's a thought that has been rattling around in my head for the last 10 years or so.

My first word processor was WordStar, but I never got to use it fully. After all, what use does a 10 year old have for a word processor in 1994?

I then moved on to MicroCom's PC-Flow for several reasons. First and foremost, it was already installed on my PC. Either that or I pirated it early enough not to make a difference - in either case, it had the major advantage of already being there. Second, it was "graphical" - it may have been a program for flow charts, but that didn't stop me from writing some awful early attempts at writing music that are now lost to the sands of time and 5.25 floppy disks. And third, because it printed - not all of my programs played nice with my printer, but this one did. The end result being that I wrote plenty of silly texts using a program designed for flow charts.

The late 90s were a tumultuous time for my computer skills. At home I had both MS Office '97 and my all-time-favorite Ami Pro, while in high school I had to use a copy of Microsoft Works that was already old at the time. The aughts brought Linux and StarOffice, which would eventually morph into OpenOffice and LibreOffice. Shortly afterwards I also learned LaTeX, making me care about fonts and citations to a degree that I would never have imagined.

And finally, the '10s brought Google Docs and MS Office 365. But the least said about them, the better.

The point of this incomplete stroll through memory lane is to point out the following: if there's a way to mark a text as bold in a document, I've done it. Cryptic command? Check. Button in a status bar that changes places across versions? Check. Textual markers that a pre-processor will remove before generating the final file? Check. Nothing? Also check. If you ever need to figure out how some piece of software expects you to mark something in bold, I'm your man.

And precisely because this function kept jumping around and changing shape throughout my entire life, I have developed a mental model that differentiates between the objective and the way to get there. If I have a reasonable belief that a piece of software can generate bold text, I'll poke around until I find the magic incantation that achieves this objective. But my story is not everybody's story. Most regular people I know learned how to make bold text exactly once, and then they stuck to that one piece of software for as long as possible. For them, text being bold and that one single button in that one single place are indistinguishable, and if you move the button around they'll suddenly panic because someone has moved their cheese.

I have long wondered what's the long-term effect of this "quirk" in our education system. And forecasts are not looking good: according to The Verge, students nowadays are having trouble even understanding what a file is. Instead of teaching people to understand the relation between presentation and content, we have been abstracting the underlying system to the point of incomprehension. The fact that Windows 10 makes it so damn hard to select a folder makes me fear that this might be deliberate - I'm not one to think of shady men ruining entire generations in the name of profit, but it's hard to find a better explanation for this specific case.

Based on my experience learning Assembly, pointers, and debugging, I believe that the best cure to this specific disease is a top-down approach¹ with pen and paper. If I were to teach an "Introduction to computers" class, I would split it in two stages: First, my students would write their intended content down, using their own hands on actual paper. They would then use highlighters to identify headers, text that should be emphasized, sections, and so on. At this stage we would only talk about content while completely ignoring presentation, in order to emphasize that...

• ... yes, you might end up using bold text both to emphasize a word and for sub-sub headers, but they mean different things.
• ... once you know what the affordances of a word processor are, all you need to figure out is where the interface has hidden them.

We would then move on to the practical part, using a word processor they have never seen. We would use this interface so the students get a rough idea of what the interface looks like in real life. And finally, my students would then go home and practice with whatever version of MS Office it's installed in their computer. If at least one of them tries to align text with multiple spaces only to feel dirty and re-do it the right way, I will consider my class a success.

Would this work? Pedagogically, I think it would. But I am painfully aware that my students would hate it. And good luck selling a computer course that doesn't interact with a computer. It occurs to me that perhaps it could be done in an interactive program, one that "unlocks" interface perks as you learn them. If I'm ever unemployed and with enough time in my hands, I'll give it a try and let you know.

Footnotes

[1] A top-down approach would be learning the concepts first and the implementation details later. Its counterpart would be bottom-up, in which you first learn how to do something and later on you learn what you did that for. Bottom-up gets your hands dirty earlier, similar to Mr. Miyagi's teaching style, while top-down keeps you from developing bad habits.