Tabs come to every window in Windows 10 “Sets”
arstechnica.com
arstechnica.com
[edit] Actually, it seems it's still missing in KDE SC 5 :(
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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'm glad it is finally coming.
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!
Because I see this as very confusing for most users.
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.
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.
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.
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.
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).
Tabs won't just be for browsers; they'll be for Notepad, or Word, or Visual Studio, or Explorer, or Minecraft.