> it's nearly impossible to click and hold on anything along the edge to resize the window.
This is what the resize box is/was for. (It's actually draggable edges with no "meat" to them, which introduce the conflict by overloading an element, which is also just a pixel wide.)
*) The resize box used to sit below the very bottom of the vertical scrollbar, just below the down arrow button, as a distinct and dedicated handle for resizing windows. Mind how this is in the direct vicinity of any scroll buttons which may be used to see more than what is exposed by the initial view. It's the quasi "natural" origin and anchor of any basic interactions with the viewport. (Somewhat ironically, while the resize box has mostly vanished from application UIs, it is still rendered by web browsers in certain circumstances. E.g., with textarea elements with scrollbars and resize enabled. With most UIs, there will be no related scroll buttons anymore, though.)
IIRC in that era, the leftmost part of the title bar could be clicked to get a menu of options that contained Minimize, Maximize, Move, Resize, Close, and maybe one or two others. If you chose Move or Resize, the mouse would change cursors and just moving the mouse would change the window, then you'd click to get out of it.
I'm pretty sure this had a button there in like Windows 3.11 or 98, that I think was later hidden so you'd just click the title bar to get it?
You'd click the application icon in the title bar, then in WinXP you could reach it by right-clicking anywhere in the title bar.
And in the Windows 3 era, it was an actual button (IIRC the minus on the left wasn't minimize, it was this menu, and the down arrow on the right was minimize): https://www.computerhope.com/jargon/w/win3x.htm
In modern Windows 10, you still get that in well-designed applications. In poorly-designed applications (hate to throw shade at Firefox, but it is one), you may be able to still get that menu by hitting ALT+SPACE. It just pops out of nowhere because there's nowhere to click to get to it.
ALT+SPACE, M, arrow keys is forever in my brain due to so many poorly behaved programs which would open their window somewhere off-screen, and that was the way to move them back onto the screen.
> ALT+SPACE, M, arrow keys is forever in my brain due to so many poorly behaved programs which would open their window somewhere off-screen, and that was the way to move them back onto the screen.
Happens quite often with dialog boxes that pop up to inform you of some error. Particulalrly if you're working on multiple screens and have moved the application off your main one. (Which is what at least I tend to do when working on a laptop attached to one or more external screen/s.)
You brought back a muscle memory I forgot I had: ALT+Space would activate the Control Menu [1] and then pressed down twice and enter to resize the window using the keyboard arrow keys.
> IIRC in that era, the leftmost part of the title bar could be clicked to get a menu of options that contained Minimize, Maximize, Move, Resize ... I'm pretty sure this had a button there in like Windows 3.11 or 98, that I think was later hidden so you'd just click the title bar to get it?
Still there, even in Windows10. (And AFAICR even W11; only used that a couple months last year.) It's called the System Menu, IIRC. If you see nothing to click, try pressing [Alt]-[Space] -- even MS Office apps, which have gotten rid of the icon, still pop up the menu.
> And in the Windows 3 era, it was an actual button (IIRC the minus on the left wasn't minimize, it was this menu,
I also called it "the big fat hyphen" when I first started using Windows 3, but AIUI now, that was actually supposed to be a picture of the space bar. As in, you know, [Alt]-[Space].
> I also called it "the big fat hyphen" when I first started using Windows 3, but AIUI now, that was actually supposed to be a picture of the space bar. As in, you know, [Alt]-[Space].
A pic of the old Windows 3.x Program Manager with its Program Groups within the Multiple Document Interface, linked somewhere in this thread, reminded me: Sub-windows within an MDI had a shorter bar for an icon, and IIRC you got the system menu (document menu?) for the focused one by pressing [Alt]-[hyphen] (or [Alt]-[minus]).
I have that quite often as I RDP in from various desktop sizes. You can bring up the Move command with Alt+SPACE then "M" and then use cur cursor keys to move the whole pane. That allows you to bring one of the corners into view so you can then drag it.
That does make it easier to resize a window from the bottom left corner, which is indeed where you want to resize the window from in the majority of cases.
However, if you want to resize the window from the top or from the left, that does not help you much.
While this is true, it also turns a task that takes only one action (resize the window up or to the left from an edge or corner) into one that requires three or four (move window, resize window from bottom right corner, readjust window position).
I guess, it's a question of perspective. For me, maybe due to habit, these are two distinct actions: moving the origin and resizing the viewport. And I'm actually not comfortable with having to combine them in a single interaction. More often, I do not want to combine both, especially on a larger screen. Moving the viewport or its origin is a matter of the desktop metaphor, as well as altering stacking in the Z-order. Resizing it is on an entirely different level and relates to another kind of mental model or mapping, relating to aspect ratio and field of view, which, if changed, requires a remapping of the situational awareness regarding everything that makes the desktop metaphor. (BTW, I also hate snapping windows.)
Personally, I think, it's this kind of constant overloading, which makes modern interfaces harder to use, or at least, causing them to put more strain on the user. (I guess, as interaction is becoming more and more the message and thus the media, like in constantly pulling the content area for more to load or swiping one thing away to see another thing, this is probably just as it ought to be. But this is essentially slot machine territory and not a working environment.)
Possible meant: "Window's resize widget is outside the viewport, so have to first move the window by dragging the titlebar until the resize widget is accessible, then resize, then drag the titlebar again to approximately restore the window position".
Still, this seems to be more logical to me than moving the window borders, since moving something in a suitable place first, in order to maybe manipulate it there, is much more like we would proceed with real-life objects.
(However, the window being rendered for an initial view in a way where not all the crucial controls are accessible is the real problem and arguable shouldn't happen at all. At this point, every action to fix this will probably be flawed. E.g., if we resize the window by dragging any of its visible borders, any action and/or cancel buttons will be still tied to the bottom part of the window, which is still off-screen, meaning, we're still stuck. On the other hand, dragging the window by its title bar, while maybe a more promising approach, may be impossible, as there is probably not sufficient screen estate left for this, to begin with.)
> That does make it easier to resize a window from the bottom left corner, which is indeed where you want to resize the window from in the majority of cases.
> *) The resize box used to sit below the very bottom of the vertical scrollbar, just below the down arrow button, as a distinct and dedicated handle for resizing windows.
At the intersection between the vertical and the horizontal scrollbar, if both were present. Or below them both, at the right end of the status bar, if the app has one (which many did, back in the day). Still there in f'rinstance Notepad++ 8.5.4, from June this year.
This is what the resize box is/was for. (It's actually draggable edges with no "meat" to them, which introduce the conflict by overloading an element, which is also just a pixel wide.)
*) The resize box used to sit below the very bottom of the vertical scrollbar, just below the down arrow button, as a distinct and dedicated handle for resizing windows. Mind how this is in the direct vicinity of any scroll buttons which may be used to see more than what is exposed by the initial view. It's the quasi "natural" origin and anchor of any basic interactions with the viewport. (Somewhat ironically, while the resize box has mostly vanished from application UIs, it is still rendered by web browsers in certain circumstances. E.g., with textarea elements with scrollbars and resize enabled. With most UIs, there will be no related scroll buttons anymore, though.)