Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Good Tools Are Invisible

gingerbill.org

Post reply on HN
Print view View original

241–250 of 305 posts

Re: Good Tools Are Invisible

#241

Post by [deleted] »

order-matters wrote: post #131
mike_hock wrote: post #130

I completely agree that the author is right and the strawman is wrong. For example. The strawman criticizes GUI apps because he cannot navigate them with the keyboard alone. Keyboard-navigated TUIs are the worst type of UI. CLI > GUI > TUI. I don't like interactive tools because they're not scriptable. I don't care about keyboard vs mouse per se. I don't like having to use different tools for the same job depending o…

good luck editing a photo with CLI tools ( though im sure someone has developed something for this lol) to your point i think there is a lot of merit to having CLI-first development, where if it can be done in a CLI then do it in a CLI. if a GUI is to be built as an assistance tool, great, but let the actions map to commands that could be saved and re-run

[deleted]

Re: Good Tools Are Invisible

#242

Post by xlii »

aquariusDue wrote: post #226
xlii wrote: post #222

I agree with the premise of the article. For example I've been using Jujutsu exclusively (as a Git frontend) for years and I don't think about it, I just use it. I reflected on this couple of years. It's existence is completely transparent to me. I, however, don't agree with sibling commenter that it's a function of time spent with X though. As a counter example: Emacs was my go to editor for 15+ years, last 2 years…

As someone deeply invested in Emacs who had a short fling with Kakoune a few years ago I'm super curious how did you manage the transition? I have lots of notes in org-mode and rely on packages like Magit and so on, due to that I'm always wary of the fact that a lot of my computer use flows through Emacs (for better or worse). Also one thing that intrigues me about Kakoune is the possibility of writing CLI utils in w…

