Tabs come to every window in Windows 10 “Sets”(arstechnica.com)
arstechnica.com
Tabs come to every window in Windows 10 “Sets”
https://arstechnica.com/gadgets/2017/11/tabs-come-to-every-window-in-windows-10-sets/
41 comments
Fluxbox has those (http://fluxbox.sourceforge.net/features/tabs.php) and Haiku too (https://www.haiku-os.org/docs/userguide/en/gui.html#stack-ti...).
The tiled WMs also have this after a fashion.
Honestly i get the feel that MS i looking at how devs like to do things over at _nix, and looks for ways to import that into Windows to attempt to entice said devs.
After all, Windows these days can tile windows, have a build in desktop switcher, has gained a _nix cli and related toolchain, and now will be getting this.
Honestly i get the feel that MS i looking at how devs like to do things over at _nix, and looks for ways to import that into Windows to attempt to entice said devs.
After all, Windows these days can tile windows, have a build in desktop switcher, has gained a _nix cli and related toolchain, and now will be getting this.
kwin has those as well, since KDE 4.
https://ubuntulife.files.wordpress.com/2009/07/oxygen-tabs.p...
[edit] Actually, it seems it's still missing in KDE SC 5 :(
[edit] Actually, it seems it's still missing in KDE SC 5 :(
Finally! Nice to see some innovation on the Windows desktop (although, as others have noticed, MS moved only after Apple added per-app tabs first).
I like that it (seemingly) can group related documents from different applications - like I can switch between vi and a command line in tmux with Ctrl+a,a. Why couldn't I do the same with graphical applications?
Interestingly, the GNOME 2 human interface guidelines recommended way back that you shouldn't use tabs in your application, because it was expected that the window manager will "soon" get native tabs.
I like that it (seemingly) can group related documents from different applications - like I can switch between vi and a command line in tmux with Ctrl+a,a. Why couldn't I do the same with graphical applications?
Interestingly, the GNOME 2 human interface guidelines recommended way back that you shouldn't use tabs in your application, because it was expected that the window manager will "soon" get native tabs.
What per-app tabs are you talking about? This whole idea is actually cross-app tabs.
On recent macOS, you can group multiple windows from one app together.
It's quite clever, because the convention was already to have simple toplevel windows for each document. Apps can simply opt in and you can get tabs for free.
It's quite clever, because the convention was already to have simple toplevel windows for each document. Apps can simply opt in and you can get tabs for free.
The other day, I was just thinking about the old Multi-Document Interface that used to be so common in the Window 3/Windows 95 era. MDI was done well in old versions of mIRC and very poorly by StarOffice (OpenOffice.org/Libre Office's ancestor).
MDI has all but vanished. Now we see basically three paradigms: - Simple, all-in-one applications (notepad, calculator) - Tabbed interfaces (Browsers, sublime, atom, etc) - Tool and document windows (GIMP's default, Pidgin)
Tabbed interfaces are clearly on the upswing so this makes sense as a window/document management technique. Still, I wonder if there is still a place for MDI that we are missing out on because it is out of style.
MDI has all but vanished. Now we see basically three paradigms: - Simple, all-in-one applications (notepad, calculator) - Tabbed interfaces (Browsers, sublime, atom, etc) - Tool and document windows (GIMP's default, Pidgin)
Tabbed interfaces are clearly on the upswing so this makes sense as a window/document management technique. Still, I wonder if there is still a place for MDI that we are missing out on because it is out of style.
"Still, I wonder if there is still a place for MDI that we are missing out on because it is out of style."
It would be an interesting experiment to run, because MDI died around the time that 1024x768 was a big screen. A lot has changed since then.
Although, arguably, one can get most or all of the benefits with a multi-workspace window manager and a workspace running a tool & document program by itself.
It would be an interesting experiment to run, because MDI died around the time that 1024x768 was a big screen. A lot has changed since then.
Although, arguably, one can get most or all of the benefits with a multi-workspace window manager and a workspace running a tool & document program by itself.
That's a fair point - there isn't really a major difference in that case.
Thinking back, I remember using the MDI mIRC and having an active channel in its own window. The rest of the channels and lists were inside the mIRC application. I then had my chat up with whatever document I was working on.
The thing from that kind of setup that is hard to come to today is a simple way to designate some windows a less important than others. The important ones get into the task manager/dock. The unimportant ones are grouped with other similar windows.
I can't think of a major desktop that I've used that lets you do that. It seems to be all or nothing. I've seen docky and some KDE plasmoids get kind of close.
Thinking back, I remember using the MDI mIRC and having an active channel in its own window. The rest of the channels and lists were inside the mIRC application. I then had my chat up with whatever document I was working on.
The thing from that kind of setup that is hard to come to today is a simple way to designate some windows a less important than others. The important ones get into the task manager/dock. The unimportant ones are grouped with other similar windows.
I can't think of a major desktop that I've used that lets you do that. It seems to be all or nothing. I've seen docky and some KDE plasmoids get kind of close.
I think that speaks to the big reason I think MDI fell by the wayside: the OS took on a more active role in window management. MDI makes sense in Windows 3.1 when your application can easily provide the exact same management tools as Windows itself: the classic Tile/Cascade menu items and not really all that much more. The steady progression in the power of the taskbar starting in Windows 95 I think corresponds somewhat directly in the drop off of MDI applications, as it started to get harder and harder to mimic the taskbar in your own application and Windows at least never offered much of an out-of-the-box application framework for that. Part of that was philosophical; Microsoft didn't provide a strong MDI framework because they didn't see a need (and probably felt MDI was too confusing users). (Mac OS did provide more options over the years and there are still MDI-ish applications there, so it is interesting to compare the philosophical divergences over the years.)
"Sets" are interesting here because it is a return, the long way around to MDI in a way, but with years of learning/experience of task management from modern taskbars, IE/Edge tabs, and other thoughts on task switching. I like the idea that in Microsoft's opinions Sets are more useful as diverse collections of heterogeneous applications (a Word document and its OneNote notebook and its Edge browser research tabs together in one window) rather than the classic MDI homogeneous approach. I think that may be the welcome modern twist the MDI concept was missing originally.
"Sets" are interesting here because it is a return, the long way around to MDI in a way, but with years of learning/experience of task management from modern taskbars, IE/Edge tabs, and other thoughts on task switching. I like the idea that in Microsoft's opinions Sets are more useful as diverse collections of heterogeneous applications (a Word document and its OneNote notebook and its Edge browser research tabs together in one window) rather than the classic MDI homogeneous approach. I think that may be the welcome modern twist the MDI concept was missing originally.
One interesting use of MDI was in the early Opera browser, that carried forwards into Opera 12.
And Vivaldi has inherited some of that, in that you can create a tab group, and then have that group tiled inside a single view.
And Vivaldi has inherited some of that, in that you can create a tab group, and then have that group tiled inside a single view.
> Still, I wonder if there is still a place for MDI that we are missing out on because it is out of style.
Image editing is the obvious example. Most image editors use tabs and this is annoying because you often want to have multiple images visible at the same time - especially when you are painting something and want to have references or have a palette in a separate window that you pick colors from. Also it is useful to have two or more views of the same image in different zoom levels visible at the same time (some applications provide a special case for this, but really is just a hack for not having true MDI).
FWIW Krita has a MDI mode, although it implements the functionality itself (well, Qt does it, but that is details) and it is sub-par to the native functionality (e.g. when moving or resizing windows you always get an outline like in Win3.1 instead of having the window follow the mouse).
Another example is chat programs - i always loved how i could tile multiple channel windows in mIRC, for example (all other - graphical - IRC clients i've used over the years only allow a single channel to be visible).
Text editors are sometimes good, although this probably needs to be paired with a tabbed interface. But over the last few years i actually ended up using an old C compiler (Borland C... well, it also does C++ but i don't use that :-P), partly because of its compilation speed but also because i like the MDI interface [1] (although i dislike the ugly Vista theme... i think one of the reasons people stopped using MDI is because of how ugly the theme looks and how big and wasteful the window borders are) because i can overlap and move windows around.
Generally speaking i think whenever you want to have multiple views visible at the same time in a program with some elements of the program always visible (e.g. a toolbar, a property editor, etc), MDI is helpful. Docked and tabbed interfaces very often end up with elements being stretched and/or jumbled and forced to align with each other.
Of course some of that stuff could also be done with virtual desktops, but often it is useful to be able to take the entire "window group" and move it around in the screen or minimize it. Some window managers allow you to do such things though (e.g. in Window Maker - my favorite window manager - you can hide all the windows of a program in one go, select a bunch of windows and move them to different virtual desktops with the mouse wheel and move them around as a group).
Interestingly Mac OS X solves some of that by using the global menu bar as the static always-there element and the auto-hiding inspectors. Or at least did until some years ago, some of Apple's newer apps go for the docked panel approach whereas previously it would be a floating inspector.
[1] https://i.imgur.com/SPJKrjE.png
Image editing is the obvious example. Most image editors use tabs and this is annoying because you often want to have multiple images visible at the same time - especially when you are painting something and want to have references or have a palette in a separate window that you pick colors from. Also it is useful to have two or more views of the same image in different zoom levels visible at the same time (some applications provide a special case for this, but really is just a hack for not having true MDI).
FWIW Krita has a MDI mode, although it implements the functionality itself (well, Qt does it, but that is details) and it is sub-par to the native functionality (e.g. when moving or resizing windows you always get an outline like in Win3.1 instead of having the window follow the mouse).
Another example is chat programs - i always loved how i could tile multiple channel windows in mIRC, for example (all other - graphical - IRC clients i've used over the years only allow a single channel to be visible).
Text editors are sometimes good, although this probably needs to be paired with a tabbed interface. But over the last few years i actually ended up using an old C compiler (Borland C... well, it also does C++ but i don't use that :-P), partly because of its compilation speed but also because i like the MDI interface [1] (although i dislike the ugly Vista theme... i think one of the reasons people stopped using MDI is because of how ugly the theme looks and how big and wasteful the window borders are) because i can overlap and move windows around.
Generally speaking i think whenever you want to have multiple views visible at the same time in a program with some elements of the program always visible (e.g. a toolbar, a property editor, etc), MDI is helpful. Docked and tabbed interfaces very often end up with elements being stretched and/or jumbled and forced to align with each other.
Of course some of that stuff could also be done with virtual desktops, but often it is useful to be able to take the entire "window group" and move it around in the screen or minimize it. Some window managers allow you to do such things though (e.g. in Window Maker - my favorite window manager - you can hide all the windows of a program in one go, select a bunch of windows and move them to different virtual desktops with the mouse wheel and move them around as a group).
Interestingly Mac OS X solves some of that by using the global menu bar as the static always-there element and the auto-hiding inspectors. Or at least did until some years ago, some of Apple's newer apps go for the docked panel approach whereas previously it would be a floating inspector.
[1] https://i.imgur.com/SPJKrjE.png
I think this is a very interesting move from Microsoft. Although it is a good multitasking innovation, I cannot help but notice the fact that - this integrates Edge on every application there is, and with a search bar right there, people might start using edge more often than what they currently do now. At least I never open edge voluntarily.
I'm ok with Edge and Bing being the default "web tab" providers for this new tab functionality, but I'll be instantly changing it for a different browser and search engine. If it's not possible to change this I'll probably ignore tabs entirely until it is.
Step one, move the task bar to the top of the screen. Step two, maximize all your app windows. Tada! Tabs!
I'm joking of course, but this is the problem with Windows in general. Microsoft always adds new UI features on top of old functionality that usually does sort of similar things, making the end result more complicated and disconnected.
I'm joking of course, but this is the problem with Windows in general. Microsoft always adds new UI features on top of old functionality that usually does sort of similar things, making the end result more complicated and disconnected.
Step three: Right click taskbar, 'Taskbar buttons:' -> 'Never combine'. Result: both app and document tabs. :-)
Tabs in browser are a problem for me generally because the basic implementation is tabs along the top of the screen. Once you open more than about 10 tabs, that design fails horribly.
Also, in web browsing at least, new tabs opened off of one have relevance to to the tabbed opened from, so ultimately tabs should be a tree structure.
For this reason I use "Tree Style Tabs" for Firefox...
The thing is, I can only imagine that Microsoft isn't going to implement what I am describing. They are going to implement tabs at the top, and possibly side tabs at the best, but they will certainly not make tree tabs... As a result I fail to see how this will be an improvement.
Also, in web browsing at least, new tabs opened off of one have relevance to to the tabbed opened from, so ultimately tabs should be a tree structure.
For this reason I use "Tree Style Tabs" for Firefox...
The thing is, I can only imagine that Microsoft isn't going to implement what I am describing. They are going to implement tabs at the top, and possibly side tabs at the best, but they will certainly not make tree tabs... As a result I fail to see how this will be an improvement.
I've been asking for this for a decade.
I'm glad it is finally coming.
I'm glad it is finally coming.
Me too!! I have so wondered why none of the OS makers was going in this direction. This is a complete gamechanger.
macOS has tabs as an OS feature available in most apps:
https://support.apple.com/kb/PH25079
But I see the main new thing Windows is doing is different apps grouped into one window. That should be handy!
https://support.apple.com/kb/PH25079
But I see the main new thing Windows is doing is different apps grouped into one window. That should be handy!
It's not the same thing. In macOS, it has tabs within one application. It's about tabs across different apps inside one window.
Could you explain the reason why this is better? If we have different App Tabs within the same Window, isn't that a duplicate of Task bar?
Because I see this as very confusing for most users.
Because I see this as very confusing for most users.
It's serving the same function that Mac users can do via virtual desktops ("mission control", formerly "spaces"), you group the related things together even if they're in different apps. This is just doing it in a window instead.
Windows 10 got a similar multiple desktops feature in a previous update, so this seems like a a second layer of doing the same thing. Whether it's better, or if people will use one or the other or both, who knows?
I can say that I use multiple desktops on my Mac all the time and never do on Windows, but that's partly because my Mac is a laptop where screen space is more scarce and the trackpad gestures are very fast.
There's definitely some diminishing returns of more and more layers of grouping. Firefox had a "Tab Groups" thing going for a while that let you toggle between different sets of tabs within one window. Doing something at the window manager level where it's a consistent way of packing more stuff into a window across the OS strikes me as more useful.
I'm not convinced I'd use this instead of multiple desktops though. If I'm single tasking there aren't usually things I want to group with it, and if I'm multitasking I'll typically want the other window to be visible (or at least sometimes visible) alongside the main task.
Windows 10 got a similar multiple desktops feature in a previous update, so this seems like a a second layer of doing the same thing. Whether it's better, or if people will use one or the other or both, who knows?
I can say that I use multiple desktops on my Mac all the time and never do on Windows, but that's partly because my Mac is a laptop where screen space is more scarce and the trackpad gestures are very fast.
There's definitely some diminishing returns of more and more layers of grouping. Firefox had a "Tab Groups" thing going for a while that let you toggle between different sets of tabs within one window. Doing something at the window manager level where it's a consistent way of packing more stuff into a window across the OS strikes me as more useful.
I'm not convinced I'd use this instead of multiple desktops though. If I'm single tasking there aren't usually things I want to group with it, and if I'm multitasking I'll typically want the other window to be visible (or at least sometimes visible) alongside the main task.
Many (non-technical) people have learned how to use tabs by using the them in web browsers.
You should be able to drag the tabs around the window so they stick out of any edge! Tabs on the left and right edges are great because you can stack many of them in a column and read all their titles -- more tabs fit on the screen that way.
https://www.youtube.com/watch?v=tMcmQk-q0k4
https://dev-videos.com/videos/tMcmQk-q0k4/NeWS-Tab-Window-De...
http://www.donhopkins.com/home/archive/NeWS/tab-3.0.2.ps
https://en.wikipedia.org/wiki/File:HyperTIESAuthoring.jpg
https://en.wikipedia.org/wiki/File:Psiber-tabs2.gif
https://en.wikipedia.org/wiki/Tab_(GUI)
Large numbers of tabbed windows scale better with the tabs along the left or right edges of the window, instead of the top or bottom edges. That is because tab labels are usually much wider than they are tall, and because it is now common to use displays which are considerably wider than needed for displaying documents and web pages. The NeWS version of the UniPress Emacs text editor placed tabs along the right window edge, and laid windows out in a vertical column, so each tab was initially visible, and the user could use them to raise and lower the windows, drag them around in the column, or pull them out to anywhere on the screen.
PSIBER visual PostScript programming environment for NeWS, with tabbed windows around objects on and off the stack. Better yet, tabbed window interfaces can give the user the freedom to position the tabs along any edge, so all four edges are available to organize different groups of tabs as the user or application sees fit. The PSIBER visual PostScript programming environment for NeWS had tabbed views that you could stick onto the stack (represented as a "spike"), and you could move the tabs to any edge. The NeWS pie menu and tab window manager enabled users to position the tabs anywhere along any edge, and the tabs popped up pie menus with window management functions, to uncover and bury windows, etc.
https://www.youtube.com/watch?v=tMcmQk-q0k4
https://dev-videos.com/videos/tMcmQk-q0k4/NeWS-Tab-Window-De...
http://www.donhopkins.com/home/archive/NeWS/tab-3.0.2.ps
https://en.wikipedia.org/wiki/File:HyperTIESAuthoring.jpg
https://en.wikipedia.org/wiki/File:Psiber-tabs2.gif
https://en.wikipedia.org/wiki/Tab_(GUI)
Large numbers of tabbed windows scale better with the tabs along the left or right edges of the window, instead of the top or bottom edges. That is because tab labels are usually much wider than they are tall, and because it is now common to use displays which are considerably wider than needed for displaying documents and web pages. The NeWS version of the UniPress Emacs text editor placed tabs along the right window edge, and laid windows out in a vertical column, so each tab was initially visible, and the user could use them to raise and lower the windows, drag them around in the column, or pull them out to anywhere on the screen.
PSIBER visual PostScript programming environment for NeWS, with tabbed windows around objects on and off the stack. Better yet, tabbed window interfaces can give the user the freedom to position the tabs along any edge, so all four edges are available to organize different groups of tabs as the user or application sees fit. The PSIBER visual PostScript programming environment for NeWS had tabbed views that you could stick onto the stack (represented as a "spike"), and you could move the tabs to any edge. The NeWS pie menu and tab window manager enabled users to position the tabs anywhere along any edge, and the tabs popped up pie menus with window management functions, to uncover and bury windows, etc.
ConEmu[0], a Windows console emulator, offers something like this - combine any number of windows GUI apps into one window ConEmu instance. I don't always use Windows, but when I do, I use ConEmu. It's one of the few apps I install to make windows tolerable for myself, UX and functionality a wise.
[0] https://conemu.github.io
[0] https://conemu.github.io
Will Ctrl-Tab and Ctrl-Shift-Tab work productively like they did in MDI days (cycle thru most recently used tab rather than the arbitrary, but "aesthetically pleasing", left-tab and right-tab?)
Can the tab's currently edited document be associated with the tab beyond simple "title" metadata? For example, can I get an icon on the tab representing the tab's in-progress document that I can drag to drop sites like Slack or an email being composed?
What statuses can be visualized on the tabs out of the box? (Percentage complete? Ancillary status icons?)
How's accessibility going to work with tabs? What happens to the client area when you switch tabs? What gets read on the tabs when you cycle through them?
I suspect these Sets are not going to make MDI great again because they will be underspecified as a UX standard or will be denuded of any productivity features (mobile first), and thus will be abused by developers who resort to hacking to get the results they want.
Can the tab's currently edited document be associated with the tab beyond simple "title" metadata? For example, can I get an icon on the tab representing the tab's in-progress document that I can drag to drop sites like Slack or an email being composed?
What statuses can be visualized on the tabs out of the box? (Percentage complete? Ancillary status icons?)
How's accessibility going to work with tabs? What happens to the client area when you switch tabs? What gets read on the tabs when you cycle through them?
I suspect these Sets are not going to make MDI great again because they will be underspecified as a UX standard or will be denuded of any productivity features (mobile first), and thus will be abused by developers who resort to hacking to get the results they want.
Ctrl-Tab and Ctrl-Shift-Tab already work on Edge (as does Ctrl-PageUp/PageDown) so i'd expect this to work in a similar way. Not sure how it will handle applications that need those keys for themselves though... but probably if an application lets the event reach DefWindowProc, it'll be assumed it doesn't use the shortcut for itself (for Win32 programs at least).
Apparently, the Tab control is is lifted directly from Edge. https://twitter.com/h0x0d/status/931595009177960449)
About time.
I tire of how slowly the dominant platform can move due to network effects. Facebook will probably add some similarly obvious features to their interface as soon as it starts its slide into obscurity.
I tire of how slowly the dominant platform can move due to network effects. Facebook will probably add some similarly obvious features to their interface as soon as it starts its slide into obscurity.
This looks like a really cool feature!
But in its current form it does not seem to fit code editing scenario on large screens: I need to keep IDE project open next to browser so they are visible at the same time. On multiple screens this would require something like task-based full-screen multimonitor layers (as in Photoshop layers).
But in its current form it does not seem to fit code editing scenario on large screens: I need to keep IDE project open next to browser so they are visible at the same time. On multiple screens this would require something like task-based full-screen multimonitor layers (as in Photoshop layers).
That’s an awesome feature I’ve been dreaming about for macOS. I wear many hats and have several clients. It’d super nice to be able to organize into these virtual sets everything related. Eg term, Chrome, editor.
Tabs on explorer or GTFO
I am not a fan the window tab uses too much screen real estate.
Also bad for stardock who released an addon providing this functionality earlier in the month.
Kind of redundant since win 10 has proper virtual desktops now.
Finally, ion3 concept implemented in a mainstream OS.