https://bugs.documentfoundation.org/show_bug.cgi?id=37134
--- Comment #126 from Eyal Rozenberg <[email protected]> --- (In reply to golemus from comment #123) > I noticed that OceanAudio has one click > solution to switch between audio files (which reminds vertical tabs). On Windows, you can switch between the current and last focused window with Alt+Tab (and most other desktop environments have this same or a similar arrangement). However - if switching between opened documents with a simple key combination is what's most important to you when promoting tabs - we can instead consider something like that: The ability to switch between several documents, not just the last two focused ones, easily. For example: At the moment, and on Windows - when you type Alt+1, Alt+2 etc. you switch between Sidebar decks. And Alt+Shift+1, Alt+Shift+2 do nothing. perhaps it could be arrange for the latter, or the former, to switch between some consistent ordering of the documents open in LO. I'm not saying I would necessarily support this, but a separate bug report about just that would probably meet with much less resistance and perhaps even be confirmed as NEW. And would be easier to implement. > Most logical place (in my layout) is replacement of title bar with tabbed > docs bar. As I've already explained, it is inappropriate and detrimental to usability for applications to draw in their title bars. If you want tabs, you would need to convince people that they are merited _without_ drawing inside the title bar. > Could LibreOffice query from OS presence of title bar and when it is not > present then automatically disable the TabbedDocs UI....? It probably could. But then you would be saying that LO users in desktop environments without title bars don't need tabs - and would this be conceding most of your arguments about how users supposedly do need them, how they are important to productivity etc. Anyway, as far as I am concerned - LO will not draw anything in the titlebar, period. Luckily for you I don't have any authority so it's just my opinion as a participant in the design team. > Or don't [take up space] if they are in title bar. That is still taking up space - from the title bar. > > * They add another aspect of complexity to our UI - for users > > It could be optional feature which is disabled as default and only those who > want it enable it. That does not contradict my statement. Tabs would be another aspect of complexity _when they are in use_. > That is true but if you have learned to work with tab switching e.g. in web > browsers or Windows file explorer, lack of them makes your workflow slower. Why does it make your workflow slower? One can switch windows instead of tabs. If it's the keyboard switching, see my comment above. > This is especially true for new users who don't have the knowledge or skills > for efficient usage of multitasking and switching of windows. Users know how to switch between windows, more than they know about switching between tabs. > > Using a browser can be thought of more as an immersive and semi-passive > > experience, at least in the sense of not typing and pressing buttons and > > manipulating controls and such - which is almost the opposite of authoring a > > document. > > Have you thought that how many percentage of LibreOffice usage is authoring > and how many is browsing documents? That is an interesting point actually. Are you saying that tabs are important/useful in particular when viewing rather than editing? Can you develop this argument further? To answer the question, though: It is difficult to estimate. From my anecdotal experience, most of the time LO is used, it is used for either authoring or editing documents others have authored, and only a smaller fraction is read-only use. Maybe 30%? Again, this is purely anecdotal. > For me it is maybe 80-90% browsing and 10-20% authoring. And when I am > authoring often large portion of work is copy pasting material between > different documents which could make it much simpler if you could put them > beside each other as tabs. But you can't put tabs beside each other. You can do that with windows (or sub-windows, if it's an MDI-style UI). > If usability testing were done for person who is unfamiliar with Libre I am > pretty certain their productivity would be higher with tabbed interface. Of > course I am not assuming that FOSS app would have much of usability testing. Well, there is no budget or planning for usability testing in the near future, so that is a theoretical point. Anyway, I don't share your assumption; first, because the "productivity" metric you mentioned needs to be better defined; and second, because I believe you are projecting your aversion to using windows rather than tabs onto a prospective study. Regardless - if we did perform usability studies, we would certainly not bias them by only having people unfamiliar with LibreOffice participate. Unless you mean a study over a period of months and years as users gain experience and familiarity? > Min. hundreds of millions of people are familiar with Chromium tabbed user > interface and would almost certainly have lower barrier to learn how to > create new documents and switch between them. Billions of people are familiar with using multiple windows in a desktop environment. > Nevertheless I agree with this suggestion. Some power users are accustomed > of using OS multitasker for switching between windowed documents and might > see TabbedDocs unnecessary. For others it could be lifesaver. It's quite the opposite. Personal computing is based on the abstraction of windows on a desktop. All users know it. Per-app tabs is the less-common, and certainly less-standardized, UI aspect. > I know there are many that don't yet, but document/sheet editor such as > Libre is much more vital program. Ps. I think OnlyOffice has them. > > Don't understand either why MS is also behind era in implementing them to > Office. You're assuming that "no tabs = outdated, with tabs = modern or up-to-date". That is not the case. Tabs are sometimes relevant, sometimes less so. -- You are receiving this mail because: You are the assignee for the bug.
