Literally everything I write is in Markdown because it’s so simple to me. I use it for blogposts, presentations, documentation, todos, internet comments.
But this article doesn’t strike a chord with me. The author fails to understand that it seems easy to us because we’re familiar with it. Of course we know how to transform it into PDF or HTML. But this knowledge isn’t basic, and it’s understandable that people want to stick to what they know.
Here’s an example. Say you had 10000 rows of CSV to slice and dice and extract insights and visualisations out of. All of us would go to the tools we’re familiar with - pandas, R, duckDB etc. But I think the median Excel user probably completes this task quicker and better than the median pandas user. And then if the pandas person is told “oh, just pick up Excel, it’s easy to learn and so useful” they won’t listen. And for good reason! Excel is powerful, but it’s not easy to learn. It only seems that way to people who already know how it works.
Don’t confuse the familiar with easy. Just because it’s easy for you doesn’t mean it’s objectively easy.
> Excel is powerful, but it’s not easy to learn. It only seems that way to people who already know how it works.
this right there.
except, it IS easy to learn actually. it's visual, you can click around and find out. if you forget the spelling of some formula, no probs, there is a help button.
the interface is what makes it easier, markdown is also an interface. except it's not AS exposed to the user as excel is.
people dont want to read manuals or consult documentation, they want to hit the ground running.
• Excel is based on a simpler model of computation, something like the unification ideas in logic programming, state is not named and minimally expressive, etc. You want a looping construct? Better autofill a column or something!
• Excel automatically includes printf-style debugging of every object in the system; that is the default state of the system and you have to hide columns you don't want to see.
• Excel has no compilation or run step. The document is living and when you change things you immediately see the results of that change.
This means that the programming model in Excel becomes much more amenable to the results-oriented mind. Decide on an incremental goal, then calculate a bunch of results “the long way” and then massage the formula until it gives a result that matches your manual calculations. Repeat as desired.
It's like clay, basically. You sculpt it to look right and then you sculpt the next piece to build on that and so on.
One additional point: since Excel packages the code with the data, when somebody sends me a spreadsheet with functionality I've never seen before it's extremely easy to figure out what they did and learn on the job. This is also why Jupyter notebooks are so powerful.
If instead of Excel they run a bunch of scripts and just send me the output, I am left much less empowered.
> when somebody sends me a spreadsheet with functionality I've never seen before it's extremely easy to figure out what they did a
You must have encountered only very simple spreadsheets. I've had to reverse engineer a number of technical spreadsheets that took days of full time sweated effort to merely understand the principles and more days again to extract the methods accurately enough so that they could be reimplemented in a programming language.
Think about how much harder it would be if you couldn't see the inputs, code, and outputs all together at once. The difficulty you found has little to do with Excel; you were trying to learn a whole new domain by reverse-engineering a model created by an SME. Of course it took multiple days of effort to merely(!?) "understand the principles" of a brand new technical domain. Ideally the SME should be explaining those things to you as well.
> The difficulty you found has little to do with Excel;
i claim, if you allowed access to an underlying source code representation of the spreadsheet, or rather, if you made that transformation at all, you could easily add symbols and labels to transform an excel sheet into something a programmer could turn into a binary but i doubt that step inbetween is desired
I mean, the activity of analyzing an excel spreadsheet is more akin to learning where all the items in your favourite point and click adventure is and in what order to get them where, than to actually analyzing a problem
When you've done that, is it all of a sudden super-simple? You've had to incorporate all the same complexity into your model. If you sent it back to a spreadsheet user, don't you think they would say the same thing, just backwards?: "I had to reverse engineer a number of technical data processes in R that took days merely to understand the principles..."
Perhaps not super simple but it will have been broken down into named parts. In the days before spreadsheets were as capable as they are now I worked with plenty of quite old engineers who would write Fortran instead; their Fortran was always better than the spreadsheets that they later produced.
The degree something is well-designed and comprehensible is based mostly on the developer, not the tool. A spreadsheet with named ranges/tables, cell comments (sparsely, where necessary), clearly-defined tabs, etc can make debugging or reverse-engineering a breeze. The visual aspect of Excel can also help debugging immensely, i.e. conditional formatting of cells failing validation, filtering to isolate subsets of data, etc.
I will certainly agree that it is quite rare to come across a spreadsheet that is perfectly-organized, on the other hand a ton of developers write horrible spaghetti-code too. Further, a 10+ year-old spreadsheet will open right up in Excel... while a 10+ year-old data project is often written in a language you've never used before (or hoped you'd never use again).
That pt 3 is actually something I really like in Office. It isn't just instant, you can see changes live as you mouse over different options. I also really like the search tool that lets you just type what feature you are looking for. I have no idea where the 'new pivot table' button is and I don't care, I can just search it instead of hunting through menus.
> 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.
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 "> _".
> 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.
Yeah, that's the flip side of a simple tool that makes it easy to solve problems. It's not clear when "simple" stops working or how to recover from it. On the other hand, the bespoke software approach can have bugs too.
I agree bespoke software could have bugs, of course, but this bug seems unique to excel. I would say excel is a tool that makes it easy to solve _easy_ problems.
I do not think Excel is simple. IMO it is less intimidating to users because it is graphical and does not look like programming.
> It's not clear when "simple" stops working or how to recover from it.
Excel row limit could clearly fail in a non-silent way, and it would be a better tool. They chose "simplicity" by ignoring errors.
There are a lot of times where a low-level understanding of Computer Stuff lets me easily get problems in simple stuff. Like if I see a year that's 1969 or a number that's in the negatives and around 4 million, I know some kind of overflow happened and can work from there to diagnose the problem. I don't know the right balance, though. I know all this stuff because you just had to if you wanted to do anything with a computer beyond simple office tasks.
Even advanced stuff has nice interfaces these days. My new laptop with a dGPU comes with software that has an overclock toggle and some guidance on how to get the most out of it, warnings, etc. That's a long way from editing files to make HIMEM.SYS work so Wing Commander would run.
I was a tech lead on one of the testing analytics data platforms by one of the "commercial firms" mentioned in the article, and I used to plead with/yell at/cajole various groups of people to not ship uncompressed CSVs around by email/FTP :(
Indeed. I'm a programmer, and if i have a 30 by 30 table of numbers with colon headers coming produced by an app or a script, my first reaction is to select, copy, paste it in excel, press search in excel and type 'text to columns'. Next step is search for 'chart'. In between I can experiment with just a few mouse clicks with different chart types, draw a trend line, add a caption,...
Of course when this needs automation, further steps need to be taking using a script in combination with pandas or the like, but only after a quick assessment using excel.
I wouldn't say that Excel is harder to learn. I was thought the basics of it in primary school. I don't think Panadas could be thought at the same level, you need to know Python first and that is a mountain, even if there are much higher mountains.
With Excel you mostly need to know about cell addressing, =, dragging corner of selection, $, ranges and some basic formulas (that currently are much easier to explore than when I was first approaching the subject). That is, I think, around 80% of Excel as it is used, maybe even more.
Right I’m speaking about slightly advanced Excel. Everyone knows how to sum/average columns or apply basic formulae. But creating pivot tables and using macros isn’t self-evident or easy to figure out by clicking around.
This may be true in a general sense, but probably not when you talk about the programmer picking up Excel. I often find I can use it for more things than people that spend their whole lives in excel simply because I have a reasonable mental model of what it should be able to do.
That said, I want to talk to whoever made the abomination that is VLOOKUP and ask them why.
Also don't confuse "easy" and "simple". "Easy" is subjective and related to familiarity, while "simple" is a more objective concept. Eg. Markdown is objectively simpler than MS Word.
Learning to sew was a never ending sequence of small steps that required lots of looking up to actually grok.
Thread the bobbin then put it in the bobbin holder, then swap in a denim needle, thread the needle from your main spool, switch to a straight stitch with a wide length, and adjust your tension disks appropriately while practicing on a sample patch. Place your main garment in, do a backstitch, and sew your lines.
All of this is super simple, but if you're just getting started, each step requires a manual (and it even glosses over a few really important parts like making sure to put your presser foot up or down while sewing).
> Literally everything I write is in Markdown because it’s so simple to me.
I'm inclined to agree, for the display of some text, it's one of the better choices that I've encountered!
I actually recall working on a system where HTML instead of Markdown was chosen for the storage and display of user messages (think along the lines of a chat/e-mail app), which came with a plethora of complexity and problems - everything from various editors across apps formatting things differently (sometimes breaking WYSIWYG), to the formatting in the database becoming inconsistent as the apps and libraries are updated but old messages weren't affected, any sort of manual parsing and migrating this data being difficult, as well as sanitization concerns and security challenges.
The Markdown suggestion of mine was shot down, but as far as I know there was just problem after problem with using HTML before I took a break from that org and took a bit of a sabbatical. Then again, migrating between different formats like Markdown and HTML is needlessly complicated if you have pre-existing data, so it's better to make the "correct" choice on day 1.
But this article doesn’t strike a chord with me. The author fails to understand that it seems easy to us because we’re familiar with it. Of course we know how to transform it into PDF or HTML. But this knowledge isn’t basic, and it’s understandable that people want to stick to what they know.
Here’s an example. Say you had 10000 rows of CSV to slice and dice and extract insights and visualisations out of. All of us would go to the tools we’re familiar with - pandas, R, duckDB etc. But I think the median Excel user probably completes this task quicker and better than the median pandas user. And then if the pandas person is told “oh, just pick up Excel, it’s easy to learn and so useful” they won’t listen. And for good reason! Excel is powerful, but it’s not easy to learn. It only seems that way to people who already know how it works.
Don’t confuse the familiar with easy. Just because it’s easy for you doesn’t mean it’s objectively easy.