[Python] UI/UX considerations

All things Programming
Post Reply
User avatar
Naib
Site Admin
Posts: 928
Joined: Sat Dec 19, 2020 2:20 am

[Python] UI/UX considerations

Post by Naib »

So...
I have this little application I wrote something like 10years ago. It basically permits me to "talk" to my motor-controllers that are FPGA based. This is done via an FTDI chipset to provide the hardware and transport layer. The application layer is what a colleague and i pulled together and its done us proud for well over 10 years.

Originally it was using py25+pyGTK but then I jumped to pyQt when GObject Introspection replaced with py3 and initial windows support was non-existent (yes this runs on windows ). The need to upgrade was primarily to ensure I do not get boxed in but also some nasty bugs were fixed in matplotlib and a bump was needed. As I said ... works really well and the toolchain is "frozen" on py34 and qt4 ... annoyingly old but still works...

my colleague and I want to resolve some shortcoming in the underlying protocol to remove limitations and help expand use-cases. My main drive is to re-baseline the toolchain, especially as the python wrapper I wrote around the FTDI driver doesn't work with py38 when I 1st looked at re-baselining 6months ago. I have some idea's to improve the UI but the biggest stumbling block is on the "virtual oscilloscope"


The core of this part is a frame containing a matplotlib plotting area. Presently there are some combo-boxes where the user can select what "signals" they want to plot, plus some other settings (whether fft, timestep etc)... When a PLOT button is pressed a bunch of data is streamed from the target FPGA and the UI re-assembles and plots it. Happy days.

Plot speed? sure, current? sure, DC-link voltage? sure. Faults? sure ... in lies the concern. Everything is basically 16bit so plotting speed is a case of taking the 16bit fixed-point and doing a mx+c to change it from z-domain to s-domain. Same with the other quantities. The Fault registers are just a std_logic_vector and thus each bit means something. IF I plot this on the same plot as other continually varying data and I am interested in when one particular bit toggles, the graph is swamped by the 16bit integer...

What I want todo is give the user the option to plot individual bits on a secondary graph a bit like how modelsim plots digital signals. The issue is how to present this option to the user.
The best argument against democracy is a five-minute conversation with the average voter

Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
User avatar
RoGeorge
National Metrics Strategist
Posts: 301
Joined: Sat Dec 19, 2020 4:47 am

Re: [Python] UI/UX considerations

Post by RoGeorge »

A screen capture would help to understand what exactly is the question about. Also, how fast is the datastream and how often those bits are changing?

Will a second oscilloscope screen underneath the analog signals, like a subplot for digital only, be enough? Or are you looking for something different than a modelsim style (to me modelsim looks very hard to read)? Have you looked into other stiles offered by various logic analyzers, for example Saleae, or MSO oscilloscopes, or the open source sigrok (just for the look of the screen, not the whole SW stack)? Also matplotlib's demo page has a lot of eye catching charts and plots:
https://matplotlib.org/gallery/index.html

Aside from that, FTDI is very expensive for a serial over USB chip. CH340 cost only cents and it will be presented like a standard serial over USB, so it won't require tinkering around the drivers.
User avatar
dont_think_twice
Director of Sandbags
Posts: 592
Joined: Sat Dec 19, 2020 4:15 am

Re: [Python] UI/UX considerations

Post by dont_think_twice »

No idea what you are specifically asking for. I’ll take the opportunity though to mention something that worked well for me: I was trying to make a quasi real time oscilloscope on a raspberry pi ( with fat also plotted). I tried matplotlib, but it was too slow no matter how I tried to blit it. I switched to openCV, and easily got 30 FPS. It doesn’t have all the nice features of matplotlib, but that’s okay for what I needed.

I think openCV is compiled to take advantage of neon, which helps.
desultory
Sanitation Engineer
Posts: 9
Joined: Mon Dec 21, 2020 4:47 am

Re: [Python] UI/UX considerations

Post by desultory »

Naib wrote: Sun Dec 20, 2020 5:02 pmWhat I want todo is give the user the option to plot individual bits on a secondary graph a bit like how modelsim plots digital signals. The issue is how to present this option to the user.
If I am answering the right question, why not treat it as analogous to an indicator light, or if change over time is of interest a running plot?

