Conversation

Notices

1. Embed this notice
   Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Friday, 13-Sep-2024 00:17:01 JST Dr. Quadragon ❌

   I think, part of the reason why The Dreaded Terminal is still so prevailant in the perception of Linux is that it's just SO MUCH easier to write manuals for.

   I mean, it's way more efficient to say: "run `apt install firefox` to install firefox" than "to install firefox, open the software center [screenshot], search for firefox [screenshot]", select firefox in the application list [screenshot], click install [screenshot]".

   The results are the same. Why waste more time drawing a comic book when you can tell a person to just type one line in a box?

   • clacke likes this.
   • Embed this notice
     Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Friday, 13-Sep-2024 05:31:02 JST Dr. Quadragon ❌

     in reply to

     • D:\side\

     @dside Uh... You seem to be under impression that I'm assigning some vauation to either CLI or GUI themselves, like "this good, this bad", or smth. This is not the case.

     What I'm saying, is, if I'm ever to write some guides or something in that vein, given the choice, I'd probably prefer to throw together some commands to making screenshots and describing mouseclicks. Because I'm lazy, and it'll work. So that's what happens more often. And this affects the perception of the platform as a whole.

     I'm also not saying that it's good or bad. Just that it happens.

     clacke likes this.
   • Embed this notice
     D:\side\ (dside@mastodon.ml)'s status on Friday, 13-Sep-2024 05:31:03 JST D:\side\

     in reply to

     @drq no we didn't.

     If you want to help the user get shit done give them a script[1] without explaining the steps in it whatsoever. That's how `curl $URL | sudo sh` installation methods have become the norm.

     But it goes deeper.

     When you don't teach a person the components involved in whatever it is you're telling them to do you're normalizing the attitude "I have no idea what I'm doin' but ok", condemning them to nasty troubleshooting sessions when the guide becomes out of date. And it will, it's a matter of time.

     And I hear what you're saying, you don't want users reading documentation and learning every single variation of every component involved because the information they *need* is buried in the middle of waves of extraneous stuff they have no use for.

     Because apparently there are no points on the documentation spectrum in between "an arcane spell" and "a hefty spell tome you have to read fully". What happened to "sensible defaults"?

     [1]: https://garden.dside.ru/put-the-info-where-you-need-it#the-right-format

   • Embed this notice
     Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Friday, 13-Sep-2024 05:31:05 JST Dr. Quadragon ❌

     in reply to

     • D:\side\

     @dside Yes, I agree about forcing people to learn discouraging the adoption of, but all of this is actually beside the point, and we digressed.

     Most of the guides ain't really about learning, they're about getting shit done. You need something done, find a guide, you follow instructions, and never look at it again.

   • Embed this notice
     D:\side\ (dside@mastodon.ml)'s status on Friday, 13-Sep-2024 05:31:06 JST D:\side\

     in reply to

     @drq yes, hotkeys. It's like command line crystallized around hotkeys.

     Hotkeys are *shortcuts*. You still gotta have discoverable (and shareable!) longer routes to make software easy to pick up, and right now they all go through documentation. Every concept you're forcing a user to learn *discourages* them. There might be "gentle encouragement" externally, like one's paycheck contingent on doing whatever the guide is about, but curious strangers are lost right there.

     Command palettes have existed since at least 2013 (probably even longer, it's the year of the first release of Sublime Text 2 that had this feature). They are keyed by human-readable explanations and advertise shortcuts right there in search results. Auto completion with documentation in annotations is close, but can we perhaps normalize making shareable forms of commands serve as their own documentation, with longer-form flags and command names? With the way CLIs designed right now it's actually impossible!

   • Embed this notice
     Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Friday, 13-Sep-2024 05:31:07 JST Dr. Quadragon ❌

     in reply to

     • D:\side\

     @dside Yeah. That fucking Perl one-liner.

     Also, yes, those VT-100 conventions clashing with desktop conventions are also disorienting as hell if you don't know what's going on.

     As for command naming... Well, keyboard shortcuts can also be counterintuinive, the advantage however is that you need to learn them once. But yeah, Pacman sucks for this.

   • Embed this notice
     D:\side\ (dside@mastodon.ml)'s status on Friday, 13-Sep-2024 05:31:08 JST D:\side\

     in reply to

     @drq one reason I can think of is newcomers being *scared* of said box, after being conditioned by numerous jokes (some of them pretty cruel) about the destructive commands.

     And command naming doesn't help, making most commands look like arcane language of random letters mashed together (Pacman being probably the worst offenders among package managers in particular) and not even readable *aliases* available by default. It's ergonomic for day-to-day manual use to someone already familiar with it all, but approachability suffers as a result.

     And don't get me started on VT-100 still holding on to dear life of ruining the consistency of textual inputs between itself and the rest of GUIs. Like, copying actually *interrupts* ongoing work? Right-click is *paste*? «Dafuq?»