More UI/UX behaviour and usability improvements!

[RemyDavies]

Hello Jan, I've noted some more UI/UX behaviours and usability improvements that I believe could be valuable to consider for a future update. These suggestions come from years of working with various brands of VNAs, so I do hope they’re helpful rather than presumptuous. I’d really appreciate your thoughts, as I’d love to see this project continue to evolve and improve.

1. Change the default Symbol Style to "Filled Triangle".
I understand that this is already a configurable preference; however, I would like to suggest using one of the "Filled Triangle" marker styles (number above or number inside) as the default symbol style for LibreVNA.

The filled triangle style significantly improves marker visibility - especially when viewing the display from a distance, as is common during field use. It also enhances clarity when markers overlap with traces or are positioned closely together.

2. Visibility of Out-of-Range Markers.
In the current release, marker triangles are entirely hidden when they fall outside the Y-axis range. Would it be possible to ensure that all markers remain visible at all times... and make this the default behavior? This would also align with how out-of-range markers are typically displayed on other VNAs, such as those from Agilent, Anritsu, and Copper Mountain.

Below is a visual example that I made with an image editor:

3. Dynamic Font Sizing.
I've noticed that the default font sizes (under Preferences > Graphs) tend to appear quite small when using a typical single-tile layout.

I understand that the smaller default font sizes were likely chosen to accommodate scenarios where multiple tiles (e.g., 4 or more) are displayed simultaneously. In that context, it makes perfect sense to reduce the font size to fit all the necessary information.

Could it be possible to have dynamic font sizing based on the number of active tiles. That way, the display would be optimized for both single-tile and multi-tile use cases?

For example, in single-tile mode, the font and line sizes could automatically adjust to something like:

Line Width: 1.00
Font (Axes): 15
Font (Trace Names): 15
Font (Marker Data): 15
Font (Cursor Overlay): 15

Then, as more tiles are activated (e.g., 2 or 4 tiles), the font sizes could decrease proportionally to ensure everything still fits neatly?

4. Default VSWR Axis Setup.
If VSWR is selected and 'Range: Auto' is turned OFF, consider setting the Maximum and Minimum fields to sensible default values, such as Max: 5.0 and Min: 1.0

[jankae]

Hi Remy,
thanks again for the suggestions. I think any suggestion can only be helpful - even if I may not agree with everything, it is always good to get feedback from users.

1. Change the default Symbol Style to "Filled Triangle".

I agree. It looks better and is a very easy change.

2. Visibility of Out-of-Range Markers.

Also a good point. Not quite that easy but the implementation should also be doable.

3. Dynamic Font Sizing.

This one I am more hesitant to implement. In my mind, the font size should be "readable without using up too much of the screen". I expect the user to configure this according to their needs (screen resolution, viewing distance,...). Once a good setting has been found, this should work no matter how many tiles are active.

Sure, for a single tile the text will be smaller relative to the graph. But the absolute font size does not change so you should still be able to read this easily.

I chose the default font sizes based on my (1920x1080) monitor and my viewing distance (typical desktop setup with monitor at the back side of the table). The default may not work well for your situation but that is why you can adjust it.

4. Default VSWR Axis Setup.

Yes, I think this would be helpful (not just for the VSWR axis but for all available Y axes types). I'll see whether there is an easy way to implement that.

[jankae]

1: Implemented with a28dd50
2: Implemented with b1c4c4f
3: Will not be implemented (at least not in the near future)
4: Most likely going to implement this but have to think of a good way. Currently leaning towards user configurable default min/max settings per Y axis type which will be automatically set whenever the graph is changed to that axis type

[RemyDavies]

Wow that was quick, thank you.

Can you make b1c4c4f as the default behavior for marker symbols 🤞

[jankae]

That should already be the default. There is a new setting in the preferences (called "clipToYAxis" in the code). The default value is true. It behaves like this:

• True: Show markers outside of the currently visible range at the top or bottom of the graph
• False: Do not show markers outside of the visible range

[RemyDavies]

Perfect thank you.

[jankae]

4 is also done now: 0818cda

I have implemented this with configurable limits per Y axis type in the preferences:

Whenever the Y axis type of a graph is switched, the limits are updated according to this table.

[RemyDavies]

Hi Jan, can you check the visibility of out-of-range markers when using Smith Chart?

[jankae]

Sure, I can check that. So far I am unable to reproduce the problem. There are 4 different cases I can think of:

