> However, since MarkItDown is a Python program, it might be challenging for non-technical users to use.
Am I alone in thinking it is perfectly acceptable to ask a non-technical user to open a command line and type something? It's not rocket science. You just follow simple directions. Click start, search for powershell, type this into the Window that pops up, hit enter. [0] If you can make boxed mac and cheese, you can type a command into a command prompt.
It was not that long ago that even for Windows software you were expected to occasionally visit the DOS prompt (type d:\, type setup.exe was a pretty common pattern in instruction manuals).
[0] Of course, the directions currently on the MarkItDown github page are pretty inadequate, but I'm talking about the general case.
*> Am I alone in thinking it is perfectly acceptable to ask a non-technical user to open a command line and type something?*
You're not alone, but that doesn't make it right; rather it puts you in the large bucket of developers that have no idea of:
1) how and why common non-technical people use computers, and
2) why asking them to perform actions they don't understand is a terrible idea both in terms of usability (because the process is difficult, intimidating and error prone) and security (because you're training them to follow instructions that can easily put their system in risk when requested by a malicious actor).
If the actions to follow are really that simple, they should be automated in full; there's no reason why you would show the users anything more complex that a start button to trigger a script, and a confirmation dialog explaining the risks (and maybe requesting elevated permissions).
But if the process is not so simple that it can be automated behind a single button, then why on heaven would you expose them to an interface that requires a complex interaction (copy/paste various large texts from a web page), shows cryptic messages as feedback, and gives no clue on what to do next if any step has errors?
> asking them to perform actions they don't understand is a terrible idea both in terms of usability (because the process is difficult, intimidating and error prone) and security (because you're training them to follow instructions that can easily put their system in risk when requested by a malicious actor).
I think you greatly overestimate the understanding of nontechnical users. Why is
1) double click icon -> click here -> click there -> type in box -> click ok
usable and secure but
2) open powershell -> type command -> hit enter
not? My suspicion is a surprisingly large fraction of nontechnical users have limited understanding of what they're doing and just blindly follow instructions. What does it matter if they are doing that with a mouse or with a keyboard?
> If the actions to follow are really that simple, they should be automated in full; there's no reason why you would show the users anything more complex that a start button to trigger a script, and a confirmation dialog explaining the risks (and maybe requesting elevated permissions).
I completely agree.
> But if the process is not so simple that it can be automated behind a single button, then why on heaven would you expose them to an interface that requires a complex interaction (copy/paste various large texts from a web page), shows cryptic messages as feedback, and gives no clue on what to do next if any step has errors?
What, like this doesn't happen with GUI applications? Those problems have absolutely nothing to do whether an interface is graphical or not and have everything to do with bad usability in general.
> What does it matter if they are doing that with a mouse or with a keyboard?
It happens to matter a lot, in large part by a cognitive principle that most programmers should know, but very few do: recognition vs recall.
Text prompts in general are much harder to use because the user needs to remember the name of the command they need to type, which is a cognitive task way more difficult that recognizing the shape of a UI control with a recognizable command name on it.
> What, like this doesn't happen with GUI applications?
You're right that GUIs are not immune to terrible design, I still remember when open source developers but UIs for their software that were mere a front-end layout of the command line, and you needed to understand in full the inner workings of the app to use the UI.
However nowadays anyone who builds GUIs for a living has been trained in the principles of usability and has some knowledge of mental models and putting user needs upfront, so that style is avoided by everybody but the most isolated do-it-yourself programmers.
> Am I alone in thinking it is perfectly acceptable to ask a non-technical user to open a command line and type something?
I think it is perfectly acceptable t ask, but know that many will balk at the suggestion. It is a reason lot of people give for avoiding Linux, even though for many users CLI interaction need not be any more common there than under Windows these days.
There is flip side to this though: we perhaps shouldn't train users to blindly run commands and code, given how easy to exploit such trust can be.
Also, after running your “command line magic” there are too many out there that will blame you for anything that goes wrong with their PC for the next six months!
In this case, the problem is more the prereqs. The user must first install Python and some packages, which already brings up the question of which version and which package manager.
And in easier cases, if it's so easy, why not package it in a regular app/exe?
It used to be actually easy to run Python — and Perl, REXX, Tcl, Ruby, and a bunch of other languages — with WSH in MSIE. Those were, in that small way, good times.
> Many packages with C extensions have also been ported for use with Pyodide. These include common packages like regex, PyYAML, lxml, and scientific Python packages including NumPy, pandas, SciPy, Matplotlib, and scikit-learn
We evaluated the pyodide ecosystem for louie.ai last year and too much didn't work, eg, we couldn't get data in for arrow or parquet, which are table stakes for python data work
https://simonwillison.net/2024/Dec/10/chatgpt-canvas/#canvas...