Message Buffer improvement thread

[lansingthomas]

Purpose

1. improve visual affordance of the message buffer
2. discuss any other issues with the message buffer and seek to resolve them.

What is your proposed change?
a visual hint of some kind for the moment(s) when the message buffer becomes an input area.

Rationale

1. For those who do not expect to look at the very bottom of screen for tiny text, the message buffer is hard to find. It is small, and relies on past experience or familiarity with Emacs to even notice it. Experiences which some of our users (and many of our future users) do not have.
2. I am fine with the message buffer being small, as long as we can make it a bit more noticeable for the important moment when people need to find it to advance through their online task.

Constraints
Lets keep it minimal, as the message buffer is not really the main attraction. It seems to have been made small for good reasons.

Additional context/User story
Artyom wrote about this a bit in #2761

In general, message buffer is our only way to show something to the user, and we are only using it for something important. It should be looked at, I believe. The problem is: it's not that visible, especially on hi-res screens.

Screenshots/Mock ups
A visual hint could look like this inner-border/box-shadow:

Another form could look like this text highlight:

I imagine the highlight could flash a few times before disappearing.

Pre-Build Checklist:

talk through the change with someone, get clear on specifications, then come back and mark off what you can

• 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.
• The specifications are clear.

Thank you!

[aartaka]

My random ideas:

• We have to make message buffer higher and make the text more visible. Size is the simplest solution here, but likely not the complete one.
• We can actually hide the message buffer by default, only showing it when there's a message. Like Firefox's URL tooltips.
• We can add some design elements (I remember suggesting (Make message buffer more self-sufficient and discernible. #2719?) to have a triange as the starting marker for message buffer) to highlight and emphasize.
  • If it's a triangle that I've suggested, we can paint it accent for regular messages and warning for errors/warnings.

I don't like the idea of flashing, because it's (subjectively) irritating and is quite an overused design trick (think any online ad) to be actually attention-catching.

[aadcg]

@lansingthomas we may be discussing too many topics at the same time.

You closed issue #2761, which means that you tacitly accept that the purpose of the message buffer is two-fold: (1) echo messages/notifications and (2) act like a pseudo input area (as in the case of describe-key). In retrospective, I think that this is unacceptable because we have two input areas (prompt buffer and message buffer). We should have a single one. The message buffer won't become the single input area because that would require too many changes. So the prompt buffer must become the single input area. In practice, that requires refactoring describe-key and friends in such a way that the prompt buffer is invoked (yet collapsed to its input area), see below.

Conclusion: If the message buffer doesn't act like an input area, the problems you report may partially or completely vanish.

---

About improvement the message buffer UI (when echoing messages), I don't think we can follow some of the suggestions proposed.

Increasing the font size is unacceptable. The font size can't be bigger than that of the prompt or status buffer, because the message buffer is less important than those. See below.

If the message buffer is hidden when blank, then that means that the status buffer will jump up and down. Unacceptable too.

We could draw the message buffer above the status buffer and hide it when blank. But, do we want to make such a radical UI change at this point? Why changing such a distinctive feature of ours? Does it pay off? I don't think so.

---

Note: We might be using the wrong language here. We're saying that there are "two input areas" but what we actually mean is something else: we're being prompted for input from two distinct UIs, which is not ideal since it breaks the user's expectation.

[aadcg]

Notice that this gets tricky when you start to think deeper. The prompt buffer's input area mostly requires you to type words. In a describe-key scenario it would ask you to press a keybinding.

And some questions pop up. If you hit C-p, where should it be echoed: message buffer or prompt buffer's input area? When you issue the command, do we need to echo to the message buffer what the user needs to do or is it enough to have it to the left of the prompt buffer's input area?

---

We could also explore the idea of having the message buffer serve a dual role. But that would require specializing the UI depending on the use case. I'm leaning towards avoiding that.

Just some food for thought @lansingthomas :)

[lansingthomas]

Good stuff here.

• I think Artyom suggests an increase to the overall size of the message buffer before an increased font size.
• I like the idea of hiding message buffer then bringing it out when required (like FF does it).
• I worry that another shape (like the blue triangle or similar) might look cluttered in that bottom left corner.
• I agree that flashing is not good enough to carry forward.

is it helpful for me to make mock ups for any of these ideas?

purpose of message buffer

purpose of the message buffer is two-fold: (1) echo messages/notifications and (2) act like a pseudo input area

1. The echo function seems great. I think we all agree there.

2. Number two does seem silly to me. Before I keep advocating for message buffer UI changes let's see if we can eliminate the need the pseudo input area. I propose a possible alternative for it below. The existing minimized prompt buffer.

Can we come up with reasons to keep the message buffer as an input area? (other than emacs does it that way :P)

possible alternative for fast inputs minimized prompt buffer

• Try the repeat-key command (see how the first input prompt asks for user input without showing a big panel). Why not have the second input do the same thing? Though, we would want to set it so that users do not need to return after their input. (possible?)

First input for repeat-key:

Second input for that same command in status quo:

Second input for that same command in hypothetical:

I am going to wait to write a spec for this until I hear what you all think.

[aartaka]

Note that we already have some non-orthodox (and not exactly intuitive/beautiful) uses for prompt-buffer:

• tag-source listing the space-separated tags from the prompt input as separate suggestions.
• toggle-modes listing enabled modes as marked and disabled ones as unmarked.

So we can potentially use prompt buffer for key inspection and echoing, yes.

[aadcg]

@lansingthomas what's the conclusion/status on this issue?

[lansingthomas]

Decision
No structural changes. Just a border to let people know when the message buffer is behaving like an input area.

Please light up the border of the message buffer with action color when it becomes an input area.

• a thin border
• I want to recycle this border later on for error and success messages (but not today)

Like this:

Thank you for the good follow up @aadcg

[aadcg]

when the message buffer is behaving like an input area.

While I understand what you're trying to say, I don't think it's accurate. The message buffer notifies the user about events. In this case, it notifies about a step the user is expected to fulfill. But the message buffer doesn't become an input area. The input event is consumed in the same way other commands are. For example, issuing page down while navigating a web page.

On this topic, I think that #2997 is important and it needs to be addressed.

Whether we'll use these kinds of border in others contexts remains to be seen, but let's stay on topic.

[lansingthomas]

Well, whatever it is called. We might want to bring people attention there when it makes sense to.

@lansingthomas what's the conclusion/status on this issue?

still inconclusive : )

If you want to close the issue I'm fine with it. If I cannot prove my case then, no action is the right action.

[aadcg]

I'm closing it since I think that the way to improve describe-key is by closing #2997.

Note that #3170 will enable tweaking the size of the message buffer with more ease.