Bug 89566 - SIDEBAR: Improving the navigator tab in Writer
Summary: SIDEBAR: Improving the navigator tab in Writer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0
Keywords: topicUI
: 93871 93872 (view as bug list)
Depends on: 89553
Blocks: Navigator
  Show dependency treegraph
 
Reported: 2015-02-22 15:49 UTC by Yousuf Philips (jay) (retired)
Modified: 2020-06-15 20:03 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
first mockup (55.44 KB, image/png)
2015-02-22 23:01 UTC, Yousuf Philips (jay) (retired)
Details
second mockup (67.11 KB, image/png)
2015-02-23 16:31 UTC, Yousuf Philips (jay) (retired)
Details
navigator screenshot (43.65 KB, image/png)
2017-12-23 07:46 UTC, Jim Raykowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-02-22 15:49:39 UTC
I believe the navigator floating window and sidebar tab can be better organized to make it more useful as well as making it less intimidating to new users.

1) Removal of Buttons - The header and footer buttons (both of which need better tooltips) arent really necessary in an advanced feature like this, as a user could easily click in the header or footer areas.

2) Import Navigation - The navigation button opens up a floating dialog with the options to click on a type of object to move through the document with. This could easily be to navigator in the form of a drop down listbox and the previous and next buttons would go next to it.

3) Grouping Heading Buttons - Heading buttons are scattered across both rows and it would be better that they were all next to each other.

4) Page number label - A text label needs to appear next to the page number control so that it is easily understood.

5) Content View - This view is very useful for people wanting an outline view, like which is found in MS Word, and clears out other navigator categories from view, so it would be beneficial to highlight the two navigator views, even if its just a text label.

6) Hiding 'Headings' in Content View - When content view is enabled, there isnt a need to show navigator category 'Headings'.

7) Improving Visuals of Hierarchy - It would be easier to see the hierarchy in Headings if there less space between the arrows and the label and more space in the indentation of the arrows. Alternatively the visuals could also be improved with lines going between the levels like ( http://www.drk.com.ar/daphne/drk_daphne_process_hierarchy_tree.png ) or ( http://i.imgur.com/0yI6W4l.png ).
Comment 1 Cor Nouws 2015-02-22 16:20:30 UTC
Hi Jay,

Thanks :)

(In reply to Jay Philips from comment #0)

> 1) Removal of Buttons - The header and footer buttons (both of which need
> better tooltips) arent really necessary in an advanced feature like this, as
> a user could easily click in the header or footer areas.

The only reason I could think of, is that when browsing through the document, you don't need to leave the Navigator - all is there.

> 2) Import Navigation - ...

OK

> 3) Grouping Heading Buttons - Heading buttons are scattered across both rows
> and it would be better that they were all next to each other.

Promote/demote chapter are a different type of action than Promote/demote chapter. So I never found it strange or disturbing to have them a two rows.
But changing wouldn't hurt me probably.

> 4) Page number label - ...

OK

> 5) Content View - This view is very useful for people wanting an outline
> view, like which is found in MS Word, and clears out other navigator
> categories from view, so it would be beneficial to highlight the two
> navigator views, even if its just a text label.

I don't understand what you mean with " highlight the two navigator views"
Also when all categories are shown, it still functions the same (only that drag and drop is not possible and that the position in the Navigator doesn't follow the cursor position in the document)

> 6) Hiding 'Headings' in Content View - When content view is enabled, there
> isnt a need to show navigator category 'Headings'.

What do you mean with "show navigator category 'Headings'" That one you refer to in you #2?  
It's also in non-Content view possible to double click a heading to jump to it..

> 7) Improving Visuals of Hierarchy - ...

OK!

Cor
Comment 2 Cor Nouws 2015-02-22 16:23:00 UTC
By the way: is it your intention to make the Navigator in the Side bad different than that one floating free ?
Cheers
Cor
Comment 3 Yousuf Philips (jay) (retired) 2015-02-22 21:22:49 UTC
Hi Cor,

So glad you got to see this one. :D

