Rethink prompt buffer UI

[aadcg]

When users invoke the prompt buffer, the suggestions are their main focus.

• Problem 1

Between the input area and the suggestions, (in the most general case) there are two headers that draw the users' attention.

In other words, the suggestions start at the 4th line of the prompt buffer's UI. Given that it's the main focus, it takes some time to understand that those are the spotlight.

Obviously, the first line (input area) needs to be there.

Input Area
Source Header
  Source Attributes Header
  Suggestion 1
  Suggestion 2
  ...
  Suggestion N

Notice that the indentation between Source Header and Source Attributes Header hints at the fact that those Suggestions are part of that Source.

• Problem 2

When looking at the Source Header, it's not obvious that its content refers to source names.

• Problem 3 (reported by @lansingthomas)

The interaction:

1. is not consistent with the expectation users bring from other apps;
2. does not have a visible status;
3. causes errors in other places when users type things in random websites intending to type in the Prompter of our Prompt Area.

[aadcg]

@lansingthomas, any preliminary comment?

[lansingthomas]

Problem 1 - too many lines before relevant information

• perhaps we could rename the name field commands and still communicate the same information. --> this enables us to remove the whole commands line. See example image. I have also changed the background gray of the column titles (which might cause issues elsewhere).

Problem 2 - I do not understand this yet. Let's talk about it over voice.

[aadcg]

