Platform
MeshMapper Web
What happened?
I wanted to pass along some feedback on the current color scheme in MeshMapper, particularly from the perspective of new users trying to interpret the map quickly.
Right now the color coding for things like RSSI, SNR, repeater status, ID conflicts, and the coverage grid overlay doesn't map cleanly to an intuitive "how good is this" mental model — partly because the same colors get reused with different meanings across different layers and Coverage Modes, and partly because some layers only use a two-color green-to-red gradient with no defined middle step. I'd suggest moving to a standard 4-color traffic-light scheme that maps consistently onto signal/operational quality across every layer:
Green — Good: Strong RSSI/SNR, repeater reporting normally, no ID conflicts. The link or node is fully usable with margin.
Yellow — Minor issues / weak but usable: RSSI or SNR near the lower edge of reliable decode, occasional missed pings, but still passing traffic. Tells the user "this works, but don't count on it in marginal conditions."
Orange — Moderate issues / barely usable: RSSI/SNR low enough that packet loss is likely, intermittent repeater uptime, or other signs the link is struggling. This is the "you can hear it, but it's not dependable" tier.
Red — Heard but unusable / major issues: Signal present but below a usable decode threshold, repeater ID conflicts, prolonged downtime, or anything that actively prevents correct or efficient repeater operation. This is the "don't rely on this" tier.
Here's how that would change a few specific things I've noticed:
Repeater Status: Currently, Orange means "New" (a repeater seen in the last 14 days) — unrelated to signal quality or operational health. Instead, I'd recommend a new repeater's status color be based on its actual last signal info (using the same green/yellow/orange/red quality scale above), just shown as a lighter/desaturated shade of that color while it's still in the "new" window. Once it ages out of "new," it simply transitions to the standard, full-saturation version of that same color. This keeps the color meaningful (it still reflects real signal quality) while still visually flagging "this one's new" through shade rather than a completely separate hue.
Signal Strength (RSSI/SNR): Right now this is a green-to-red gradient with no orange step, so users have to guess where "usable but weak" ends and "basically unusable" begins. Splitting that ambiguous middle zone into yellow (weak but usable) and orange (barely usable) gives two clearly labeled, actionable categories instead of one fuzzy one.
Duplicate/ID Conflicts: Currently this is Red ("Excluded"), the same red used for low signal strength or stale pings. A user scanning the map can't tell at a glance whether red means "this repeater has an ID conflict" or "this repeater's signal is just weak" — they have to click in for details. Standardizing red specifically for major/blocking issues (including ID conflicts) keeps red meaningful as "stop, this needs attention," while yellow/orange handle signal-quality degradation.
Repeater Time Offset: This currently has no color at all — it's a text warning buried in the sidebar. Folding it into the same red/orange logic (e.g., orange for a moderate clock drift, red for drift large enough to disrupt scheduling/duty-cycle behavior) would let users spot misconfigured repeaters from the map view itself instead of clicking into each one.
Coverage Grid Overlay: This is probably where the inconsistency shows up the most. In Standard mode, grid squares are colored by ping type (green=BIDIR, orange=TX, purple=RX, etc.), which is a completely different color language than Effective Coverage, Signal Strength, Ping Age, and Noise Floor modes, which each use their own green-to-red gradient for a different underlying metric. A user switching between Coverage Modes has to relearn what color means in each one — green might mean "bidirectional link confirmed" in one mode and "strong signal" in another, even though those aren't the same thing. I'd recommend applying the same green/yellow/orange/red quality scale uniformly across every Coverage Mode, so green always means "good here," yellow/orange always mean "degrading," and red always means "avoid/unusable," regardless of which underlying metric (SNR, age, noise, ping type) is driving that grid square's color. The Priority System that picks the "best" ping to represent a mixed grid square would still work the same way, it would just be selecting from a single consistent color scale instead of different scales depending on mode.
The advantage of this approach is that it's a near-universal convention — most people already associate green/yellow/orange/red with go/caution/warning/stop — so it reduces the learning curve for new users significantly, while still giving experienced users enough granularity to distinguish "weak but working" from "actually broken." More importantly, it gives one consistent scale across every layer (signal strength, repeater status, ID conflicts, clock sync, and the grid overlay itself) instead of requiring users to learn a different color vocabulary for each mode.
Thanks for all the work on MeshMapper — it's been a great tool to use.
How to reproduce
standard use of meshmapper by any user
What should happen instead?
more standardized and user intuitive color scheme
How bad is it?
Medium - Annoying but workable
Anything else?
No response
Platform
MeshMapper Web
What happened?
I wanted to pass along some feedback on the current color scheme in MeshMapper, particularly from the perspective of new users trying to interpret the map quickly.
Right now the color coding for things like RSSI, SNR, repeater status, ID conflicts, and the coverage grid overlay doesn't map cleanly to an intuitive "how good is this" mental model — partly because the same colors get reused with different meanings across different layers and Coverage Modes, and partly because some layers only use a two-color green-to-red gradient with no defined middle step. I'd suggest moving to a standard 4-color traffic-light scheme that maps consistently onto signal/operational quality across every layer:
Green — Good: Strong RSSI/SNR, repeater reporting normally, no ID conflicts. The link or node is fully usable with margin.
Yellow — Minor issues / weak but usable: RSSI or SNR near the lower edge of reliable decode, occasional missed pings, but still passing traffic. Tells the user "this works, but don't count on it in marginal conditions."
Orange — Moderate issues / barely usable: RSSI/SNR low enough that packet loss is likely, intermittent repeater uptime, or other signs the link is struggling. This is the "you can hear it, but it's not dependable" tier.
Red — Heard but unusable / major issues: Signal present but below a usable decode threshold, repeater ID conflicts, prolonged downtime, or anything that actively prevents correct or efficient repeater operation. This is the "don't rely on this" tier.
Here's how that would change a few specific things I've noticed:
Repeater Status: Currently, Orange means "New" (a repeater seen in the last 14 days) — unrelated to signal quality or operational health. Instead, I'd recommend a new repeater's status color be based on its actual last signal info (using the same green/yellow/orange/red quality scale above), just shown as a lighter/desaturated shade of that color while it's still in the "new" window. Once it ages out of "new," it simply transitions to the standard, full-saturation version of that same color. This keeps the color meaningful (it still reflects real signal quality) while still visually flagging "this one's new" through shade rather than a completely separate hue.
Signal Strength (RSSI/SNR): Right now this is a green-to-red gradient with no orange step, so users have to guess where "usable but weak" ends and "basically unusable" begins. Splitting that ambiguous middle zone into yellow (weak but usable) and orange (barely usable) gives two clearly labeled, actionable categories instead of one fuzzy one.
Duplicate/ID Conflicts: Currently this is Red ("Excluded"), the same red used for low signal strength or stale pings. A user scanning the map can't tell at a glance whether red means "this repeater has an ID conflict" or "this repeater's signal is just weak" — they have to click in for details. Standardizing red specifically for major/blocking issues (including ID conflicts) keeps red meaningful as "stop, this needs attention," while yellow/orange handle signal-quality degradation.
Repeater Time Offset: This currently has no color at all — it's a text warning buried in the sidebar. Folding it into the same red/orange logic (e.g., orange for a moderate clock drift, red for drift large enough to disrupt scheduling/duty-cycle behavior) would let users spot misconfigured repeaters from the map view itself instead of clicking into each one.
Coverage Grid Overlay: This is probably where the inconsistency shows up the most. In Standard mode, grid squares are colored by ping type (green=BIDIR, orange=TX, purple=RX, etc.), which is a completely different color language than Effective Coverage, Signal Strength, Ping Age, and Noise Floor modes, which each use their own green-to-red gradient for a different underlying metric. A user switching between Coverage Modes has to relearn what color means in each one — green might mean "bidirectional link confirmed" in one mode and "strong signal" in another, even though those aren't the same thing. I'd recommend applying the same green/yellow/orange/red quality scale uniformly across every Coverage Mode, so green always means "good here," yellow/orange always mean "degrading," and red always means "avoid/unusable," regardless of which underlying metric (SNR, age, noise, ping type) is driving that grid square's color. The Priority System that picks the "best" ping to represent a mixed grid square would still work the same way, it would just be selecting from a single consistent color scale instead of different scales depending on mode.
The advantage of this approach is that it's a near-universal convention — most people already associate green/yellow/orange/red with go/caution/warning/stop — so it reduces the learning curve for new users significantly, while still giving experienced users enough granularity to distinguish "weak but working" from "actually broken." More importantly, it gives one consistent scale across every layer (signal strength, repeater status, ID conflicts, clock sync, and the grid overlay itself) instead of requiring users to learn a different color vocabulary for each mode.
Thanks for all the work on MeshMapper — it's been a great tool to use.
How to reproduce
standard use of meshmapper by any user
What should happen instead?
more standardized and user intuitive color scheme
How bad is it?
Medium - Annoying but workable
Anything else?
No response