That seemed to me like the most obvious way to do it at the time, since tabs along the top of bottom edges were extremely wasteful of screen space. (That was on a big hires Sun workstation screen, not a tiny little lores Mac display, so you could open a lot more windows, especially with Emacs.)
It makes them more like a vertical linear menu of opened windows, so you can real all their titles, fit many of them on the screen at once, and you instantly access any one and can pop up pie menus on the tabs to perform window management commands even if the windows themselves are not visible.
https://en.wikipedia.org/wiki/Tab_(GUI)#/media/File:HyperTIE...
https://en.wikipedia.org/wiki/Tab_(GUI)
http://www.cs.umd.edu/hcil/trs/90-02/90-02-published.pdf
>Since storyboards are text files, they can be created and edited in any text editor as well as be manipulated by UNIX facilities (spelling checkers, sort, grep, etc...). On our SUN version Unipress Emacs provides a multiple windows, menus and programming environment to author a database. Graphics tools are launched from Emacs to create or edit the graphic components and target tools are available to mark the shape of each selectable graphic element. The authoring tool checks the links and verifies the syntax of the article markup. It also allows the author to preview the database by easily following links from Emacs buffer to buffer. Author and browser can also be run concurrently for final editing. [...]
>The more recent NeWS version of Hyperties on the SUN workstation uses two large windows that partition the screen vertically. Each window can have links and users can decide whether to put the destination article on top of the current window or on the other window. The pie menus made it rapid and easy to permit such a selection. When users click on a selectable target a pie menu appears (Figure 1) and allows users to specify in which window the destination article should be displayed (practically users merely click then move the mouse in direction of the desire window) . This strategy is easy to explain to visitors and satisfying to use. An early pilot test with four subjects was run, but the appeal of this strategy is very strong and we have not conducted more rigorous usability tests.
Using pie menus gesturally with "mouse-ahead display pre-emption" was a lot like of "swiping" on an iPad. And window managers tend to have directional commands: open on left or right side, resize from bottom right corner, move to top or bottom layer, etc, which correspond nicely to pie menu directions, so they're obvious, easy to learn, remember, and use without looking or waiting.
>In the author tool, we employ a more elaborate window strategy to manage the 15-25 articles that an author may want to keep close at hand. We assume that authors on the SUN/Hyperties will be quite knowledgeable in UNIX and Emacs and therefore would be eager to have a richer set of window management features, even if the perceptual, cognitive, and motor load were greater. Tab windows have their title bars extending to the right of the window, instead of at the top. When even 15 or 20 windows are open, the tabs may still all be visible for reference or selection, even thought the contents of the windows are obscured. This is a convenient strategy for many authoring tasks, and it may be effective in other applications as well.
I regularly used Emacs with tab windows and pie menus for software development and hypermedia authoring, and found them useful enough that I thought all NeWS applications should have them. So I implemented them as a globally shared extension to the NeWS window manager, independent of Emacs, so all NeWS applications got tabbed windows with pie menus. (NeWS was a lot like Smalltalk in that you could dynamically customize and extend the entire system like that.)
My later versions of tabbed windows with pie menus for NeWS in 1990 let you drag the tab around to any position along any edge you wanted. And they had pie menus designed to make window management quick and easy and very gestural, supporting "mouse ahead display pre-emption" and previewing and highlighting in the overlay plane (which was much faster to draw interactively than moving and resizing the live windows themselves).
https://www.youtube.com/watch?v=tMcmQk-q0k4
I iterated on the idea of tabbed windows and made several different versions over the lifetime of NeWS for its various GUI toolkits (Lite, NDE, TNT):
https://donhopkins.com/home/archive/emacs/emacs.ps
https://donhopkins.com/home/archive/NeWS/tabwin.ps
https://donhopkins.com/home/archive/NeWS/old-xnews-tab.ps
https://donhopkins.com/home/archive/NeWS/tabframe-1.ps
https://donhopkins.com/home/archive/NeWS/tab-3.0.2.ps
#/media/File:HyperTIESAuthoring.jpg){kind=link}
% Pie menus and tab windows and NOT patented or restricted, and the
% interface and algorithms may be freely copied and improved upon.
https://news.ycombinator.com/item?id=15327339
https://donhopkins.com/home/archive/NeWS/owm.ps.txt
Tabs aren't only for top level windows or frames. You can also attach tabs to any side of nested windows, so you can drag them around anywhere freely, then stick them on a "stack" to constrain their movement, so you can drag them up and down to rearrange their order on the stack, and pop them off the stack by dragging them far enough away. The tabs can have pie menus with a standard set of window management commands, as well as a submenu item for content-specific commands, so they're easy to learn (because of their common layout) and also possible to customize (because of their type specific submenu).
https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...
>There is a text window onto a NeWS process, a PostScript interpreter with which you can interact (as with an "executive"). PostScript is a stack based language, so the window has a spike sticking up out of it, representing the process's operand stack. Objects on the process's stack are displayed in windows with their tabs pinned on the spike. (See figure 1) You can feed PostScript expressions to the interpreter by typing them with the keyboard, or pointing and clicking at them with the mouse, and the stack display will be dynamically updated to show the results.
>Objects on the PSIBER Space Deck appear in overlapping windows, with labeled tabs sticking out of them. Each object has a label, denoting its type and value, i.e. "integer 42". Each window tab shows the type of the object directly contained in the window. Objects nested within other objects have their type displayed to the left of their value. The labels of executable objects are displayed in italics. [...]
>Tab Windows: The objects on the deck are displayed in windows with labeled tabs sticking out of them, showing the data type of the object. You can move an object around by grabbing its tab with the mouse and dragging it. You can perform direct stack manipulation, pushing it onto stack by dragging its tab onto the spike, and changing its place on the stack by dragging it up and down the spike. It implements a mutant form of “Snap-dragging”, that constrains non-vertical movement when an object is snapped onto the stack, but allows you to pop it off by pulling it far enough away or lifting it off the top. [Bier, Snap-dragging] The menu that pops up over the tab lets you do things to the whole window, like changing view characteristics, moving the tab around, repainting or recomputing the layout, and printing the view.
Here's some more stuff I wrote about tabbed windows in HN:
https://news.ycombinator.com/item?id=16876520
>Unfortunately most of today's "cargo cult" imitative user interface designs have all "standardized" on the idea that the menu bars all belong at the top of the screen and nowhere else, menus items should layout vertically downward and no other directions, tabs should be rigidly attacked to the top edge and no other edge, and the user can't move them around. But there's no reason it has to be that way.
Now Firefox and Chrome still need decent built-in universally supported and user customizable pie menus, but unfortunately the popup window extension API is inadequate to support them, because there's no way to make them pop up centered on the cursor, or control the popup window shape and transparency. Unfortunately they were only thinking of drop-down linear menus when they designed the API. (Stop thinking inside that damn rectangular box, people!)
But I remain hopeful that somebody will eventually rediscover pie menus in combination with tabbed window for the web browser, and implement them properly (not constrained to pop up inside the browser window and be clipped by the window frame, and not just one gimmicky hard coded menu that user's can't change and developers can't use in their own applications). But the poorly designed browser extension APIs still have a hell of a lot of catching up to do with what it was trivial to do in NeWS for all windows 30 years ago.
https://news.ycombinator.com/item?id=8041232
>These things used to rub me the wrong way in the 90's, but I've learned to take it in stride. I think it's great that people are rediscovering and trying out old ideas in new systems, and perhaps the understandable belief that something's never been done before isn't so bad, if it motivates them to keep trying out different ideas in new contexts, and leads to even more great stuff that's never been done before, or even just re-implementations of old ideas that aren't as ugly as they used to be the first time around.
>So many "modern" user interfaces are such cargo cult carbon copies of each other (like tabs along just the top edge, or that way "flat" is such a big fad these days), that it's easy to get the impression that anything slightly different is actually original.
>Back in the day, we had no choice but to draw "flat" user interfaces, because all we had was black and white, and moving the cursor across the screen was uphill both ways!
Here's an old todo list from 1987 with some other crazy ideas I (fortunately or not) never got around to implementing in NeWS. The "stack of cards with indexing tabs" would be a generic widget that let you easily flip through and manage an editable stack of things using tabs with pie menus:
https://donhopkins.com/home/archive/NeWS/news.todo.txt
What I was getting at was an extensible generalization of tabs, kind of like Scratch's tools that appear around the selected object: customizable widgets that stick out from the edges of rectangular windows, that could be various shapes (like ears or antennae) and do various things (screen snapshot, scrolling, navigation, window management, application commands, etc).
A window could have one main window management title tab (and possibly others) that were always visible, and when it was activated, other auxiliary tabs of various types could open up in the last place you left them. Some could represent iconified sub-windows, like tool pallets or nested sub-windows that you could open up recursively, like an outliner.
You could attach many different kinds of tabs to the edge of a window, move them around, hide and reveal them, and open their property sheets and help screens, etc. And you could plug in new kinds like browser extensions, or interactively script your own and copy and paste them around like a HyperCard window manager. That's how the web browser and window manager should work together seamlessly.