@lansingthomas you already helped. Ignore the rest of this discussion (you don't have enough background to follow it yet).

I was going to say that @lansingthomas's idea doesn't make much sense since he didn't understand the difference between sources and its attributes. But actually his observation is spot on. Why can't we have the first source attribute (the first column in prompt buffer) coincide with the source name? Is there a counter example in our codebase?

CC @aartaka.

[aadcg]

Actually we can't do this. set-url-new-buffer serves as a counter example.

Well, we actually can. With some attribute renaming.

[aartaka]

@lansingthomas you already helped. Ignore the rest of this discussion (you don't have enough background to follow it yet).

It might still be related to Thomas' expertize, let'd not exclude him :P

Some terms so that we're on the same page:

• Source is a set of things you can select from, most likely coming from the same... ehm, source. Like the information one has might come from books, academic papers, personal communication, news. All those are separate sources with their special properties and the ways information from those is different from each other.
• Suggestion is an atomic thing, piece of information. Like a quote you remember from a book.
• Attribute is a certain, likely source-specific, property of a certain suggestion. Like the page or a book that you read a quote on.

I was going to say that @lansingthomas's idea doesn't make much sense since he didn't understand the difference between sources and its attributes. But actually his observation is spot on. Why can't we have the first source attribute (the first column in prompt buffer) coincide with the source name? Is there a counter example in our codebase?

We cannot, I'm guessing. Sources and their attributes are totally separate semantically, and should not be conflated unless we are willing to confuse the person using them. It's often the case that source name conicides with the first attribute name, but that's mostly because we tend to collect things into sources based a certain identity grouping that manifests itself both in source name and default/first attribute name. It's more than intuitive that if you collect books you'd have source named "Books" and the first attribute being simply "Book" or "Name".

So what we need it not hierarchy collapse, what we need is hierarchy highlighting. Like "This is a set of books, they belong to the same place, and here are individual books with their specific propreties" as an interface-induced takeaway. We can use some background that unites all of the suggestions for a source, and some visible nesting (instead of almost-invisible indentation) so that sources' names and attributes make much more sense.

Or we can have a good descriptive text for those and forget about tweaking interface in the places where only a good text could explaing things.

[aadcg]

So what we need it not hierarchy collapse, what we need is hierarchy highlighting.

I agree with everything you say, but that doesn't seem to bring us any closer to de-cluttering the prompt buffer UI.

Perhaps you think that Problem 1 is not a problem?

[aartaka]

Perhaps you think that Problem 1 is not a problem?

Indeed, I don't see it as a problem.

[aadcg]

@lansingthomas after our session yesterday, you should be able to follow this discussion from top to bottom.

I've assigned you to this issue since you're iterating on a new specification for the prompt buffer.

[lansingthomas]

The form of the prompt buffer (prompt area) is evolving. Let's try to take out the easy stuff first -- one at a time.

Some issues related to this:

• Removing Excess Icon - from: prompt-buffer/source-heading #2751
• Affordance of position in buffer tree #2752

[lansingthomas]

Proposal for a UI enhancement

these few changes to the prompt buffer will:

1. add clickable exit functionality
2. visually connect the status bar and the input buffer area.

this image displays the destination

this image highlights the changes

how we got here

• clickable exit is a reasonable expectation, so lets provide it.
  • John and Thomas talked through a number of mock ups, exploring other shapes/forms and seeking to build on what exists (rather than rebuild)
  • This edition is minimal and Nyxty
  • further UI changes are in process (including modes and other status bar elements) -- the changes here accommodate the upcoming changes.
  • the chamfer and side bar
  • the idea is that these tweaks will visually connect the status bar with the input buffer area.
  • These two elements have many tasks in common, like organizing suggestions, so we should connect them visually to communicate that connection.

specifications for the elements

clickable exit shape

• the ASCII 158x does not stand out -- this element should not stand out.
• It's position in the top right connects with typical user expectations.
• the chevron looks cool : )
• the chevron shape should change color on hover to visually afford that the element is an interaction
• like this

chamfer and bar along the right side

• thin bar (we looked at some thicker bars and they look too chunky)
• 45 degree chamfer

@aadcg @aartaka

Are you good with clickable exit?

Are you good with side bar & chamfer?

Are we clear about the changes?

• let me know if the images above are not sufficient fidelity. I'm happy to elaborate but I think you guys get the idea here.

[aadcg]

All great ideas in my view @lansingthomas!

[Ambrevar]

All good on my end!

[lansingthomas]

Nice! We are aligned!

Now who wants to tackle this one?

[aartaka]

@lansingthomas, sorry for the late reply. I have two complains here:

• First, the area you're suggesting putting this X into is already used to list modes enabled in prompt buffer. Adding to or replacing those will likely be quite confusing.
• Why two options at the same time? Either of those is clear enough and should be mostly sufficient as the way to close prompt buffer.

[aadcg]

First, the area you're suggesting putting this X into is already used to list modes enabled in prompt buffer. Adding to or replacing those will likely be quite confusing.

Notice that @lansingthomas said:

further UI changes are in process (including modes and other status bar elements) -- the changes here accommodate the upcoming changes.

In my understanding, he and @jmercouris are re-thinking the way modes are displayed in the prompt buffer. Later, there will be further instructions on how to handle them.

I don't know what are their plans on that but, personally, I think that the modes enabled in the prompt buffer should be displayed in a radical different way than we do now.

Why two options at the same time? Either of those is clear enough and should be mostly sufficient as the way to close prompt buffer.

Do you mean that there would be a keyboard and mouse based way to close the prompt buffer? In my understanding that's exactly the goal: provide an additional and intuitive (mouse-based) way to close the prompt buffer.

[aartaka]

Why two options at the same time? Either of those is clear enough and should be mostly sufficient as the way to close prompt buffer.

Do you mean that there would be a keyboard and mouse based way to close the prompt buffer? In my understanding that's exactly the goal: provide an additional and intuitive (mouse-based) way to close the prompt buffer.

No, what I meant is that there's too much mouse-based ways: the cross and the chevron, both doing the same thing. It feels redundant. I don't understand why we need both of those.

[aadcg]

No, what I meant is that there's too much mouse-based ways: the cross and the chevron, both doing the same thing. It feels redundant. I don't understand why we need both of those.

I didn't interpret the proposed changes like that. The cross is displayed inside the chevron, but that's a single close button. @lansingthomas is my understanding accurate?

[aartaka]

Ah chevron/chamfer, I confused those （*/∇＼*）

I mean, why we need this-area-with-a-cross-on-the-top-of-prompt-buffer and this-small-triangle-in-the-bottom-right-corner, if they are doing the same thing?

[aadcg]

I mean, why we need this-area-with-a-cross-on-the-top-of-prompt-buffer and this-small-triangle-in-the-bottom-right-corner, if they are doing the same thing?

I don't think they are doing the same thing, and I'd suggest going through @lansingthomas' proposal again!

The cross embedded in the chevron is a button to close the prompt buffer. The small triangle + the thin line on the right are aesthetical details that communicate continuity between the status buffer and the input area (I'm just rephrasing @lansingthomas' specification).

[lansingthomas]

Yes, can confirm -- the hover-able area behind the X (within the chevron) should be the clickable exit.

[lansingthomas]

update: @aartaka and I started to speak on video today but connection issues prevented meaningful exchange.

Why the chamfer you ask?

• the edge line and chamfer together communicates that the clickable exit is functional for the entire pop-up (not just the input area)
• the chamfer at the bottom communicates that the suggestion window does not scroll any further. So users do not need to anticipate scrolling around in the prompt area. This way, scrolling/pagination feels more like bringing the suggestions to the user, not the user perspective shifting around in another layer. I want Nyxt to feel like surfing the internet, and bringing my toolbox with me.
• I also like the look of it (maybe I have been looking at this gray box for too long). Notice continuity with the other angled components.

[jmercouris]

Just a heads up, I am working on this :-)

[aadcg]

@lansingthomas could you re-read and conclude whether there is any actionable task left to squeeze from this thread?

[aadcg]

@lansingthomas friendly ping :)

[lansingthomas]

looks fantastic. Well done all.