I think an interface that presents you with multiple windows by default, and then lets you drag them, is a lot more discoverable than what the iPad is doing.
I agree. This is a challenge with the iOS (and Android) UIs, I think. Mice and trackpads have a more obvious and somewhat richer set of "verbs" for interaction, e.g., right-click versus "try tapping with two fingers," and menu bars make all their commands very easily discoverable in ways that toolbar-only UIs have a lot of trouble duplicating.
I'm not sure, though, what a better approach is on the iPad, assuming that we don't just give a menu bar. I'm pretty interested in a lot of these changes; as silly as it may sound, being able to display two documents from the same app side by side on the iPad will alone solve one of my huge frustrations with the system as it is now, and the changes to the Files app sound like they'll be really useful in practice. I know there will be a lot of folks, particularly in the HN crowd, who will be upset that iPads can't do [Insert Thing They Need], but iOS, er, iPadOS is reaching a point where there's very little it can't do that I personally need. (Adding my proviso that "the iPad can't do this thing I need to do the way I'm used to doing it" should not be conflated with "the iPad can't do this thing I need.")
> This is a challenge with the iOS (and Android) UIs, I think. Mice and trackpads have a more obvious and somewhat richer set of "verbs" for interaction
GTK+3 has a good approach there, I think. It turns the window titlebar into a thick "header bar", which includes a "title" part for easy grabbing as well as a handful of button-accessible menus (fewer than the top levels in a traditional menubar), including a kitchen-sink "hamburger menu" for lesser-used options. It becomes a bit less convenient for mouse&keyboard use, but the touch usability is absolutely there. Too bad that running Linux on tablet-like computers is still way too fiddly, it could be a fierce competitor to the iPad ecosystem for more pro tasks.
Added: And on recent GTK+3 releases, one can shrink the window horizontally and the buttons will simply shift to the bottom when there's not enough room for them in the top headerbar. This solves a flexibility issue with the previous headerbar-only approach (especially on smaller or lower-res screens), while still being quite intuitive.
> GTK+3 has a good approach there, I think. It turns the window titlebar into a thick "header bar", which includes a "title" part for easy grabbing as well as a handful of button-accessible menus
In case you don’t know, that’s what modeled after macOS. (It had it from the beginning. AFAIK)
