I actually think that this is a step backwards. I've been using smartphones, tablets, tmux and a tiling window manager for several years now, and _that_ feels like the interface of the future, not overlapping windows. I have one primary interaction with my computer at any one time, but it's easy to switch interactions whenever I need to. And when I _do_ need multiple windows, I can always just split the screen. But I hardly ever have more than one window per screen, and basically never more than three windows per workstation.
This feels like a step backwards for me, too, and I love overlapping windows and never split my screen. The benefit of having multiple windows is that you can have different working contexts that don't overlap, which makes it easier to find the exact window you're looking for. But look at the screenshots in the article: you still get one web browser window, one calculator, one instance of every app. You can't split (say) the browser into Tabs for Project A and Tabs for Project B, or keep a calculation open for Project B then open a new one without destroying the old one. (Contrived examples, perhaps, but those are the only apps demonstrated in their screenshots so far. Imagine it with text editors.)
I'd imagine that the "one web browser window, one calculator, one instance of every app" is because currently there's not too much need for multiple instances. After a windowing-system is in place, I'd expect (hope?) that Android/developers would begin to add support for multiple instances.
That would be nice, but I'm not holding my breath; the existing code will probably assume one window. We've brought up being told that singletons are bad and should never be used, and then go and build programs like this!
But apps access files, databases, listen for intents. You definitely need some adjustments by app developers, even if Android handles most of the implementation details.
I also use a tiling window manager on Linux, but I think Google's decision here is based on the general public - who probably aren't ready to learn a new window management scheme. For window management, overlapping floating and resizable windows are the norm, and I think will be for some time.
That's true, but for smaller screens and only one or two apps per screen (in split screen view). I think the goal of multi-window might be to support larger display extensions (e.g. plugging a 24" display into a phone)?
Thing is that i think most are already running everything maximized (unless they are OSX users). The only things left floating are calculator and IM clients. This because the content will more often than not require the use of the majority of the screen, and they switch windows via a taskbar or similar.
BTW, i seem to recall that the original GUI design at Xerox had things tiled upon opening (they could be moved afterwards though).
Maybe people run most things maximized because window management on Windows is so limited? With 8.1 and now 10 you can arrange up to four windows on the screen without using the mouse, but even that is too basic to be useful compared to tiling window managers.
I think Google could actually pull this off by "forcing" users to use a tiling concept (like a couple of different layouts to choose from and letting you launch/drag apps into the screen areas).
I run most things maximised because, even on a Macbook retina display, I only get 1280x800 effective pixels, and that's just not enough to run more than one window at once. If I had a 5K desktop, it might be a different story. The only things I ever tile are side-by-side Finder / Terminal windows. Never see my wallpaper.
I love the idea of tiling window managers, but they really break down with the CAD tools I use. Any program that involves multiple contexts of the same information will probably suffer. (In my case, command, schematic & layout views)
I used to use i3m & dwm, but wound up spending almost all my time in floating-windows mode, and decided that was silly.
I was never able to come up with good splits. It's been years so I forget the details, but I think the problem was:
- On one monitor, these programs work best overlapped on the corners to have usable window sizes. Side-by-side or vertically stacked doesn't work.
- On two monitors, dual monitor support was not very robust so I couldn't leverage the two monitors well. My case was particular in that I was logged in via a remote desktop program, and the WM insisted on treating it as one really wide screen.
I also don't understand why I can't just swipe up from the overlay button and immediately switch to the previous window, like alt-tab. Such an obvious shortcut, yet Android doesn't do it.
Couldn't this be work towards getting functionality ready that may not be enabled on phones (or even tablets) but would allow the Chromebooks to go Android?
Comments
I actually think that this is a step backwards. I've been using smartphones, tablets, tmux and a tiling window manager for several years now, and _that_ feels like the interface of the future, not overlapping windows. I have one primary interaction with my computer at any one time, but it's easy to switch interactions whenever I need to. And when I _do_ need multiple windows, I can always just split the screen. But I hardly ever have more than one window per screen, and basically never more than three windows per workstation.
This feels like a step backwards for me, too, and I love overlapping windows and never split my screen. The benefit of having multiple windows is that you can have different working contexts that don't overlap, which makes it easier to find the exact window you're looking for. But look at the screenshots in the article: you still get one web browser window, one calculator, one instance of every app. You can't split (say) the browser into Tabs for Project A and Tabs for Project B, or keep a calculation open for Project B then open a new one without destroying the old one. (Contrived examples, perhaps, but those are the only apps demonstrated in their screenshots so far. Imagine it with text editors.)
I'd imagine that the "one web browser window, one calculator, one instance of every app" is because currently there's not too much need for multiple instances. After a windowing-system is in place, I'd expect (hope?) that Android/developers would begin to add support for multiple instances.
That would be nice, but I'm not holding my breath; the existing code will probably assume one window. We've brought up being told that singletons are bad and should never be used, and then go and build programs like this!
Just... run several processes of the same app?
But apps access files, databases, listen for intents. You definitely need some adjustments by app developers, even if Android handles most of the implementation details.
I also use a tiling window manager on Linux, but I think Google's decision here is based on the general public - who probably aren't ready to learn a new window management scheme. For window management, overlapping floating and resizable windows are the norm, and I think will be for some time.
But they already have! Anyone who's been using a smartphone this decade is used to it by now.
That's true, but for smaller screens and only one or two apps per screen (in split screen view). I think the goal of multi-window might be to support larger display extensions (e.g. plugging a 24" display into a phone)?
Thing is that i think most are already running everything maximized (unless they are OSX users). The only things left floating are calculator and IM clients. This because the content will more often than not require the use of the majority of the screen, and they switch windows via a taskbar or similar.
BTW, i seem to recall that the original GUI design at Xerox had things tiled upon opening (they could be moved afterwards though).
Maybe people run most things maximized because window management on Windows is so limited? With 8.1 and now 10 you can arrange up to four windows on the screen without using the mouse, but even that is too basic to be useful compared to tiling window managers. I think Google could actually pull this off by "forcing" users to use a tiling concept (like a couple of different layouts to choose from and letting you launch/drag apps into the screen areas).
I run most things maximised because, even on a Macbook retina display, I only get 1280x800 effective pixels, and that's just not enough to run more than one window at once. If I had a 5K desktop, it might be a different story. The only things I ever tile are side-by-side Finder / Terminal windows. Never see my wallpaper.
I love the idea of tiling window managers, but they really break down with the CAD tools I use. Any program that involves multiple contexts of the same information will probably suffer. (In my case, command, schematic & layout views)
stumpwm does have a floating-windows mode for that, but in principle one could set up splits to support most sane multi-window apps.
I used to use i3m & dwm, but wound up spending almost all my time in floating-windows mode, and decided that was silly.
I was never able to come up with good splits. It's been years so I forget the details, but I think the problem was:
- On one monitor, these programs work best overlapped on the corners to have usable window sizes. Side-by-side or vertically stacked doesn't work.
- On two monitors, dual monitor support was not very robust so I couldn't leverage the two monitors well. My case was particular in that I was logged in via a remote desktop program, and the WM insisted on treating it as one really wide screen.
I also don't understand why I can't just swipe up from the overlay button and immediately switch to the previous window, like alt-tab. Such an obvious shortcut, yet Android doesn't do it.
You can hold the recent apps button to do that in CyanogenMod.
Also, alt tab works in Android if you have a keyboard.
On the developer preview of Android N you can double tap the recents key to switch to the previous window
And alt-tab is tied to the same actions ever since Android 3.0.
Couldn't this be work towards getting functionality ready that may not be enabled on phones (or even tablets) but would allow the Chromebooks to go Android?
My thoughts exactly. They've already started going that way with ARC; this looks to me like everything converging.