Hide/Disable "Back" and "Forward"

[GWRon]

There a menu "help" containing "Back" and "Forward". They are there to move within the help tab. Same for the two icons "back" and "forward" in the toolbar.

I think these icons should be either disabled or hidden when not in the "Help"-tab.

Also I am not really liking the symbols used for it (and also the "Home" icon). Why?

• these arrows look like "undo / redo" symbols (as known from other editors)
• these arrows have "back" and "forward" tooltips - so I thought they navigate in the tabber (previous/next tab)

So what would I suggest:

• choose/create other symbols for back/forward within the "help tab"
• only display them when "help tab" is active (and deactivate/activate them if there is a back/forward available)
• add "undo / redo" symbols (and deactivate/activate them if there is undo/redo available or not)

Alternatively to the navigation symbols in the help: add a breadcrumb navigation header-area in the help files Home > Module Reference > Audio > BRL.Audio

I would of course prefer this as it is way more common than a "back" and "forward" button in the toolbar. Also it eases navigation (as you can move backwards more steps with one click). You could still have the "help"-menu entries to navigate that way .... but you should have a better label there ("Previous Help Page" and "Next Help Page").

What do you think?

[GWRon]

If the "back" and "forward" toolbar icons for "help" are to vanish and there is only "home" left, I would move it to the most left - as a "home" always belongs to there ;-) and it resembles that the "F1" key is on the left side of your keyboard too

[woollybah]

I don't think toolbars should add/remove items on-the-fly. I think that's bad UX. Stuff should be disabled if you don't want someone to click on it. Adding/Removing things just makes a toolbar confusing and not predictable - i.e. I move my mouse to the same position every time to click on such-and-such - except that it moves to the left or right sometimes?

[GWRon]

That's right - and if done like I suggested (breadcrumbs and no "help back/forward symbols at all") it wouldn't be needed at all. Redo/undo could be simply disabled if not applicable.

I only suggested the "show/remove" of these icons to help the user to find out "ahh, they are for navigating in the help" (as they are only visible there).

[GWRon]

What I could suggest too: For now "alt + left/right" are used to navigate between tabs of the notebook/tabber. (or even "ctrl + left/right" if you did not enable "use OS shortcuts" - with "ctrl + left/right" being default keys to move a cursor "per word").

Users today are used to (Web-)Browsers. In such a browser "alt left/right" is used to browse in a tabs history. So in the help page this means: "back" and "forward".

To navigate between tabs of a notebook it is common to use "ctrl + tab" for "next" and "ctrl + shift + tab" for previous tab in the notebook (so not "last used" but "previous in order"). Maybe on the mac the shortcuts differ (command key instead of "ctrl").

So I would even suggest to use standard shortcuts here too.

This means I would also propose to get rid of this "use OS keys" thing at all - and to use whatever is used everywhere else on the specific platforms (I mean... "Command + S" on Windows to save? seriously?)

[GWRon]

So I ask you (@woollybah): What keys are used (in Mac OS) to:

• navigate in a browser tab (go to previous page/next page loaded in this very same tab)
• go to the previous/next tab (browser, multi-document editors ...)
• use shortcuts of menus (I assume "command" / apple key ?)

We could use this to make MaxIDE more conform to standard keyboard conventions.

Notepad++ (and maybe others) use "ctrl tab" to open up a list of the opened tabs and each hit scrolls to the next item. The previously selected one is added to the top - so a "ctrl + tab" moves to the previously selected one - keep "tabbing" to select later ones. The "browser behaviour" is achieved by "ctrl + pgUp/pgDown". It is pretty often that you want to switch between two documents ... so a similar behaviour might be "standard" in IDEs ?! I know that it is done similar in Geany and Visual Studio too.

[woollybah]

There is an Option to use "native" navigation or something like that. This affects skipping over words and changing tabs. Generally this swaps between using alt-arrow and ctrl-arrow for navigations. It also allows one to use the "same" navigation on different platforms, where one platform standard might expect to use ctrl-arrow to switch tabs, whilst another use alt-arrow to switch tabs. I tend to align mine so I have the same keys across platforms.

So, you shouldn't change this :-) Or else you add a further option ... "enable 3rd navigation keys", that I can disable.

[woollybah]

I don't think it's worth making large changes to MaxIDE, because time could be better spent on other more useful things related to NG.

You might mention, "but introducing scintilla to MaxIDE was a large change", and although I agree, it was also a MaxGUI change to introduce an insanely better text area widget. (which yes, I still need to integrate on macOS).

[GWRon]

Ok, so it is used to keep navigation the same across platforms.

We could hmm ... have a dropdown to use "OS X shortcuts", "Windows shortcuts", ... so we could pretty much define all shortcuts individually instead of just changing two different "mod keys".

I understand that there are other more important things (especially for you) but at least this is something I could help with - and it's not as boring as writing documentation ;-)

[woollybah]

Nothing is as boring as writing documentation...

[GWRon]

Also you must not forget: for developing some business stuff I have to work with MaxIDE - and it's inconsistency regarding shortcuts compared to other tools ... is a little productivity killer ;-) You know ... "how was the type named? it's in the tab I used as last... just need to switch to it for a short look and switch back in a blink"

As "Ctrl + Tab" is not used for now ... I could at least add this - without influencing your "used to" controls.