As far as controlling it goes, a combobox or dropdown menu seems the least bad common modality for a GUI, 16 radiobuttons would be rather space inefficient, but might have other factors weighing in their favor. Other options would seem to call for additional work that would otherwise be unnecessary, like validation if it was controlled by prompting the user to enter a value in hex, or octal, to indicate the desired bit.
User avatar
Naib
Site Admin
Posts: 928
Joined: Sat Dec 19, 2020 2:20 am

Re: [Python] UI/UX considerations

Post by Naib »

Apologies for not not replying sooner, this is on my work windows laptop and I refused to boot it over the xmas period :)

So basically this is a tool I created to interface with some of my hardware and I am taking the small window I have to do some refreshing ( py34 -> py39, qt4 -> qt5 etc).
Slowly pushing through the backend stuff to either align with the updated toolchain or bake in improvements I have thought of over the years based upon use-case shortcomings,

So this query is about UI/UX of one of the functions - plotting. The UI is used to configure the target FPGA with what to stream ( NOTE: it is more of a snapshot rather than continuous streaming at this point, that is a wider improvement).

Part of the wider UI/UX improvement is a location bar on the right where READ,BITS,WRITE,PLOT,LOG can be accessed and the central area is a qtWidget that is replaced (rather than the present tab ... eats too much area...)

So consider the plotting. The user has 6 channels to choose from which are combo-boxes. Then there are a few other options. This is sort of fine and as desultory hinted at still probably the best way to convey a choice.
The complication would be how to then also expose BITS if they were to be plotted individually.

Present (drive specific...) there are a number of FAULT and STATUS registers where each bit represent a different piece of info. Present these registers can be plotted like any other but the problem is if I am plotting a velocity of say ... 1000rpm and sinusoidal current of say 500A and then plot a FAULT register and the MSb toggles (because the MSb is say: OVER_TEMP), this gets plotted as 0 -> 65k step and thus the rescale via matplotlib swamps the display.
Present workaround? save as CSV and extract the bit/s of interest

What I would like to do is be able to add a smaller subplot (easy) specifically to BIT's only but how to present to the user the offer? My initial thinking was keep with the combo-box but when the user hovers of a STATUS or FAULT register it expand to the expanded 16bits ... problem I'm not sure its possible to have an expanding entry in a combo and thus the query how best to offer this capability?

Below is the present UI. The 7 plots mean something as I used these to ensure the FFT function worked as each curve has a different harmonic added (pita settling on a suitable window function...)

Image


As to FTDI ... CH340 is nice but it is exposed as a UART (hardware and software side) and thus it is subject to the userland tick of the underlying operating systems and on windows this is an annoyingly inconsistent 15-20ms between requests as it gets exposed as a virtual coms port and there is no low-level driver access . I will look into this family for future options and because of my abstraction my libFTDI could be replaced as a libCH340 to permit my bespoke protocol application layer
The best argument against democracy is a five-minute conversation with the average voter

Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
User avatar
dont_think_twice
Director of Sandbags
Posts: 592
Joined: Sat Dec 19, 2020 4:15 am

Re: [Python] UI/UX considerations

Post by dont_think_twice »

Are the bits hard coded, so that you always know what they represent, or do they need to be determined on the fly?

An expanding menu would be cool - you need a tree view embedded in a combo box. Or use a classic menu, with arrows to see more options in a sub-menu.

Or you could just throw a second combo box below the first, that gives the detailed choices. For cases where there is no detail (velocity), it would just be greyed out.
User avatar
Naib
Site Admin
Posts: 928
Joined: Sat Dec 19, 2020 2:20 am

Re: [Python] UI/UX considerations

Post by Naib »

such configuration would be static for its instance - I pre-parse VHDL to know what the code exposes to build up a class of information - address, gain, offset etc..

I was looking at a treeview but was getting stumped on how not to make the entire thing appear clunky...
daughter combo that are only enabled and populated with pre-determined fields could work

its the UX I am concerned with. with widescreen (laptops and monitors) being the default now, y-axis is at a premium while there is more on the X, hence thinking along the lines below. I stacked a load of combo and every other one disabled *IF* a non-bitfield is selected. It could work

