For consideration - revised input edit page for color LCD radios.

[philmoz]

I've reworked the layout for the input edit page for color LCD radios.
Comments, criticisms and issues welcome.

Summary of changes:

• Move everything out of the 'advanced' pop up to the main input edit page
• Move Source to the title bar to free up space
• Input name and Line name on the same line
• Switch and Trim on the same line
• 'Side' drop down replaced by 'x < 0' and 'x > 0' buttons under the preview (these are the only two options in the code). At least one or both must be active (handled automatically).
• GV buttons highlighted if the corresponding input is a GV variable.
• Portrait layout fits on one screen, Landscape has a small amount of scrolling still

Screenshots:

[Eldenroot]

Coool! Thx!

I would like to see in close future this implemented: #2466 (not related to this PR). This could save me a lot of headaches :)

[Eldenroot]

Maybe make white text in "modes" and in the graph black for better visibility?

[philmoz]

@Eldenroot the flight mode button color is set in the libopenui project. It’s easy to change but I’m not sure what else this might affect. Changing it might also adversely affect other themes. I agree it looks odd at the moment on the default theme.

[pfeerick]

Maybe FMMatrix is missing the active/inactive colours being set? It really should behave like a button - so perhaps needs some tweaking in either radio/src/gui/colorlcd/fm_matrix.cpp or radio/src/gui/colorlcd/themes/etx_lv_theme.cpp?

[philmoz]

I may be missing something; but to me it looks like the colors are hard coded into libopenui/src/button_matrix.cpp, btn_matrix_event function. When I change line 50 to use COLOR_THEME_PRIMARY1 the flight modes display with black text when active. I could not see any way to override this in fm_matrix.cpp or etx_lv_theme.cpp.

[philmoz]

I found a way to make the flight mode button text color behave like other text buttons. I also updated the landscape layout to fit without scrolling.

[Eldenroot]

Cool, good job. Now it should be consistent over all screens etc. So maybe future pr. I really like this change, thank you

[philmoz]

Adjusted the landscape layout to allow a larger preview of the curve.

[Eldenroot]

Much better! Good job.

[JimB40]

Although I understand advantages of no-scroll this implementation has 3 problems

1. Brakes UI consistency - top bar is for navigation and info
2. Flight mode buttons are too small though prone to touch error
3. Flight mode buttons are in 'difficult touch" area 20-30 px from the bottom (recessed screen)

Scolling with touch is quite fast so I'd leave it here to keep usability
Had a lot of work (closing year) but it's finished so if you wait @philmoz just a little I'd prototype it in Figma on Friday. There are few other thing like preview on left side and values on right (most of people are right handed).

[philmoz]

1. Brakes UI consistency - top bar is for navigation and info

It seems a waste to not utilise this available space. Also the 'Select Model' page has the 'New Model' button in this space so it is not entirely inconsistent :)

[Eldenroot]

I like this change a lot, no wasted space and easier editing/adjusting of points. All UI should be unified across all menus etc., so it could change depending on users feedback.

[philmoz]

After using it on my TX16S for a while I found the flight mode buttons awkward as @JimB40 suggested. I've reverted them back to two rows with larger buttons and scrolling in landscape layout.

[JimB40]

After using it on my TX16S for a while I found the flight mode buttons awkward as @JimB40 suggested. I've reverted them back to two rows with larger buttons and scrolling in landscape layout.

@philmoz I'm brief sometimes, but spent more than 10 years with UI/UX. Handheld touch devices are for decade so there are already best UX/UI best practices for them. UX is not my job ATM but still have some friends :) so I can read reports (like Nielsen) that costs 5k usd.

They may seem not to be important but using them "magically" makes UI user-friendly. Like 85-90% people are right handed, so placing editable content on the right part and preview on the left instantly brings better UX. (Like with a curve edit screen)

I've made part of mockup yesterday based on changes we discuss.
Do you use Figma?

[JimB40]

@philmoz as you do a lot of nice UI changes one more tip.

Whenever you need to split screen (columns layout) start design on horizontal with 3 modules
So split can be

1. 160/160/160 px
2. 320/160 px
3. 160/320 px

Then porting to vertical NV14 that is 320px wide is easier.

Sometimes split has to be different but it's a good starting point.

[philmoz]

@JimB40 Thanks for the tips, will try and keep all that in mind. I have not used Figma, can you post images here to discuss.

[philmoz]

This is how it looks with the preview on the left.

[JimB40]

@philmoz I'd strongly advocate not to use TopBar for editable UI elements.

There is ongoing UI 3.0 sub project. Once we cover all TABs conversion to LVGL it will provide solution to user-case based UI. Simply saying available features will be based on type of model (Plane, Glider, Quad, Heli etc)
TopBar area is intended to serve as information, general navigation & general tab specyfic functions.

If we stay within 'content' area, UI (code) will fit seamlessly. Otherwise fixes will be needed.

Some previews of UI.3.0

[philmoz]

@JimB40 Looks interesting although I'm not sure how the top bar will fit on the NV14 - the middle section with the date etc is the full width of the portrait LCD screen.

[JimB40]

It will 320px wide

[JimB40]

Reviewin & Mockin up Input editing screen.
Can someone check in code what does Trim 'ON" parameter?

So Trim dropdown list has below stated entries
OFF - is to disable trimming feature
ON - ???
T1..T6 (or assigned trim buttton name) - sets desired trim button as the source of trimming (and of course enables trimming)

So what ON is doing?
@pfeerick you're plane pilot :)

[pfeerick]

IIRC
OFF - no trim
ON - trim active (default - i.e. throttle is throttle trim, ail is ail trim, etc)
T# - trim active, some other trim control

[JimB40]

Can we re-code so:

• Trim ON/OFF is check box
• if checkbox is ON default trim button is selected on trim source list - unless user changes to different trim button?

[pfeerick]

Finish that thought... and do what then?

At the moment, the one UI element allows for trim enable/disable/reassign. So now it will be a checkbox, and a choice that is shown when it's ticked (which we now have to reserve space for since there are now two controls)? Don't make me guess what you're thinking ;)

[ulfhedlund]

SE translation:
#define TR_SHOW_ACTIVE "Visa aktiv"