TL;DR UI design is teh hard
Apps that are all gradiated and fiddly and zoomy and jittery and thinks my palm means that I want to zoom and scroll, that freaks me the heck out.
Lots of software has this bad; someone on the Orange Site was complaining that copying text off some web page was difficult; practically every character had a link or some other means of defeating the copy. You wanted a minefield of popups, right? Or here's a space boat game that helpfully scrolls the list such that the highlighted item is no longer readable, forcing one to scroll the list back up to where it was. Nice!
Or how about clicking on various segments of music in Logic.app? I cannot predict what part of the segment will turn up; sometimes it shows the end of the segment, and other times, the beginning. Good interface design always keeps you guessing.
Worse, having to scroll around using the (too small) scroll bar is difficult, as one can easily instead either move or resize the whole window upon being off by a pixel or two. Probably apps should be run fullscreen to avoid having to fiddle the window back to shape, but that's only a workaround, and may not work for all workflows. In theory you can scroll with the trackpad, hopefully without making a weird gesture that does something untoward. I do go through and turn off most all of the gesture stuff. On review, "Click with Two Fingers" is a secondary click, and everything else is disabled.
Most of my tmux.conf is turning off features. At least there are knobs. Windows XP had some menu gewgaws with a "disable" option, but after a while they would helpfully turn themselves back on. I was not amused.
And even vi does this! Sometimes.
$ perl -E 'say( ("\n")x$ARGV[0], "foo" )' $LINES > bar
$ /usr/bin/vi bar
...
$ /usr/bin/vi +/foo bar
...
A search for "foo" in the first vi instance puts the "foo" line at the bottom of the screen, while the second instance puts it in the middle of the screen with a bunch of "~" blank lines to complete the screen. vim added some knobs to set how much padding should be around the search, or you can patch vi to make searches more likely to put things into the middle of the screen. Alas, this causes redraws when there should not be ones, so I may revert it and use {z.} when the search lands on an awkward line of the terminal.
--- vi/v_search.c
+++ vi/v_search.c
@@ -261,6 +269,10 @@ v_exaddr(SCR *sp, VICMD *vp, dir_t dir)
F_CLR(vp, VM_RCM_MASK);
F_SET(vp, VM_RCM_SETFNB);
}
+
+ F_CLR(sp, SC_SCR_TOP);
+ F_SET(sp, SC_SCR_REFORMAT | SC_SCR_CENTER);
+
return (0);
err1: msgq(sp, M_ERR,
Fun fact! You used to be able to set the window size to 0 in traditional vi, gleaned from looking up how {z.} does its magic to display the current line in the middle of the screen. However, v_exaddr is complicated so I've probably missed or maybe even broken a bunch of edge cases, as searches were (and still are?) full ex commands that allow such useless commands as {/foo/;1} which finds "foo" and then moves to the first line, unless the match fails. The intent here was likely to allow for {/foo/-2} when you were interested in lines known (or assumed) to be a certain number of lines away from a given search result, or two prior in this example. But at least this code is somewhat fixable (or has already been improved on in other lines of the vi evolutionary tree) unlike other applications where maybe someone might look at your bug report, or worse, where the distractions are the design pattern.