network graph - show/hide panels based on window width/height

[RandyMcMillan]

The debugwindow - network graph hides ui elements
btnClearTrafficGraph, lblGraphRange, sldGraphRange
when at minimumHeight, it also hides the groupBox
at minimumWidth - this maximizes the dimensions of
the traffic graph in these small dimensions.

[RandyMcMillan]

20220131135552215.mp4

[RandyMcMillan]

commit a1bd27f rebase and set side panel to hide at 2x the minimum width of app window. Same functionality as #539 commit 874b2d8 screen cast - without other changes.

[jarolrod]

From a UX perspective, why would we ever want to hide access to the durations slider and the current in/out values? Perhaps we could make more efficient use of the space in displaying the slider and in/out values as was attempted in #90.

[RandyMcMillan]

@jarolrod

Part of what I have added to my thought process is how this will translate to the mobile U/I (android/etc) - I have implemented a hybrid version of both of these approaches - but haven't posted a PR to it.

Some of my conclusions to these approaches (and the gui repo in general) - is that it may be beneficial to have a hybrid of both implementations - it would lend itself to a mobile portrait/landscape design idiom.

I may be wrong - but there doesn't seem to be enough reviewing members/contributors that have experience in the nuances of cross platform design including mobile U/I support. I don't see the Android developers reviewing this stuff to ensure up/down stream compatibility - that seems weird/negligent to me, having done mobile UI design for web, macOS/(OSX) and iOS and (Apache/Cordova) work.

[RandyMcMillan]

I find it strange that this web interface collapses in a "responsive U/I" design - but you ask why would "we" want to do this. Who is "we"? Because most of modern UI/UX interface design has adopted this a long time ago at this point.

[luke-jr]

How about moving the current values on top of the graph (top-left?) instead?

[RandyMcMillan]

@luke-jr - I agree - thanks for your suggestion - I will revisit this PR shortly

[RandyMcMillan]

@luke-jr - how about a simple overlay?
Note: the transparency can (obviously) be adjusted.

note: this approach removed 39 lines of code.

[luke-jr]

That looks kind of hard to read IMO. Maybe just make it the default widget background behind the text? (QFrame for borders?)

[RandyMcMillan]

@luke-jr - This is pretty close to the original colors...
I will tighten all this up - I just want to make sure the colors are good before anything else...

[luke-jr]

The correct colours to match "original" are going to vary based on the user's colour theme.

But maybe as long as we make sure the text and background have good contrast, the theme doesn't need to apply within the overlay since the graph itself is unthemed.

I do think the current screenshots are still a bit hard to read. Maybe bolding the text will do the trick?

[RandyMcMillan]

I will look into toggling the graph (light/dark) themes based on system preferences - it may be a good "feature".

[RandyMcMillan]

@luke-jr

I have adjusted the colors based on the global template and an accessibility audit. If we are going to be this nuanced - please actually compile/run the PR changes. [deleted]

[RandyMcMillan]

traffic_graph_a11y_audit_2.mov

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

No conflicts as of last run.

[hebasto]

Closing this due to lack of activity. Feel free to reopen.