When You Need To Reload - page reload requirement affordance

[lansingthomas]

Purpose of request:
sometimes a page reload is the right thing to do, and the user needs to know about it.

Describe your proposed change:

1. For cases where a page reload is required to propagate changes, (certain modes, certain settings..) I propose adding a color change to the hover area of the existing reload button in the Status Buffer.
2. for the toggle-modes menu, add a helpful echo to clarify what is happening as different modes are marked/unmarked

Why do you believe this to be an improvement?

1. Small ways to show state changes for our system help orient users
2. the change will not get in the way of other UI elements, it is just a state change for an existing element.
3. clarifies the sometimes confusing system states in the toggle-modes menu.
4. provides some error prevention for changes made in the Common Settings page.

Additional context/User story:
I have not thought through every place this might apply, and I suspect there will be times where prompting the user for a page reload is helpful.

Screenshots/Mock ups:

---

Pre-Build Checklist:

• Discussion has occurred.
• One or more developers have signed off on this change.
• One or more user researchers have signed off on this change.

[lansingthomas]

@aartaka this is related to our upcoming conversation about checkboxes :D

[lansingthomas]

The color for this state: reload-required should be action+ from our palette ^^

• #72CDFE
• in dark theme this is #4C21AB

[lansingthomas]

Hi @aartaka,
do you need any more information for this to happen?

I think this a resolution for this issue will be helpful for the upcoming (soon) Common Settings page.

[aartaka]

No, it's clear enough. But I'll de-assign: I'm getting back to more pressing things. @jmercouris, @hgluka, any taker?

[hgluka]

I can take it, but just to be clear, the Common Settings page requires a restart, not just a reload. Maybe there should also be a way to signal that a restart is required.

We'll also need to think about all the places where this sort of thing comes up.

[aartaka]

Yeah, maybe it's simpler to make a note/popup/if-confirm prompt?

[lansingthomas]

the Common Settings page requires a restart, not just a reload.

Ah yes.

a note/popup/if-confirm prompt

This makes sense... let's keep the Restart prompt separate for now. I'll open an issue to capture the idea.

[aadcg]

My opinion is that we're thinking 100% backwards. We don't need to fix the UI when the issue is coming from the engineering. If a mode is enabled, then it must have immediate effect. There may be some rare cases when this is not possible, but we'll get to that.

"Fixing" the UI to mask deeper design issues isn't acceptable.

[lansingthomas]

Fair enough. I am solution agnostic for this problem: Poor visibility of system state when a page requires reload, (and when the app requires restart)

I am seeing [3] potential remedies, which could happen individually, in combination, or not at all.

1. light up the reload button when appropriate
2. echo in the message buffer when appropriate
3. reduce or remove the cases where a page reload or an app restart are required

@aadcg & @jmercouris (if alive) Please help by deciding a course of action for this one.

Or tell me to ignore it -- just please acknowledge that it is annoying to wonder "is this broken? or do i need to reload...?"

I am not able to estimate the difficulty of implementation the way you two can. My perception is that Nyxt will require re-loads and re-starts for a long time... dunno.

Thank you!

P.S.
If working backwards is what it takes to make nyxt more usable then let's go backwards sdrawkcab og s'tel :)

[aadcg]

The priority is 3 and, at the stage of the project, the strategies to mitigate rough edges can't obfuscate the issues themselves. Sensible mitigation efforts include mentioning it in the documentation. For example, the docstring of no-image-mode says:

Disable images in current buffer.
Might need page reload to take effect.

---

The top post mentions settings and modes. With regards to settings, the on-going effort is #3120. Let's be patient and wait for its outcome. As to modes, we need to address each and every one of them separately. E.g. to discuss no-image-mode, an issue can be created about it. I can think of several strategies to address it.

---

No one-size-fits-all. An actionable outcome is derived from an issue when we achieve to expose the crux of the topic.