[pxc]

> except, it IS easy to learn actually. it's visual, you can click around and find out.

That's not easy at all. I am an actual Excel 2007+ virgin. I switched to OpenOffice (there was no Libreoffice yet; Oracle had not yet bought Sun) before high school. Before I finished university, I abandoned all traditional office tools in favor of open-source tools that use entirely different paradigms from Microsoft Office, e.g., Word -> Lyx/LaTeX, PowerPoint -> Org-beamer, Excel -> R. I didn't even use traditional Office tools when they were 'required' by class, instead explaining my commitments to the instructors and teaching myself the open-source alternatives as I went.

For the first ~5 years of my career, I was at startups where I didn't need to use Microsoft Office or even tools in that category.

So within the past year, I started dabbling in Excel for my job, when the last version of Excel I even messed around with was Excel 2003, pre-ribbon menu, in junior high.

And as a developer who is approaching contemporary Excel from a position that is actually pretty close to a blank slate in terms of experience with it... I am here to tell you that this

> [Excel] IS easy to learn actually

is false. You are almost certainly discounting experience people have gradually acquired with Excel in school and over the course of a career. This isn't just evident with oddball developers like me who wanted to and managed to avoid Excel for most of our careers so far. It's also perfectly evident in baby boomers who grew up without Excel and need assistance for basic tasks, and increasingly in zoomers who, like those two generations before them and earlier, have grown up without being trained on office software in schools.

Which takes us back to GP's statement:

> > Excel is powerful, but it’s not easy to learn. It only seems that way to people who already know how it works.

Moreover, these statements

> if you forget the spelling of some formula, no probs, there is a help button.

> people dont want to read manuals or consult documentation

contradict each other. So do the following two, in a slightly less direct way.

> it's visual, you can click around and find out

> they want to hit the ground running

Pressing the help button is reading the documentation, just as much as running `q --help` or whatever.

And anybody who is visually exploring a GUI with as many buttons and menus as Excel's is absolutely crawling, not running. Visually scanning an overloaded, totally new-to-you graphical interface is slow, slow, slow.

When I've been driving Excel on video calls with colleagues during working sessions (specifically for the purpose of learning it), I can practically hear the veins on their foreheads bulging as I fumble around.

Searching with your eyes, especially when some options are hidden behind additional clicks as they are on ribbon menus, is so unbelievably slow compared to searching through a comprehensive manual by typing a couple of words.

[feoren]

Complicated tools are hard to learn. There's no general fix to this. The only way to make complicated tools easier to learn is to watch a bunch of different people try to learn them and tweak little details based on what you see. In Excel 2003, Microsoft had 20 years of doing this. When they moved to the "ribbon" in 2007, they threw a lot of that learning away. So you're right that the ribbon makes Excel harder to learn than it needs to be.

But I reject the idea that visual GUIs are inherently more difficult to learn than non-visual interfaces; everything we've ever seen in the history of software suggests the opposite.

> Searching with your eyes, especially when some options are hidden behind additional clicks as they are on ribbon menus, is so unbelievably slow compared to searching through a comprehensive manual by typing a couple of words

Typing which words!? You're already assuming the user has a pretty strong understanding of the software if they know which words to search for. This is not a fair comparison with opening a brand new GUI for the first time.

Think of the difference between walking into a restaurant and having the waiter hand you a big menu with lots of pictures, vs. standing there and asking "What do you want?" ... um, I don't know, what do you have!? The latter is how it feels for new users to be presented with "> _".

[pxc]

> Think of the difference between walking into a restaurant and having the waiter hand you a big menu with lots of pictures.

The useful part of the menu is the text! Especially if I'm somewhere with novel or unfamiliar food, there's no way I can guess what actually went into a cooked dish or what its texture is like by looking at pictures of it. But all of that I can infer from a reasonable description of the dish given in terms of its ingredients and how it is cooked.

But if the waiter asks 'what do you want', that is indeed an offer for them to search on my behalf much more efficiently than I could do visually through a menu! I'm free to say 'something savory and salty' and see what they offer me, or ask 'what chicken dishes do you have?', or 'I need something light, because I'm not very hungry'.

Even in the example you chose, visually scanning a menu is less efficient and more restrictive!

> how it feels for new users to be presented with "> _".

Of course a shell prompt is not self-explanatory, because you have to learn the commands for asking about other commands.

But there's also no reason that accessing the command line for the very first time has to mean being dropped at a blank prompt with no instructions. That's completely inessential to the paradigm, and it's unfortunate that this is such a common default.

> Typing which words!? You're already assuming the user has a pretty strong understanding of the software if they know which words to search for. This is not a fair comparison with opening a brand new GUI for the first time.

Sure it is. I do this with commands I've never used or use very rarely all the time. In the worst case you try a few synonyms and words for related concepts and find what you're looking that way.

You're also not making a 1:1 comparison here. One may need some basic instruction on the command line environment itself, e.g., how to search for and open documentation at the command line. But that is not part of the process of learning to use a new command line application. You're comparing the cost of learning a single application to the cost of learning an entire paradigm and environment.

> But I reject the idea that visual GUIs are inherently more difficult to learn than non-visual interfaces; everything we've ever seen in the history of software suggests the opposite.

What volume of research has ever even investigated command line usability and how it can be improved? Where has that research been applied? How much of it focuses on applications/domains which are comparable in complexity to an absolute behemoth like Excel?

Consider the part of this discussion that has focused on developers who are hesitant to use the command line. Is there seriously any reason that a text-driven environment navigated non-spatially, through search/filtering, should be any harder to use than an IDE, like those same developers use every day?

----

I also wanna be clear that I'm not saying that Excel's non-obviousness is a fatal flaw, or that people who are effective with it should switch to something else. Excel is actually an impressive, capable piece of software.

I'm also not saying that most command line environments as they exist do a good job of being easy to jump into. They generally don't! I think the command line has long been largely neglected in terms of UX, and it shows.

But the way CLI environments lend themselves to searching, filtering, composition, and reusing old actions but slightly modifying them also make searching for, picking up, and using new command line programs really smooth and fast in a way that I think most of us don't give enough credit.