The Navigator has a list of "open document" that is supposed to help to navigate. This is broken and unhelpful in many ways: - When the navigator is docked to a Window, making it navigate content in another window is highly unintuitive - The same applies to the navigator as deck inside the sidebar -- which is docked by default Even when the navigator is undocked, the navigator is bound to the window it is used with: - having two windows with open documents, opening the navigator on one window with F5 and focusing the other document window makes the navigator disappear. - having two windows with open documents, opening the navigator on both windows at different window positions makes the navigator "jump" from one position to another when switching focus. Or rather one documents navigator disappears and the navigator of the other one appears. The only sane way with the current implementation seems to make the navigator refer to the active window only when floating, and when docked, to the window it is docked to. (Leaving out the fact that the sidebar can be undocked theoretically too, although that is too buggy that anyone would do it right now anyway)
Hi Björn, This view allows dragging to link / copy content from another file. E.g. a whole chapter from one to another. I like it. So .. -1 from me :)
(In reply to Cor Nouws from comment #1) > This view allows dragging to link / copy content from another file. E.g. a > whole chapter from one to another. ... except nobody will find that functionality anyway, because it is buries below all the buggy behaviour described above. :/
(In reply to Björn Michaelsen from comment #2) > ... except nobody will find that functionality anyway, because it is buries > below all the buggy behaviour described above. :/ I did find it a long time ago. Just by trying context menu on content items (using the context menu in LibreOffice is a good thing) and looking at the list at the bottom.. And if the behaviour is buggy (I do not understand in what way currently) it would be better to improve that then to remove functionality.
(In reply to Cor Nouws from comment #3) > I did find it a long time ago. Yes, but you are hardly a user to benchmark after, sorry. :/ I bet if you ask our userbase, the vast majority wouldnt even know about the navigator _at_ _all_ (although that is changing a bit since its now in the sidebar).
Hey Brörn, (In reply to Björn Michaelsen from comment #4) > Yes, but you are hardly a user to benchmark after, sorry. :/ I did not want to present myself as an 'average user'. Although by the time I found all that out, I probably was not far from that. But If you are looking for metrics (I see no so far) for the use of details of the Navigator, you have to find those in the group op people that use it, obviously. And those are not average users. > I bet if you ask our userbase, the vast majority wouldnt even know about the > navigator _at_ _all_ (although that is changing a bit since its now in the > sidebar). So it is good that it is available in the side bar too. I'm always supporting improvements for simple use, as long as it does not break the work of people that use and need LibreOffice as a power tool > (In reply to Cor Nouws from comment #3) >> .. >> And if the behaviour is buggy (I do not understand in what way currently) it >> would be better to improve that then to remove functionality. What is your opinion on that, please?
Hi (In reply to Björn Michaelsen from comment #2) > (In reply to Cor Nouws from comment #1) > > This view allows dragging to link / copy content from another file. E.g. a > > whole chapter from one to another. > > ... except nobody will find that functionality anyway, because it is buries > below all the buggy behaviour described above. :/ Precisely, the french TDF Playlist includes a video (1) which shows how to use this very useful feature. I would agree for it to be improved (?) but I am certainly not convinced of the need to remove it altogether. (1) https://www.youtube.com/watch?v=PF43zctn3RM&index=50&list=PL0pdzjvYW9RFl1ZRu8MkE3QxWQSt7Xktk Best regards Pierre-Yves
(In reply to Cor Nouws from comment #5) > > (In reply to Cor Nouws from comment #3) > >> .. > >> And if the behaviour is buggy (I do not understand in what way currently) it > >> would be better to improve that then to remove functionality. > > What is your opinion on that, please? As expressed above, the UI communicates that the navigator is bound to a specific document: - if you enable the navigator on one document, it still isnt enabled in another - if you switch between documents, you exchange the navigator of one document with one from another (e.g. position and size change) As such, each navigator is a property of each document. Allow that navigator to display content from another document is misleading and confusing. It is _conceptually_ broken and can never work in a intuitive way as it would try to achieve two conflicting goals (being a navigator for the current document and being a general purpose navigator for all open documents.) The conceptionally clean alternative would be to make the navigator consistently entirely independent if you enable the navigator on one document, it still isnt enabled in another from documents. That would mean: - the navigator would always stay open/closed when you change document windows - the navigator would never change position/size when you change document windows - the navigator would neither dock, now would be part of the dockable (and mostly docked) sidebar: A directly/indirectly docked navigator suggests it belongs to the document in the window -- thus it shouldnt navigate content from other windows.
(In reply to pierre-yves samyn from comment #6) > Precisely, the french TDF Playlist includes a video (1) which shows how to > use this very useful feature. Case in point: When you need a video to explain a feature, its a good indication that the UX is broken. Decent UX doesnt need a video explanation.
(In reply to Björn Michaelsen from comment #8) > Case in point: When you need a video to explain a feature ... Who says you need a video to explain this ?
(In reply to Björn Michaelsen from comment #7) IMO your thinking is way to complicated :) The list at the bottom shows "<name> (active)" and when you open it "<name 2> (inactive) " etc. But if you can improve the appearance and conserve the functionality, of course I'm all for that.
(In reply to Cor Nouws from comment #9) > Who says you need a video to explain this ? Seriously? 95% of our user base dont even know what the navigator is in the first place. > IMO your thinking is way to complicated :) No, its not. Having a list box at the bottom of a sidebar tab that makes that sidebar tab suddenly display content from a different document than the one that is docked is a UX horror story. Its completely unintuitive unless you watched a video or read a book about it (which 5% of our user base do, if you are _very_ _very_ optimistic). A user changing the listbox by accident or without knowing what it does will leave the user behind confused as the sidebar will not show navigation for the document in the window. A novice will not understand that. Nor should he/she: its entirely counterintuitive and broken. P.S.: I found another wart in the navigator UX horror, which breaks any hope to make the navigator a "global" navigator for all open documents: The listbox shows only documents of the same type, which is yet another unintuitive inconsistent behaviour: _If_ the navigator is independent of the current document, it should be really independent (and thus not limit to the current documents type).
Why not invite the design team to examine the horror.
With some much stacked "unintuitive inconsistent behavioural UX horror" there must be many complaints & reports from the 95% user group that got stuck in that Navigator list box :) ? No ? In any case: please leave it in the full Navigator and (AFAIAC) do in the side bar as you like. See. https://bugs.documentfoundation.org/show_bug.cgi?id=89566#c26
(In reply to Cor Nouws from comment #13) > With some much stacked "unintuitive inconsistent behavioural UX horror" > there must be many complaints & reports from the 95% user group that got > stuck in that Navigator list box :) ? No ? For the most part people are not using or even aware of the navigator.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Fully agree with Bjoern that this feature is a techie-born and badly implemented idea. The use case of accessing a chapter in another document per dropdown menu is unclear on systems with multitasking. And eventually there haven't been objections to the Navigator proposal at https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/ where this interaction is dropped.
(In reply to Heiko Tietze from comment #16) > Fully agree with Bjoern that this feature is a techie-born and badly > implemented idea. The use case of accessing a chapter in another document > per dropdown menu is unclear on systems with multitasking. I would advice that UX people pay enough attention in getting input from advanced and experienced users to judge features and possible improvement. > And eventually there haven't been objections to the Navigator proposal at > https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may- > support-object-handling-in-libreoffice-draw/ where this interaction is > dropped. I see that post has been gone mostly unnoticed, or in any case uncommented. Only one lone soul took the trouble.. By the way: I explained "The dropdown (Navigator) below the tree lists" but I see that I missed the proposal to drop that feature. What a pity..
let's just set to Won't 'Fix'. Makes little sense to leave this open, while it was concepted at least partially from not understanding how people use the feature. Of course if there is a clear idea on how to improve, avoid possible pitfalls, I'm all for that.
it's functional not only in Writer, by the way