Image

The idea is when the user clicks on one of the buttons on the right the main central widget is replaced - READ then a qtTable is placed with NAME: value.. .rows and columns generated based upon how many is exposed.
WRITE: same as READ but the 2nd column is editable
BIT's either a qtTable or what I presently do to break out the bits and highlight with a green/red picture whichone is set and what each one means.
PLOT, basically a matplotlib embeded with the additional UI
LOG well...
The best argument against democracy is a five-minute conversation with the average voter

Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
desultory
Sanitation Engineer
Posts: 9
Joined: Mon Dec 21, 2020 4:47 am

Re: [Python] UI/UX considerations

Post by desultory »

In that case, what about a ticker plot, showing the state of the selected bits, synchronized with and running under the main plot?
User avatar
Naib
Site Admin
Posts: 928
Joined: Sat Dec 19, 2020 2:20 am

Re: [Python] UI/UX considerations

Post by Naib »

desultory wrote: Wed Dec 30, 2020 3:14 am In that case, what about a ticker plot, showing the state of the selected bits, synchronized with and running under the main plot?
Conceptually yes that's what I will be doing, its more a concern as to how to present the options to the users.
So the hardware limitations is 7 channels can be selected. If all 7 are selected are bitfields (status or fault), that is 112 ticker type signals ... too many so the idea is to select say 5 bits out of all available

15years of using this tool with moderate support until py34 has given me an idea as to how people use it and what people are interested in. 5 isn't too much of a limitation but selecting 5 out of maybe 112 could be (from a UX perspective)
The best argument against democracy is a five-minute conversation with the average voter

Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
desultory
Sanitation Engineer
Posts: 9
Joined: Mon Dec 21, 2020 4:47 am

Re: [Python] UI/UX considerations

Post by desultory »

That seems like a job for a tree, or "zoom" interface; especially given that each level is, at least seemingly, not excessively broad but the whole set would be if presented flatly.
User avatar
dont_think_twice
Director of Sandbags
Posts: 592
Joined: Sat Dec 19, 2020 4:15 am

Re: [Python] UI/UX considerations

Post by dont_think_twice »

Also, 500 A? That is a serious motor your are working on.
User avatar
Naib
Site Admin
Posts: 928
Joined: Sat Dec 19, 2020 2:20 am

Re: [Python] UI/UX considerations

Post by Naib »

desultory wrote: Wed Dec 30, 2020 3:42 am That seems like a job for a tree, or "zoom" interface; especially given that each level is, at least seemingly, not excessively broad but the whole set would be if presented flatly.
exactly.
A tree widget might make sense here.

Code: Select all

- Channel 1
    - Velocity ( ) 
    - PhA current ( ) 
    - Fault reg 1 (o)
        - Over-temp [x]
       - Over-current [ ]
      - CRC Error [x] 
...
- Channel 2
    - Velocity (o) 
    - PhA current ( ) 
    - Fault reg 1
        - Over-temp []
       - Over-current [ ]
      - CRC Error [] 
would permit expanding when the user wants. By alternating radio and checkbox the user has a choice. Any bits selected would then be plotted in a subplot dedicated to digital signals.
I just need to ensure it doesn't take up too much space ... it shouldn't as the alternatives could. What would be good would be if the qtDockWidget could auto-hide then I could use that so it pops out with a mouse over when the user wants to change something then slides back in when it isn't in-use.
This doesn't seem to be something the dock widget does by default (which is odd) ... I could code something but thats getting into the extremes of my capabilities - When a control,systems,power engineer dips his toe into software :)

dont_think_twice wrote: Wed Dec 30, 2020 3:46 am Also, 500 A? That is a serious motor your are working on.
Its only 500A peak not rms (when dealing with FOC, Clark&Park you sort of need to deal with peak not rms... took ages for me to get use to that since instinctively AC quantities are always discussed in RMS). There is a 1000A another team is working on and ill just get dragged in for consultation, otherwise its this 500A and a 100A i have
The best argument against democracy is a five-minute conversation with the average voter

Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Post Reply