okay, a terminology issue: Faithlife uses the term "panel" or "tab" to refer to a specific resource and the term "tile" to the location containing several panels/tabs within a window.
The basic idea is that one could define a layout with specific tiles for Bible, Commentaries, dictionaries, visualizations, interactive ... i.e. instead of the current algorithm for assigning a resource to a tile upon opening, the user would control where it opens by defining tiles for specific library types.
This question comes up periodically.
Short answer: There's broad consensus that the tiled layout we have in L4/5/6 is great, except that panel opening is kind of mysterious. We'd like to fix that, too, but it's much more complicated than it might first seem.
Long answer:
L2 and L3 were what's called a multi document interface, or MDI. An MDI is basically windows-within-windows where can open multiple "document" (in our case document, resource, tool, and guide) windows inside of the main application. These child windows work like regular application windows in all respects, except that they are contained within their parent window (the app). They can be maximized, minimized, and most importantly, they can overlap.
The new window opening algorithm was simple: New resources on the right, new tools/reports on the left. This worked really well as long as you never deviated from the two vertical halves left and right layout.
When we did our user research for the L4 design, we found that many many users were experiencing frustration because their windows were overlapping and partially or wholly obscuring windows "behind." (L3 had a sort of rudimentary "tab" interface, but that would only work if you locked in two or more windows to exactly the same X,Y coordinates and size. So it failed easily and often.) Minimizing a window didn't really make it go away, it just made it tiny and shoved it to the bottom left corner, behind everything else.
We also asked users to send us screen shots of their favorite work setups. We found that every single one of them used all the empty space on the screen with no gaps. When we watched users creating these layouts, we also found that they spent a lot (and I mean A LOT) of wasted clicks and drags fiddling with the borders of child windows to cover the gaps. We found several people intentionally left a small strip of empty space in the lower-left corner of the screen. Puzzled, we asked those users why they set it up that way. It was so that minimized windows wouldn't get "lost" but would go into this little gap in the lower left.
Our design solution to both of these problems was to create a tiled layout system where every window is "docked" into a portion of the screen and all of the screen real estate is used (with the exception that we only use one half when there's only one tile). This solved all of the foregoing problems very elegantly. It's a very sophisticated docking/tiling system that (if I may say myself), I've never seen equaled. With the true tabbing system on top of the automatic space-filling tile layout system, it's really second to none.
In the L4/5/6 layout system, the screen is divided into tiles that a) must occupy all the available space, and b) cannot overlap.
But every design comes with trade-offs. In the old system, the panel opening logic was dead simple. In the new system, you could create any layout with impunity and be certain that no windows were lost. But the rule that tiles cannot overlap means that the panel opening algorithm has to choose which tile to open a new tab into.
Turns out, there isn't a right answer, because sometimes you want like panels stacked on top of each other (eg, all Bibles in the upper-right corner) but sometimes you don't (eg, you're reading these translations side-by-side to compare). We decided on this heuristic, which isn't perfect:
(1) Some panels should open in a new floating window because their content is large. For example, Timeline. Other panels we think should open in sidebars, for example, Favorites.
(2) Of the remaining panels, we first check for open empty space, and open there. If there's no empty space, we compare the metadata of all open tiles and open the new panel into the tile that most closely matches. So, if you stack a lot of Bible dictionaries into a corner, it's more likely (but not guaranteed) that opening another Bible dictionary will stack on top.
(3) HOWEVER, there's a final rule, and that is that if you open a new panel from a hyperlink, we try very hard not to open that new panel on top of the one you just clicked in (ie, the one you're working with). We originally didn't have this rule and found a lot of users weren't happen that clicking a Bible reference in a commentary was likely to open the Bible over top of the commentary they were reading (and other similar situations -- clicking anywhere in a Passage Guide pretty much assured that Passage Guide was going to get covered up).
This heuristic creates a certain unpredictability to panel opening that we don't particularly care for, either, but it's the least-worst alternative.
We have several ideas for how to give a panel a user-specified preference on where to open. Current thinking is that the simplest approach is to attack rule #1 in the heuristic above: Let people decide for new default locations (main layout, left sidebar, right sidebar, or new floating window) for whichever panels they feel most strongly about. Some people, for example, almost always drag Text Comparison out of the right sidebar into the main layout, because they want to see the comparisons side-by-side instead of stacked on top of one another. You should be able to tell Logos that's your style, and to stick to it.
Other ideas have users drawing out empty tiles in their preferred layout, with some sort of rule system to guide newly opened panels to those tiles, sort of like Collection rules. For example, you could draw a rectangle on the upper-right corner and declare that "type:bible" goes there, no questions asked. (Lots of corner cases here.)
Maybe one or the other. Maybe both. Maybe, maybe — someday.
One thing we won't do is go back to a classic MDI interface. Those have (thankfully) mostly died out.
I hope that's a helpful explanation of how we got where we are and were we might go from here. Happy hunting!