Obviously Kakoune is much simpler than Emacs, so face variability, very interactive UI is not there (though there'd be nothing preventing writing it, but I doubt anyone wants it enough).

As for transition - I always was somewhat of an UNIX guy, so I replaced Swiper/Occur/Consult with delegating to shell. Kakoune has just enough utilities to create a on-keystroke-updated-buffer so I'm happy with that. In some languages I go as much to create "find functions" special mode - composition with shell is easier than Lisp - I rarely have to read documentation.

For Git I use Jujutsu (so I stopped using Magit long time ago) but Kakoune has a very nice "!commmand" utilities. It's nothing more than a "C-u M-!", but positioning of feature differs.

So the transition is mainly about delegation, not sticking to one application, but instead finding utility that does it and use that instead.

Re: Good Tools Are Invisible

#243

Post by nixonaddiction »

i learned to code primarily from really old guys so i started on vim. i was forced to use vim because i was doing a lot of remote hpc work. now i like vim. use vim/tmux combo to improve my mouseless workflow. i just need a better way to look at all my files and pdfs without touching my mouse. i should try sublime as i cant have any real comparison between the two without having tried both. but i much prefer mouseless workflows.

Re: Good Tools Are Invisible

#245

Post by ventana »

fmbb wrote: post #231
pianopatrick wrote: post #183

Earlier quoted context omitted.

You should not underestimate how confusing those CLI tools are to people who have never used them before. For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp.

> For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp. I don't believe this. If you find a person (well, two I guess for this experiment) with no computer experience and want to teach them how to copy files, your first step will be teaching them what is a file and how they are organized in…

My mom struggled to understand the concept of copying and pasting when she got her first computer at home, with Windows. It was more than 20 years ago, but I think the idea that you need to copy in one place, then go to some other place and paste there, still sometimes confuses her in the context of files, even though she does not have any issues with that when copy-pasting texts.

Re: Good Tools Are Invisible

#246

Post by xarwex »

nixonaddiction wrote: post #243

i learned to code primarily from really old guys so i started on vim. i was forced to use vim because i was doing a lot of remote hpc work. now i like vim. use vim/tmux combo to improve my mouseless workflow. i just need a better way to look at all my files and pdfs without touching my mouse. i should try sublime as i cant have any real comparison between the two without having tried both. but i much prefer mouseless…

Take a look at yazi https://yazi-rs.github.io/, I find it pretty good for looking at my files.

Re: Good Tools Are Invisible

#247

Post by wccrawford »

overgard wrote: post #128
ventana wrote: post #11

As a long time terminal user, it does not surprise me much when people just don't get it . The discussion often goes like this: — In a terminal, I can do so-and-so with a simple command — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that)…

I don't think your logic is off, but I also think that the FrobnosticatorStudio people have a point. The thing is, yes, the terminal gives you infinitely more capabilities but you probably have like, 20 actual things you do regularly? The learning curve makes it a hard sell when those 20 things are probably all you need. Like, sometimes I'll do something like this if I'm in a terminal and I want to find a build scrip…

I have used and use both regularly. The IDE makes the normal stuff really fast, but the CLI enables things that just can't be done in the IDE. I quite often ended up being the guy that dealt with things quickly, especially in an emergency. I just had the tools to get things done quickly, even when I hadn't been in that situation before. And I say that without even being good at awk and sed, which are used a lot by others in those situations. I always meant to get good at them, but never did. I ended up using other simpler tools instead to get the same kinds of things done.

In short, knowing the CLI way is absolutely useful, even if you use the IDE for 95% of stuff. And I also don't recommend going full CLI, because the IDE way is faster for that 95%.

Most things in life are about balance, and that's true here, too.

Re: Good Tools Are Invisible

#248

Post by spudlyo »

iLemming wrote: post #206
ventana wrote: post #11

As a long time terminal user, it does not surprise me much when people just don't get it . The discussion often goes like this: — In a terminal, I can do so-and-so with a simple command — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that)…

Most programmers come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, terminal, in PDFs, Word or LaTeX documents. Code is just structured text.…

> Anyway, this should be a little more of a deeper discussion than a forum comment.

You should turn this into a post of its own, it's probably the most insightful thing I've taken away from this entire conversation.

Re: Good Tools Are Invisible

#249

Post by jodrellblank »

dtj1123 wrote: post #114

I like TUIs because I can pipe the output of CLIs directly into them, and I don't have to leave my terminal environment. GUIs can't compete with that.

    ls | gvim -
or in PowerShell

    gci | ogv -PassThru
Programs which call GUI library functions can read stdin too... why wouldn't they be able to?

Re: Good Tools Are Invisible

#250

Post by ablob »

jodrellblank wrote: post #187
ablob wrote: post #60

Earlier quoted context omitted.

Most knowledge about human computer interfaces was obtained through metrics. Groupings, menu bars, corner buttons, context menu orderings, and other things didn't just spawn into existence. There was a time where human pattern recognition and physiology was an active consideration for user interfaces. One of the reasons mouse input became popular is precisely because interfaces were created to be easy to use with it.…

> " I'd wager that if actually tested, " https://danluu.com/keyboard-v-mouse/ - """The widely cited studies on mouse vs. keyboard efficiency are completely bogus ... When I look at various tasks myself, the results are mixed, and they’re mixed in the way that most programmers I polled predicted. This result is so boring that it would barely be worth mentioning if not for the large groups of people who believe that ei…

Sigh, I don't know why a blog-post against micro benchmarks should alter my opinion on this topic. There are more metrics than just "speed" regarding an interface. You also want it to be discoverable and visually distinct.

How someone interacts with your software is absolutely measurable and the results will vary by how a user is likely to use it in frequency and variety of function. Someone that needs to do something specific with your software every day will interact with it quite differently than someone that just hops onto it every now and then to do a different task each time.

All of this requires actual studies and observation of users over time. Micro benchmarks have no space there. Testing how fast a find and replace is is meaningless. In case of software for writing text you'd test a user actually writing prose, changing font sizes, title colors, and maybe replace a word over the file too. You would have commonly used functions mixed in with less commonly used functions over how the software is used under a specific use case. (For example, writing text, revising text, and polishing a graph representation are different use cases)

This is not easy, which probably why it's not done all too often, but it is also most definitely unlike a micro benchmark (which your link argues against).

All that being said, I don't know of any person strictly pitting mouse against keyboard when testing UI for possible improvements.

Post reply on HN