(In reply to Cor Nouws from comment #1)
> The only reason I could think of, is that when browsing through the
> document, you don't need to leave the Navigator - all is there.

Yes i thought that might be a reason but noticed that the buttons do nothing if you are on a page with no header or footer and also that headers and footers dont change that frequently in a document, so there isnt a need to jump to them that often.

> Promote/demote chapter are a different type of action than Promote/demote
> chapter. So I never found it strange or disturbing to have them a two rows.
> But changing wouldn't hurt me probably.

I noticed that Word also had it across two lines, though the promote/demote level buttons had a combobox between them to easy promote/demote to another level as well as buttons to promote it to the highest level and lowest level. I think these additional controls maybe useful to be added as well.

Another reason to put them all on the same row was that they all get disabled when you are not in headings, so it would be easier to ignore the entire line of icons as they would all be disabled.

> I don't understand what you mean with " highlight the two navigator views"
> Also when all categories are shown, it still functions the same (only that
> drag and drop is not possible and that the position in the Navigator doesn't
> follow the cursor position in the document)

Was just stating that this feature needs a bit more focus so users may more likely try it if they didnt already know about it.

> What do you mean with "show navigator category 'Headings'" That one you
> refer to in you #2?  
> It's also in non-Content view possible to double click a heading to jump to
> it..

I had initially thought that Content View was exclusive to only Headings, so i thought it could be removed if that was the case, but i see now that it can be done for any of the navigator categories. As this is the case, it might be better to replace the content view button with a combobox that would have the list content entries in it.

(In reply to Cor Nouws from comment #2)
> By the way: is it your intention to make the Navigator in the Side bad
> different than that one floating free ?

They are identical now, so i dont think there is a reason to change make them different if they are sharing the same code.

By the way, i couldnt understand what the buttons labeled toggle, drag mode, set reminder, and anchor<->text.

I've also filed a bug to improve the page number control (bug 89553).
Comment 4 Yousuf Philips (jay) (retired) 2015-02-22 23:01:11 UTC
Created attachment 113613 [details]
first mockup

Was messing around with the reorganization and here is the first mockup.
Comment 5 Heiko Tietze 2015-02-23 08:30:21 UTC
Your proposal is much better but has still a lot of controls in the header. Why not restrict it to functions that tweak the view below and not the document.

Document related
* Promote/Demote chapter
* Promote/Demote level
(Do we need to structure the document from the navigation pane? And there would be the context menu too.)
* Header/Footer
* Anchor-Text
* Previous/Next page
* Page number
(Just one click away in the document)

Navigator related
* Content view
* Heading levels

Unclear to me
* List box on/off
* Toggle
* Navigation (looks like a menu button but isn't)
* Drag mode
Comment 6 Cor Nouws 2015-02-23 09:44:40 UTC
(In reply to Jay Philips from comment #3)
> Hi Cor,
> 
> So glad you got to see this one. :D
> 
> (In reply to Cor Nouws from comment #1)
> > The only reason I could think of, is that when browsing through the
> > document, you don't need to leave the Navigator - all is there.
> 
> Yes i thought that might be a reason but noticed that the buttons do nothing
> if you are on a page with no header or footer and also that headers and
> footers dont change that frequently in a document, so there isnt a need to
> jump to them that often.

Depend on how the feature Navigator is defined?
I would not miss it, but find it heard to speak for others in such a case..

> By the way, i couldnt understand what the buttons labeled toggle, 

The the Navigator is floating, that shows/hides the content.

> drag mode,

You can drag to paste/link parts from one document to another and within the document. That offers the choice copy/link/...

> set reminder,

temporary bookmark. You can have 5 IIRC. Can via the Navigation button choose to jump to those. 

> anchor<->text.

Jump between foot/end notes and the marker in the text.

(See the Help for all those, I guess?)
Comment 7 Cor Nouws 2015-02-23 09:48:54 UTC
(In reply to Heiko Tietze from comment #5)
> Your proposal is much better but has still a lot of controls in the header.
> Why not restrict it to functions that tweak the view below and not the
> document.

So a distinct position for controls that are to tweak the Navigator and those for actions on the content/document.. OK

> (Do we need to structure the document from the navigation pane? And there
> would be the context menu too.)

See all the many duplicates asking for the Word Outline view.
Manipulating with the Navigator is close to that, so must be as easy as possible to use and well visible.
Comment 8 Cor Nouws 2015-02-23 09:49:22 UTC
(In reply to Jay Philips from comment #4)
> Created attachment 113613 [details]
> first mockup
> 
> Was messing around with the reorganization and here is the first mockup.

Missing the controls there that you didn't know the working of ;)
Comment 9 Yousuf Philips (jay) (retired) 2015-02-23 16:25:59 UTC
(In reply to Heiko Tietze from comment #5)
> Your proposal is much better but has still a lot of controls in the header.
> Why not restrict it to functions that tweak the view below and not the
> document.

Well the mockup has the main three parts in it - the navigation controls so you can jump up and down between various objects, the page number controls, and the headers manipulation controls.

> Unclear to me
> * List box on/off
> * Toggle
> * Navigation (looks like a menu button but isn't)
> * Drag mode

Listbox can be removed as its only usable in the floating window. toogle can likely be removed as its always disabled for me. navigation is already integrated in the mockup and drag mode can be removed as its available in the context menu.

(In reply to Cor Nouws from comment #6)
> The the Navigator is floating, that shows/hides the content.

The 'Listbox On/Off' is what shows/hides the content when its floating, the 'Toggle' button is always dimmed no matter what i do.

> You can drag to paste/link parts from one document to another and within the
> document. That offers the choice copy/link/...

Interesting idea. :D

> temporary bookmark. You can have 5 IIRC. Can via the Navigation button
> choose to jump to those. 

Another interesting idea. :D

> > anchor<->text.

As you have to interact with the document in order to do this, how is this slower than just clicking the foot/end note number?

(In reply to Cor Nouws from comment #8)
> Missing the controls there that you didn't know the working of ;)

Had to start with the ones i understood first and add the others. :D
Comment 10 Yousuf Philips (jay) (retired) 2015-02-23 16:31:41 UTC
Created attachment 113625 [details]
second mockup

So taking into consideration what Cor had explained about the buttons missing from my last mockup, i've inserted the ones that i felt were important, which was just one - reminder.

Drag mode and shown outline levels are available in the context menu, so there isnt a need for them taking up space in the toolbar. The display context submenu should be removed as there is a combobox with its features at the bottom of the list.

The mockup lines up quite well on both rows, so if we want to add the toggle and anchor<->text it still can be aligned.
Comment 11 Cor Nouws 2015-02-23 19:37:15 UTC
(In reply to Jay Philips from comment #9)

> Listbox can be removed as its only usable in the floating window. 

So different Navigator inside and outside the Side bar ?

> toogle can likely be removed as its always disabled for me.

Ah, that one is a must when working with Master documents.
See the Help - I guess.

> and drag mode can be removed as its available in the context menu.

I think that's OK, since dragging itself also asks for mouse using on the heading labels.

> The 'Listbox On/Off' is what shows/hides the content when its floating, the
> 'Toggle' button is always dimmed no matter what i do.

See - see my comment before.

> As you have to interact with the document in order to do this, how is this
> slower than just clicking the foot/end note number?

The Navigator offers an overview and access to all various elements in the document.

> (In reply to Cor Nouws from comment #8)
> > Missing the controls there that you didn't know the working of ;)
> 
> Had to start with the ones i understood first and add the others. :D
Comment 12 Cor Nouws 2015-02-23 19:55:59 UTC
(In reply to Jay Philips from comment #10)
> Created attachment 113625 [details]
> second mockup

What is the Navigator icon for, top left, in front of the list?
What is the document icon for, top close to right, in front of the page nr?

I'm lost on the use of the combined buttons on row #2. |< <  number > >| ..

The reminder icon is bottom right. Since navigating to the various reminders is with the arrows on row #1, a position near there, is possible, would feel more natural.

> So taking into consideration what Cor had explained about the buttons
> missing from my last mockup, i've inserted the ones that i felt were
> important, which was just one - reminder.

Indeed, toggle is needed.

> Drag mode and shown outline levels are available in the context menu, so
> there isnt a need for them taking up space in the toolbar. 

There are so many things in the tool bars that are in context menu's too :) But in this case, it's a natural place, related to handling the very headings where the context menu is.

> The display context submenu should be removed as there is a combobox 
> with its features at the bottom of the list.

Mwah.. It's faster access there, when you are mousing. But OK, not a big deal - used not that often after all ;)

> The mockup lines up quite well on both rows, so if we want to add the toggle
> and anchor<->text it still can be aligned.

Yes, I'd appreciate those two.

Cheers - Cor
Comment 13 Cor Nouws 2015-02-23 20:00:57 UTC
NB While working on the Navigator: a control to dock/float would be really appreciated :)
Comment 14 Yousuf Philips (jay) (retired) 2015-02-24 01:20:28 UTC
(In reply to Cor Nouws from comment #11)
> So different Navigator inside and outside the Side bar ?

Well if we believe users are using the floating navigator with the contents hidden, then i guess the two will have to be different.

> Ah, that one is a must when working with Master documents.
> See the Help - I guess.

Well i guess it can be kept in that scenario.

(In reply to Cor Nouws from comment #12)
> What is the Navigator icon for, top left, in front of the list?
> What is the document icon for, top close to right, in front of the page nr?

The mockup states "These are just image labels". :D

> I'm lost on the use of the combined buttons on row #2. |< <  number > >| ..

|< - promotes level to 1
< - promotes level
number - sets the level
> - demotes level
>| - demotes level to 10

> The reminder icon is bottom right. Since navigating to the various reminders
> is with the arrows on row #1, a position near there, is possible, would feel
> more natural.

Totally agree with you, if there was sufficient space to place it in without having one row much larger than the second and also i'm keeping the icons on the right for less used features.

> Mwah.. It's faster access there, when you are mousing. But OK, not a big
> deal - used not that often after all ;)

Just trying to clear clutter in the context menu. :D

> Yes, I'd appreciate those two.

Any preference on which one should go on which row?
Comment 15 Björn Michaelsen 2015-10-29 19:48:13 UTC
(In reply to Yousuf (Jay) Philips from comment #0)
> 5) Content View - This view is very useful for people wanting an outline
> view, like which is found in MS Word, and clears out other navigator
> categories from view, so it would be beneficial to highlight the two
> navigator views, even if its just a text label.

So, in the sidebar Navigator and Navigator in Content View might be two individual decks, instead of mangling everything into one view.


Another pet peeve of mine is that View->Navigator (F5) opens a floating navigator. I would prefer it to open/selecting the navigator in the sidebar. To get the floating navigator for the few expert on this planet that actually want to use navigator and another sidebar deck (e.g. properties) at the same time, I'd like to actually add a "pop out navigator" button like the "more options" buttons on the sidebar. The click paths then would be:
- average user: View->Navigator opens the sidebar
- expert user: F5 open the sidebar at navigator deck, pushes "pop out navigator" button, gets a floating navigator in addition to the sidebar.
Comment 16 Cor Nouws 2015-10-29 20:27:17 UTC
(In reply to Björn Michaelsen from comment #15)

> Another pet peeve of mine is that View->Navigator (F5) opens a floating
> navigator. I would prefer it to open/selecting the navigator in the sidebar.
> To get the floating navigator for the few expert on this planet that
> actually want to use navigator and another sidebar deck (e.g. properties) at
> the same time, I'd like to actually add a "pop out navigator" button like
> the "more options" buttons on the sidebar. The click paths then would be:
> - average user: View->Navigator opens the sidebar
> - expert user: F5 open the sidebar at navigator deck, pushes "pop out
> navigator" button, gets a floating navigator in addition to the sidebar.

Please don't.
That would force all those experts to use the mouse.
Unless people agree that in all modules Ctrl+Shft+F5 or Ctrl+F5 is used.
(In writer  Ctrl+Shft+F5 puts focus in Page field in Navigator ...)
Comment 17 Björn Michaelsen 2015-10-30 16:58:38 UTC
(In reply to Cor Nouws from comment #16)
> (In reply to Björn Michaelsen from comment #15)
> That would force all those experts to use the mouse.

Arent they anyway? I would be very surprised, if even the most expert users:
a/ do not often need to reposition the navigator window because it pops up in the wrong place with the wrong size[1]
b/ anyone navigating the _contents_ of the navigator with anything but the mouse anyway.

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=35256
Comment 18 Björn Michaelsen 2015-10-30 17:01:18 UTC
@Jay: Just wondering, have you considered a three-row layout for the top bar?

The content in the navigator toolbar is quite squeezed, stemming from the low-res display of the 1990ies. We might afford using a little more screenspace for it.
Comment 19 Yousuf Philips (jay) (retired) 2015-10-30 23:18:33 UTC
(In reply to Björn Michaelsen from comment #15)
> So, in the sidebar Navigator and Navigator in Content View might be two
> individual decks, instead of mangling everything into one view.

If we created a new Outline deck and moved the heading management functionality from the navigator deck into it, i think that would be a great thing to do and would also bring more attention to the functionality that is hidden by default.

> Another pet peeve of mine is that View->Navigator (F5) opens a floating
> navigator. I would prefer it to open/selecting the navigator in the sidebar.
> To get the floating navigator for the few expert on this planet that
> actually want to use navigator and another sidebar deck (e.g. properties) at
> the same time, I'd like to actually add a "pop out navigator" button like
> the "more options" buttons on the sidebar. The click paths then would be:
> - average user: View->Navigator opens the sidebar
> - expert user: F5 open the sidebar at navigator deck, pushes "pop out
> navigator" button, gets a floating navigator in addition to the sidebar.

The debate about making navigator exclusive to the sidebar went on in bug 73151.

When it comes to an average user, they wouldnt likely touch the menubar, especially when the sidebar has a navigator button always visible. When it comes to View -> Navigator, it should likely activate the sidebar as all sidebar entries are placed together in the View menu. When it comes to F5, it should be maintained for the floating window, as shortcut keys are primarily used by experts.

(In reply to Björn Michaelsen from comment #18)
> @Jay: Just wondering, have you considered a three-row layout for the top bar?

I considered it but that would reduce the available space to view the navigator on smaller screens. One option is to hide the heading/outline management buttons until you are in content view or alternatively have the outline deck.
Comment 20 Björn Michaelsen 2015-10-31 04:23:21 UTC
(In reply to Yousuf (Jay) Philips from comment #19)
> The debate about making navigator exclusive to the sidebar went on in bug
> 73151. 
> When it comes to an average user, they wouldnt likely touch the menubar,
> especially when the sidebar has a navigator button always visible. When it
> comes to View -> Navigator, it should likely activate the sidebar as all
> sidebar entries are placed together in the View menu. When it comes to F5,
> it should be maintained for the floating window, as shortcut keys are
> primarily used by experts.

Changing the menu default to open the sidebar, and while keeping F5 open the floating navigator sounds great to me. Its certainly an improvement over what we have now. However, having some functionality (floating navigator) accessible _only_ via shortcut seems suboptimal. I wondered if the navigator image label that you have on the second mockup could be a button that opens the floating navigator?

> I considered it but that would reduce the available space to view the
> navigator on smaller screens. One option is to hide the heading/outline
> management buttons until you are in content view or alternatively have the
> outline deck.

Ok. Actually, the more I look at the 2nd mockup, the more I like it. ;)
Comment 21 Yousuf Philips (jay) (retired) 2015-10-31 05:01:26 UTC
(In reply to Björn Michaelsen from comment #20)
> Changing the menu default to open the sidebar, and while keeping F5 open the
> floating navigator sounds great to me. Its certainly an improvement over
> what we have now. However, having some functionality (floating navigator)
> accessible _only_ via shortcut seems suboptimal. I wondered if the navigator
> image label that you have on the second mockup could be a button that opens
> the floating navigator?

The floating navigator is only beneficial in writer from what i can see, so it should likely be eliminate from all other modules. As F5 would be used in all other modules to open navigator in the sidebar, that should be how it works in writer, and we assign a different uno command and shortcut key for the floating navigator and place its entry in writer's tools menu.

> Ok. Actually, the more I look at the 2nd mockup, the more I like it. ;)

Yes after struggling with understanding how navigator works, i tried to simplify it so hopefully average users wont feel so intimated by it, like i did when i first opened it. One of the main things was to eliminate the navigation window and use the same drop down menu control in the Find toolbar instead of the 'Navigate by' entry.
Comment 22 Cor Nouws 2015-11-01 19:52:10 UTC
(In reply to Björn Michaelsen from comment #17)
> (In reply to Cor Nouws from comment #16)
> > (In reply to Björn Michaelsen from comment #15)
> > That would force all those experts to use the mouse.
> 
> Arent they anyway? I would be very surprised, if even the most expert users:
> a/ do not often need to reposition the navigator window because it pops up
> in the wrong place with the wrong size[1]
> b/ anyone navigating the _contents_ of the navigator with anything but the
> mouse anyway.
> 
> [1] https://bugs.documentfoundation.org/show_bug.cgi?id=35256

I hit F5. Navigator opens docked at left side. (It has been decided previously to keep Navigator separated too, for the people that have both panels open).
(And if it's not yet docked, hit Ctrl+Shft+F10)

I simply use arrows or the starting letter to jump to a heading. Enter to go there. Or one can use Shft+F10 or the properties key for the context menu.

Why don't you simply accept it from me that it's a PITA to be forced to use the mouse if you prefer not to do?
Comment 23 Cor Nouws 2015-11-01 19:56:47 UTC
People use the mouse may hit an Icon or enter the menu. Use that to open the Navigator in the side bar.
Let F5 stick to the separate Navigator.
Maybe (that's another issue) have a stripped down simple version of the Navigator in the side bar. And the full powered one in the separate version?
Then with a widget top right in the stripped version to allow people to find the other one?
Comment 24 Cor Nouws 2015-11-01 20:01:42 UTC
I get the unpleasant feeling that there are discussions about the short cut in use/to use for the Navigator in several issues :)
Or is there one issue for that? Would have the advantage that we can relatively easily collect input from involved users.
Comment 25 Björn Michaelsen 2015-11-03 23:13:39 UTC
(In reply to Cor Nouws from comment #22)
> I hit F5. I simply use arrows or the starting letter to jump to a heading.
> Enter to go there. 

And you do a double F5 to close and reopen the navigator again for getting the focus back into the navigator?

> And the full powered one in the separate version?
> Then with a widget top right in the stripped version to allow people to find the other one?

Yeah, thats mostly what I was suggesting in comment 15.
Comment 26 Cor Nouws 2015-11-10 13:44:36 UTC
(In reply to Björn Michaelsen from comment #25)
> (In reply to Cor Nouws from comment #22)

> And you do a double F5 to close and reopen the navigator again for getting
> the focus back into the navigator?

Yep - for that use case definitely.
I'm not saying or pretending that I never use the mouse (only speaking for myself of course). But any case that does not need the mouse, is a win ;)

> > And the full powered one in the separate version?
> > Then with a widget top right in the stripped version to allow people to find the other one?
> 
> Yeah, thats mostly what I was suggesting in comment 15.

Ah nice.
I thought about maybe Shft+F5 for the full Navigator, but that already has function in Writer, Calc and Impress..

Did I suggest somewhere (@jay: do you still have oversight :) ?) to have a View > Navigator Full and a > Navigator Simple ?
Comment 27 Robinson Tryon (qubit) 2015-12-13 11:24:11 UTC Comment hidden (obsolete)
Comment 28 Yousuf Philips (jay) (retired) 2016-02-02 14:15:29 UTC
@Samuel: You removed 'needsDevEval, topicUI' from the keywords field but didnt replace it with any alternative keywords. Was this intentional?
Comment 29 Samuel Mehrbrodt (allotropia) 2016-02-02 14:22:18 UTC
(In reply to Yousuf (Jay) Philips from comment #28)
> @Samuel: You removed 'needsDevEval, topicUI' from the keywords field but
> didnt replace it with any alternative keywords. Was this intentional?

Yes that was because I think this isn't suited as an EasyHack. The reason is that there are lots of tasks in this issue, too much for an EasyHack.

Sorry, should have given an explanation.
Comment 30 Samuel Mehrbrodt (allotropia) 2016-02-02 14:22:53 UTC
Does the topicUI field have any meaning without a needsDevEval/easyHack keyword?
Comment 31 Yousuf Philips (jay) (retired) 2016-02-03 09:33:05 UTC
(In reply to Samuel Mehrbrodt from comment #29)
> Yes that was because I think this isn't suited as an EasyHack. The reason is
> that there are lots of tasks in this issue, too much for an EasyHack.
> 
> Sorry, should have given an explanation.

I guess i was mistaken with the interpretation of needsDevEval, as i was assuming a dev would decide the level of difficulty and skill set needed to fix the enhancement. Atleast thats how i understood it from kendy when we decided to start including 'needsDevEval topicUI'.

(In reply to Samuel Mehrbrodt from comment #30)
> Does the topicUI field have any meaning without a needsDevEval/easyHack
> keyword?

The combo was used as a means of tracking down UI enhancements that the design team wanted design devs to evaluate.
Comment 32 Samuel Mehrbrodt (allotropia) 2016-02-03 10:04:35 UTC
(In reply to Yousuf (Jay) Philips from comment #31)
> I guess i was mistaken with the interpretation of needsDevEval, as i was
> assuming a dev would decide the level of difficulty and skill set needed to
> fix the enhancement. Atleast thats how i understood it from kendy when we
> decided to start including 'needsDevEval topicUI'.

According to [1] needsDevEval is a replacement for ProposedEasyHack. See also. [2],

> (In reply to Samuel Mehrbrodt from comment #30)
> > Does the topicUI field have any meaning without a needsDevEval/easyHack
> > keyword?
> 
> The combo was used as a means of tracking down UI enhancements that the
> design team wanted design devs to evaluate.

Again, topicUI is a keyword for Easy Hacks. See [3].

[1] http://nabble.documentfoundation.org/Libreoffice-qa-ProposedEasyHack-Changed-to-NeedsDevEval-td4099431.html
[2] https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Keywords#needsDevEval
[3] https://wiki.documentfoundation.org/Development/Easy_Hacks/Bugzilla_Categorization#Topic
Comment 33 Heiko Tietze 2016-09-20 10:48:40 UTC
*** Bug 93872 has been marked as a duplicate of this bug. ***
Comment 34 Heiko Tietze 2016-09-20 10:50:09 UTC
*** Bug 93871 has been marked as a duplicate of this bug. ***
Comment 35 Xisco Faulí 2017-07-13 11:17:46 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 36 Jim Raykowski 2017-09-07 01:12:54 UTC
Hello all,

I have been working on implementing the ideas purposed here.

So far I have replaced the small navigator popup window button control with the new dropdown list control that is used in the Find toolbar. I tried using the uno scrolltonext/previous controls from the Find toolbar to replace the next/previous controls in the Navigator content toolbar but they didn't work, possibly due to not having a context to a document. 

The Document dropdown doesn't seem to always function as intended. I believe the idea is to be able to use any Navigator for any document?

Samuel Mehrbrodt asked for comments on possibly dropping this navigation stuff from the Navigator. https://bugs.documentfoundation.org/show_bug.cgi?id=79167#c38

Maybe it would be better to find a different bug to hack on?
Jim
Comment 37 Yousuf Philips (jay) (retired) 2017-09-08 14:12:20 UTC
(In reply to Jim Raykowski from comment #36)
> Samuel Mehrbrodt asked for comments on possibly dropping this navigation
> stuff from the Navigator.
> https://bugs.documentfoundation.org/show_bug.cgi?id=79167#c38

I would assume that the navigation stuff is a crucial part of navigator, as you are able to jump through elements of a particular type according to a document's order, which isnt possible within the tree view of the navigator, and a number of the elements in navigation (e.g. footnote, control) arent listed in the tree view.

@Cor, @Stuart, @Sophie: what is your take now that navigation is in the find toolbar?
Comment 38 Thomas Lendo 2017-09-08 18:24:19 UTC
I'm with Jay in comment 37. Navigator without navigation feature seems to be bizarre. The Find toolbar enhancement is nice but shouldn't result in reducing central features elsewhere.
Comment 39 Jim Raykowski 2017-09-09 01:57:25 UTC
I will continue working on this. The 'Navigate By' controls used in the Findbar are able to be used in the Navigator panel content toolbar. This has resulted in a fair amount of code reduction. Maybe this is a good place to do a commit before diving into the headings stuff that Yousuf has suggested in the mockups? I can post a screenshot for comments if that would be better at this point.
Comment 40 sophie 2017-09-11 09:01:58 UTC
(In reply to Yousuf Philips (jay) from comment #37)
> (In reply to Jim Raykowski from comment #36)
> > Samuel Mehrbrodt asked for comments on possibly dropping this navigation
> > stuff from the Navigator.
> > https://bugs.documentfoundation.org/show_bug.cgi?id=79167#c38
> 
> I would assume that the navigation stuff is a crucial part of navigator, as
> you are able to jump through elements of a particular type according to a
> document's order, which isnt possible within the tree view of the navigator,
> and a number of the elements in navigation (e.g. footnote, control) arent
> listed in the tree view.
> 
> @Cor, @Stuart, @Sophie: what is your take now that navigation is in the find
> toolbar?

Several elements are not present out of the Navigation bar and are needed, so I'll keep it as it is currently - Sophie
Comment 41 Jim Raykowski 2017-12-23 07:46:00 UTC
Created attachment 138606 [details]
navigator screenshot

Hi All,

Attached is a screenshot of what I have done for this. The first line follows Jays second mockup minus the image labels. The second line is a rearrangement of items presently available. The 'Navigate By' drop down and previous and next arrows are the same uno controls used in the Findbar. The 'Go To page' edit spin control is a new uno control created for use here. I committed it for review a while back to granulate. 

If there is interest in what is here I will commit.
Comment 42 Cor Nouws 2017-12-23 12:20:44 UTC
(In reply to Jim Raykowski from comment #41)

> Attached is a screenshot of what I have done for this. The first line

Hi Jim,
Looks nice and clean to me.
(I didn't read back all details of the discussion here, but it looks to me, that the same functionality is present. Correct?)
Thanks!
Cor
Comment 43 Jim Raykowski 2017-12-23 19:35:43 UTC
(In reply to Cor Nouws from comment #42)
> (I didn't read back all details of the discussion here, but it looks to me,
> that the same functionality is present. Correct?)
> Thanks!
> Cor

Yes the Navigator has the same fu
Comment 44 Yousuf Philips (jay) (retired) 2017-12-23 19:52:05 UTC
(In reply to Jim Raykowski from comment #41)
> If there is interest in what is here I will commit.

Go for it Jim, but move the 'drag mode' group button to the end of the second line and replace it with a separator. We'll deal with the removal of controls from the second line later.
Comment 45 Jim Raykowski 2017-12-24 03:40:49 UTC
Ok Jay, 'drag mode' group button moved to the end of the second line and replaced with a separator.

here is a link to the commit 
https://gerrit.libreoffice.org/#/c/47033/
Comment 46 Jim Raykowski 2020-01-18 06:50:33 UTC
Here is an updated version that only includes the navigation toolbox replacement and some code improvements:
https://gerrit.libreoffice.org/#/c/core/+/87005/
Comment 47 Commit Notification 2020-02-14 04:37:45 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/350bf42540ff810a142538c5fd8ec2a78d430091

tdf#89566 Replace navigation toolbox in Writer navigator

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 48 Mike 2020-06-15 20:01:42 UTC Comment hidden (off-topic)
Comment 49 Mike 2020-06-15 20:03:26 UTC Comment hidden (off-topic)