1. Marker position and symbol completely inside the unit circle. This is the standard case and the marker shows up.
2. Marker position inside the unit circle but the symbol extends beyond it. This is the case for your first screenshot but in my tests it works fine:
   
3. Marker position outside of the unit circle and smith chart mode is set to Limit to visible area:
   
   This is the case in your second screenshot. In this case the marker does not show up because its position is outside of the visible area. This is intended behavior.
4. Marker position outside of the unit circle and smith chart mode is set to Show complete traces. The trace and any markers will show up even if beyond the usual smith chart range.

I think whats happening in your first screenshot is that the area for the graph is about as high as it is wide. The smith chart circle always uses as much space as possible but in your case it touches the left side of the graph area. Any space to the left already belongs to another graph and the smith chart graph is not allowed to draw anything on it:

[RemyDavies]

Thanks for looking into this.

I've been able to reproduce the behavior - however this may not be a bug, and just the intended behavior for markers with LibreVNA.

It is clear to me now that any existing markers will vanish when the Start/Center/Stop frequency range is changed, and the existing markers have fallen outside of the new frequency range.

At the time (when I raised this issue), the markers looked as though they had gone 'out of range' - when in fact they were outside of my frequency Start/Stop range.

I have noticed this behavior is also true for X/Y plots as well, not only Smith Chart.

Steps to reproduce behavior:

1. Open an existing setup for 445-455MHz Smith Chart (S11).
2. Load an existing SOLT calibration file for 445-455MHz.
3. Place a S11 Marker at 450MHz (Center).
4. Load a new calibration file for a frequency Start/Stop that is out of range of the existing Marker at 450MHz (i.e. 395-405MHz).
5. Select 'Yes' when asked if you wish to match the span.
6. The existing S11 Marker at 450MHz is no longer visible, as it now falls outside of the new Start/Stop frequency range.

S11 Marker at 450MHz (after changing Start/Stop range):

S11 Marker visibility returns after double-clicking on the Marker and hitting Enter (this resets the Marker to a frequency that is within the new Start/Stop range):

With other VNA's that I have used - when you change the Start/Stop frequency range, any existing markers outside of the new Start/Stop range are then automatically moved to a frequency that is within range - I believe this is intentional and ensures that all existing markers remain visible.

[jankae]

You are absolutely right, if you change the span a marker may end up outside of the frequency range and not show up anymore. I feel a bit conflicted on how to handle such a span change.
I think there is one main difference between other VNAs and the LibreVNA-GUI: With the LibreVNA-GUI you can also import other Touchstone files, perform TDR/DFT calculations (and other custom math operations) and keep previous measurements in memory which may have used different start/stop frequencies than the current span. All of this means that there can be several traces each with a different frequency range. It would be very annoying if every marker would always jump to the frequency range covered by the selected span because other traces could cover a much larger frequency range.

Markers are however assigned to a trace and the marker position is constrained to the frequency range of that trace. This is why the marker jumps back into view when you double-click the frequency and hit enter (this is treated as changing the frequency and the new frequency will be constrained to the trace).

I can think of a few different options to handle the marker position when something changes:

1. Always update the marker position automatically whenever the start/stop frequency of a trace changes. This is a very bad approach because a trace has no concept of the currently selected span. It simply is filled with the VNA data as it comes in. When you change any acquisition setting (such as the span), the active traces are first cleared of all data and then filled with the new data. When the first point hits the trace, it consists only of one point at the start frequency. The trace does not know how many data points will follow (and no, you can not just use the stop frequency because certain calculations can change the frequencies). So any marker on that trace would jump immediately to the start frequency whenever you change a setting (even if they are still within range of the new span).
2. Always constrain all markers to the selected start/stop frequency. As mentioned above this is also a bad approach because not all traces necessarily cover that exact frequency range
3. Add some logic to determine whether a trace does use the selected span and then change the marker position when the span is adjusted
4. Do not change the marker position if the trace changes its frequency range

I currently have implemented option 4. You could argue that option 3 would be the better choice. But I believe it may be difficult to always determine correctly to which trace this logic should apply (some math operations may change the frequency range, and some very similar other operations may not). And I also like that you can have a marker at a certain position, then zoom in with a tighter span if you would like to look at something else in detail and finally zoom out again and have that marker still at its original position.

[RemyDavies]

Thanks for the feedback Jan - I can definitely appreciate the complexity involved to implement any changes here :)