button to trigger the toggle-attributes-display menu

[lansingthomas]

Dear Cyber Pumpkins,
Please observe and consider this proposal.

Purpose
Creating a more accessible way for adding and subtracting attribute columns in a prompt buffer.

What is your proposed change?
[1] clickable button to open the toggle-attributes-display menu.

• A nice icon in the Source row -- perhaps a ± (U+00B1)
• INVISIBLE --> until users hover over aSource row
  • it will be nice to find the toggle-attributes-display menu when users are seeking it but not at other times
  • also this prevents people seeing the icon twice when two Sources are displayed

Rationale

• the toggle-attributes-display menu is hard to find and not immediately obvious in the documentation. Some commands apply in the prompt buffer and not elsewhere (in default CUA: the c-] input for new-url is the SAME as the c-] input for toggle-attributes-display menu. Users are expected to magically know this obscure keybinding from other programs.

• Users may not even know the nyxt-jargon "attributes" -- the only thing that might help them find this in the documentation.

• My view is that the toggle-attributes-display menu is a helpful feature IF users can find it. So lets help them find it!

Constraints
the purpose is to be helpful exactly when needed, so any solution MUST NOT have a big chunky icon that might confuse users. Small and discoverable is better than big and loud.

Additional context/User story
users will be trying to remove excess information from a prompt buffer, or bring back a column after they understand it, or are ready to process that information.

Screenshots/Mock ups

Pre-Build Checklist:

@jmercouris @aadcg @aartaka

• I have consulted with the team. {}
• One or more developers have signed off on this change. {}
• One or more user researchers have signed off on this change. {self}

Thank you!

[aadcg]

Sounds sensible to me. I believe the only changes needed would be to move the button to the right and to make it visible exclusively on hover. Is this accurate @jmercouris? You worked on this not long ago.

[aartaka]

Let's actually move all of those to the right.

[lansingthomas]

Moving the [accordion navigation element] to the right along with the [toggle-attribute-display menu ±] could be a very nice choice -- the arrows currently do not meet the proposed specifications, specifically, they do not communicate system status {open, closed}.

In my view, having two icons is not the best solution, it is a solution. But not the best.

John mentioned some difficulties with having a single icon that changes to reflect the systems status {open, closed}. My secret hope is that he will solve this problem with his computer. : )
Using ⏷ OR ⏵ to communicate system status will be so much more clear for our guests.

I would love to see something like this (the accordion element under the heading Open Multiple)

IF we place the navigation element on the right, we should move the toggle-attribute-display menu ± just left of it.

[aadcg]

Do we agree to move these buttons to the right?

[aartaka]

Yes, no hurt in moving them to the right I guess.

[aadcg]

Anyone eager to take it? Assign it to yourself, if that's the case. Thanks.

[aartaka]

Have fun :)

[lansingthomas]

I'm glad this is still open.
Let me do some mock ups for the button(s).

[lansingthomas]

this is the perfect test for me while we sort out colors for pseudo-classes.

[aadcg]

I thought this was ready for development. Are you going to specify a new button location @lansingthomas?

[lansingthomas]

@aadcg Yeah sorry, the location will probably stay the same. But I want to experiment with button styles and at least do a rough mock-up to help avoid confusion.

I do not see anyone assigned to this one yet. IF anyone has started work on this let me know and we can collaborate.

[aadcg]

I haven't, and can't commit to this at the moment.

[aadcg]

Related to #3139. Would be a good idea to kill two rabbits with one stone. CC @jmercouris.

[lansingthomas]

Okay, the plan has evolved.

[1] I want to change the location slightly

• to group the button with the columns it acts upon.

[2] here are some icons to choose from

• let's choose h.
• the other ones are too visible for such a small thing.

[3] I want to keep the button visible, just changing a small square of background behind the icon for hover state

• maintain discoverability, without standing out too much)

default state

hovered state

just change a square of background behind the icon to primary+ #474747

pressed state

change that same bg square to secondary #A6A6A6 for a nice flash of light gray

cool?

• @jmercouris
• @aadcg

[aadcg]

I think that the button must be placed on the bar above. The way you have specified it, the button is being displayed in the place designated for the attributes/columns titles.

Just like source navigation buttons are located at the source header bar, the button that set the visible attributes semantically belongs there.

[lansingthomas]

I think that the button must be placed on the bar above. ...

I'm sold.
A video of John told me he is fine with it as well.

Yay!

Default state:

Icon - text colored - #OCOCOD
bg - secondary colored - #A6A6A6

Hovered state:

Icon - text colored - #OCOCOD
bg - secondary+ colored - #BFBFBF

[lansingthomas]

No need for a pressed state -- the prompt buffer changes quickly enough I think we can skip it.

[lansingthomas]

This one looks ready to me :D

[aadcg]

@hgluka please address this issue in #3202 too. It's trivial.