Skip to content
This repository has been archived by the owner on Jan 1, 2025. It is now read-only.

Remove debug clutter from interface #61

Open
linkfanel opened this issue Nov 14, 2016 · 4 comments
Open

Remove debug clutter from interface #61

linkfanel opened this issue Nov 14, 2016 · 4 comments

Comments

@linkfanel
Copy link
Contributor

It's nice that contrary to the utwente WebSDR software, KiwiSDR makes an attempt at maximizing the use of screen real estate for the waterfall. However at the same time, it makes it frustrating whenever the interface clutters the useful display :/

I'll talk personally but I expect plenty other people would feel the same. The thick, solid top bar feels cumbersome. The top left general information about the KiwiSDR instance are nice to have and read once, but don't warrant taking all that top bar space all the time. The logos don't, and the average user doesn't care about the CPU and network debug.

Same about the bottom left panel: the contact links are not useful to keep at hand all the time, and the average user doesn't care about the config, uptime, audio and network debug...

I think most people look at this bottom left panel only for the user slots. I think there should be a dedicated "user status" panel, with these user slots, and the callsign input field should be moved to it and free the top bar, and the external chatroom link I mention in #60 should be put there too. The debug from that panel, and in general everywhere, should be kept out of the way by default for average users. This would also help with the user experience on mobile devices while waiting for a dedicated interface.

@G8JNJ
Copy link

G8JNJ commented Nov 15, 2016

Hi,

I think that many of the ideas raised here are certainly worthy of further discussion.

I agree that a lot of the information on the top bar is only of minor interest and that the most useful is the user slots, as it's worthwhile knowing how busy the SDR is and what other people are listening to.

I also think that perhaps a 'vote for this SDR' link should be provided within the KiWi that would update the votes on the SDR.hu site.

For me the major issue WRT the display is the control panel that permanently obscures the most useful part of the waterfall.

I'd prefer the control panel to be along the bottom of the waterfall and pop up when required like the windows task bar.

Maybe this topic should be merged with "Hide mode, freq, s-meter panel? #7"

Regards,

Martin

@ka7u
Copy link

ka7u commented Dec 1, 2016

It does depend on the available viewing area. Working with the interface on a cell phone is not a good solution as the layout is currently designed. But how satisfying would a cell phone interface ever really be for this application? I feel the top bar is for initial information and should be replaced by the user with the Spectrum display during actual use of the interface. Tuning the radio with this interface is a visual operation and without the spectrum display, the user is missing out on a very intuitive tuning opportunity. It also is very helpful in adjusting the waterfall to maximize the available signal availability. I really like the present interface. I'm sure it could be improved, but would be concerned that the good that exists could be compromised with the new and improved versions. Hi Hi
Ron - KA7U
kiwisdr19

@dish-eme-sdr
Copy link

I've been experimenting with openwebrx running on a raspberry pi-3 since before the kiwisdr days. The most annoying thing to me about the kiwisdr display is the HUGE white bar that displays the band / call letters / station info. Although this info comes in handy from time to time, I consider it a HUGE waste of screen space and certainly not something I like to have on the screen all the time. In fact, I found it so annoying that I ended up altering the code on my system so that this is permanently disabled. Of course this creates issues with updates, so I also have that turned off and only do an update when I have time to once again alter the code to something more to my liking.

I was hoping that sometime down the road either I or someone else would could add a user option to turn the 'white bar' on and off much the same as the lower panels.

You will also notice I am experimenting with color, fonts, frame rate, etc. Scrolling the waterfall at 23 fps is a waste of bandwidth in my opinion and have mine set to 7 fps maximum which results in a data rate of ~80 kbs. The slower scroll rate also prevents info from scrolling off the screen too quickly.

Again, more work is needed here as I can see where the higher frame rate can come in handy, (spectrum display) but like the 'white bar' issue, not something that is needed all the time. Maybe, some sort of control panel is needed so these functions could be user defined.

As a programmer, I was disappointed when the system info was deleted::
"Beagle CPU 74% usr / 13% sys / 11% idle, FPGA eCPU 18%
audio 6 kB/s, waterfall 4 kB/s (7/7 fps), http 0 kB/s, total 10 kB/s (80 kb/s)"
and had to re-enable that info. I agree, this is useless info for the average user but it would be nice if I could get this info when needed, then turn it off.

I am thinking of duplicating the Rx user data and frequency displays on top bar so I don't have to open the lower right panel to get that info.

Here is what I am working with looks like as displayed using Firefox in FULL SCREEN mode:
10aa

I am also experimenting with color, fonts, etc. in the user panels to increase visibility (contrast): Next is to and fix the squelch so it works in other modes besides FM, like it did in openwebrx.
10b

@jks-prv
Copy link
Owner

jks-prv commented Oct 30, 2017

If you're a Kiwi owner/admin the system stats info is available on the status tab of the admin page.

I don't disagree with any of this really. I've been holding off on any major UI change because the whole thing needs a serious re-think with a mobile UI also in mind. There is also the serious question of whether a UI framework should be used (JQuery, Bootstrap, ...) which would be a huge change requiring much effort. OpenWebRX is now using JQuery. There are so many other things to be done that people are clamoring for (see kiwisdr.com/bugs).

One of the oldest open bugs is to change the update mechanism to use an alternate github repository. That would make it easier for you to use github to merge your private changes with the current releases and update from your own branch. Maybe I should finally get that working..

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants