special case UI for mode specific commands

[lansingthomas]

special case UI for mode specific commands

[aadcg]

I think this is rather important and, personally, I'd go with 1 but the bar should be placed at the top. What made you place it at the bottom?

[aadcg]

I don't think that Nano is a good model since we have a prompt buffer that is being raised constantly. The bar of controls needs to be visible at all times, which means that it would have to jump constantly.

Also, it's seems reasonable that a fixed-positon bar of controls is placed in one of the 4 extreme ends of the UI.

[lansingthomas]

special function UI - Specification

structure of the special function UI

special function UI MUST:

• clearly display the presence of mode specific functions (to improve discoverability)
• only be present for the special modes pages {editor mode, REPL, etc.}

special function UI SHOULD:

• clearly connect the special functions to the associated active mode (so that users understand the impermanence of these commands)
• clearly communicate the name of the special commands (so that users understand the similarity to typical commands)
• clearly communicate the keybinding for each command (or absence of a keybinding, so that users understand that they could set their own binding)

special function UI COULD:

• be collapsable

[lansingthomas]

Having the special command UI at the top is certainly worth consideration.

My initial reasoning FOR placing the bar at the bottom was that

• grouping with other actionable elements (prompt buffer, status bar) seems sensible
• it looks like Nano, which has a nice familiar (to our users hopefully) TUI feel to it.

My initial reasoning FOR NOT placing the bar at the top

• the stacked stack of top bars is already full of information related to other systems
  • notice how other browsers have a hover behavior to show/hide top bars from window mangers and operating systems, top bars really start to stack up
  • chrome has three top bars (then FIVE when you hover over them). The way that this works visually is that they have no bottom bar at all, so there are two clear visual panes [1] for infinite top bars, and [2] for main-buffer. As Nyxt has a Status bar and a Message bar we have already broken this two pane structure, so let's use the space we have already claimed.

---

Lets give the top bar the consideration it deserves!

Possible form 4:

I could advocate FOR a top bar with these arguments:

• We don't need to worry about top bars coming in from web-buffers (as this UI would only be for certain pages, we can expect the new bar to be top bar no.3 or 4 depending on people's systems)
• This UI would show up when opening a REPL cell, and when editing with the internal-text-editor → people are habituated to using top bars for text editor controls in other apps.

[lansingthomas]

Okay Im sold on top menu: (form 4)

1. top bar satisfies the proposed spec 100%
2. top bar preserves both vertical symmetry and horizontal space for the main working space.
3. top menu take up a lot less space overall
4. The next best alternative (side bar) has one advantage -- but it doesn't quite apply
   • advantage of a side menu is scalability as more special-mode-only-commands are added (and we are not there yet)
   • when we do get there we can use submenus in the top bar for smaller displays.

[aadcg]

I'd have choosen the side bar if these buttons would be icons and wouldn't extend lengh-wise (due to the text next to buttons). It is more severe to occupy 10% of the width than 10% of the height when the main task at hand is text-based. Other criteria would apply for UIs dealing with graphics, etc.