EdgeTX UI 3.0

[JimB40]

Okay since we are almost ready with LVGL implementation it's time to push ETX 3.0 UI.

Below is description of UI concept done last year:

Assumptions & concepts prior to design

1. minimalistic, UI-in-background (data focused)
2. centralized navigation configurable to accomodate various user knowledge (simple/expert)
3. navigation available at any state of OS operation
4. max three clicks (taps) to reach any UI-navigation -tree place
5. use potential of TouchUI
6. Proper breadcrumb that allows user localize within UI-navigation-tree
7. Allow vertical LCD radios to have better navigation

1. UI-in-background (data focused)

So as with other modern OS'es most important information is data. This is already archived by concept of Main-Screens (kind of desktops) that can be populated with various data presenters (widgets or apps). When EdgeTX starts user will see Main-Screen configured to his/her need using different widgets (date/time, timers, radio inputs state, model picture, telemetry values, etc.)

Navigation between Main-Screens is done via:

• PAGE> & PAGE< keys
• swiping left or right with your finger

At this point any UI elements connected with OS features are not visble, focusing on data rather then OS functions.

With one exeption that is System-Bar. Small UI item that can be hidden presenting most important OS-state information such as

• current date/time
• current Main-Screen (desktop) selected
• RC link status
• Radio battery level
• Volume level

Main-Screen with widgets & System-Bar shown

Main-Screen with widgets & System-Bar hidden

2. Main Menu

Main Menu core asset of quick & efficient navigation.
At any moment of using OS user can bring on screen Main Menu that allows to navigate through OS features

There are two ways to access Main Menu

• pressing SYS button
• swiping down with finger starting from top area of LCD screen

Main-Menu opened

UI Elements of Main-Menu

a. EdgeTX Logo

b. Group icons (bigger)

• Radio Setup - all features connected with radio
• Model Setup - configuration & featurtes connected with current selected model
• Models Library (Models Manager) - features allowing models selecting, creating, deleting, labeling etc
• Applications (App Manager) - selecting, browsing, running installed apps
• Monitors - various monitors (channels, outputs, logic switches, sytstem (debug) etc

c. Page icons (smaller)

d. Selected Group & Page name

e. Close Button

Selecting is done via

• roller/dial
• tapping on icon

To close Main-Menu

• press SYS again or press Exit when nothing is selected
• tap Close Button

3. Featues pages

Feature page are now redesigned and standarized

Radio Setup / General Features Page

UI Elements of Features Page

a. Page icon being also Contextual Page Menu Button

On some pages there are features that are connected with whole page ie adding list item or general function like "Add all Trums to Subtrims". To simplify and speed up UX every page can have Contextual Menu with those features

Model Setup / Inputs Features Page with Contextual-Menu visible

b. Breadcrumb
Showing UI-navigation-tree position

c. Close Button
Visible close button that allows page to be closed

As stated before possibility to Main-Menu is active all the time so user can cross-navigate to other feature page (is Monitor) at any moment.

4. Samples of EdgeTX UI 3.0 concept

a. Main-Screens with widgets or Apps

b. Main-Menu navigation

c. Features Pages

Video showing Interactive Simulator

LUA Interactive Simulator

ETX30UI_IMV10.zip

1. Download
2. Unzip
3. Move EdgeTX_30_UI.lua and EXT30UI folder to /SCRIPTS/TOOLS/

Feel free to post comments & feedback.

[jtaylor2]

Please don't have only graphic icons with no text. I'm pretty sure I'm not the only one that mostly doesn't know what the pictures mean and can't remember the layout. It's a pain to have to keep selecting icons until you find the one you want.

[offer-shmuely]

It have, it is just on the top
That save a lot of space

[ScottLangham]

I would like text to be always visible under each icon. Maybe you don't need the text if you are an expert, but is this only being designed for experts or for everybody? It would be annoying to have to select each icon before the text appears. I want the text first so I know which to select.

[offer-shmuely]

Looks promising, and amazing vision!

Hope that the the amount of data presented on the screen will not be reduced and replaced with many spaces.

[jmxp69]

Robert, I will give simulator a go today; however, based on the video, I have a few comments/suggestions:

MDL/SYS
Today, if I want to edit a model I short press the model button and I'm in the model configuration. From what I saw in the video, I would have to press the system button, then scroll to model, press the jog dial, then highlight the desired icon and press the jog dial again. Or swipe down, press model icon. This feels like a regression. I edit models all the time. It is a primary function that should have the least amount of steps. I prefer to get to my model settings with 1 click.

Please consider using the system button long and short press: Long press to drop down the system bar. System Button == System Bar...it makes more sense than Model Button == System Bar??? I probably wouldn't toggle system bar on and off frequently, so I would suggest: Long press SYS for system bar, short press SYS to invoke the pop-up menu for navigation.

SYSTEM BAR
Today the "top bar" allows for widget selection for about 70% of the top bar. Left is icon, right is "system tray" with time, logging indicator, RF, volume, etc. I submit the entire bar should be widget based.

For example, I don't care what time it is while I'm flying. I do care what VBAT says while flying. I would like to have data I care most about on the top bar, not what the radio thinks I should care most about. I'm not suggesting there isn't value in time--it is important for logging. My point is the time means nothing to me while I'm in the air. VBAT does. RQLY does. TPWR does. You may care more about number of satellites and distance to home. Others might care what flight mode they're in.

Of course, those widgets should include time, volume indicator, transmitter battery voltage, sd logging indicator, etc...FYI I do rely on the SD logging indicator and the way it's done today is quite effective.

Finally, I think the number of fields in the system bar should be defined by user. Maybe my system bar only needs to show two widgets. Maybe four.

COLORS
Ideally the System Menu is themeable or the user can select colors. If not, color choices should be evaluated out doors on a fully sunny day to ensure any hard coded system colors are most visible outside. I get concerned when I see a dark background with slightly less dark text/icons. That could be challenging to see outside on a bright day.

UNIFICATION
I do like the idea of unifying the "menu". That makes perfect sense to me, but I still believe the MDL button should be a shortcut directly to model settings.

Thanks for your work on this. I hope my comments are helpful.

[JimB40]

Thanks John for feedback.

1. MDL key
   Of course MDL key binding is my mistake coding SIM. Just assigned first key to show possibility to show/hide System-Bar.
   MDL key binding will stay as it is with short press leading to Model Setup and long press leading to Manage Models.
   So system-Bar key binding is to be defined. It may be long SYS press but then I think this should be reserved for APPS key shortcut. Things like Config LUA scripts are used very frequently (ELRS, BetaFlight, TBS Agent) so it speeds up doing task. Maybe TELEM key.
   But frankly speaking I would see in 3.0 config option for SYS,MDL and TELE keys short & long press, with list of most used places to go when short or long key event is recieved.

2. System bar.
   Fact is that what is currently visible on TopBar (Date, Radio Voltage, RClink status etc) can be presented as widget. Reason for current TopBar was Feature Pages selection (icons) that will now be transferred to Main-Menu.

User will have whole LCD to configure Main Screen (desktop) as needed. If Date & time is needed you place widget for that, if GPS logging status or Sat numbers is needed there is widget for that. Maybe instead 4 or 5 one mulit-purpose configurable widget canl be created, Plus default predfined Main-Screen layout populated with widgets needed for particular model. Plane/Multi Rotor/Heli. As an example drone pilots do not use trims so this UI element is not needed.

Then System-Bar UI element that can be quickly displayed as overlay. To check System data rather then Flight data. So for example if there is a case that Main Screen doesn't include Radio Voltage you can quiclky display it an overlay on currently displayed UI with this system data not being forced to do any configuration. Another case is when you do some configuration on Feature Pageand you want quickly check Radio voltage. etc

3. Colors
   There is no problem to unify System bar to mach Theme, but regarding Main-Menu I will strongly lobby for B&W as it is for maximum contrast and readability.

[pfeerick]

regarding Main-Menu I will strongly lobby for B&W as it is for maximum contrast and readability.

Are there any issues regarding colour-blindness, etc, there? As I would instead lobbly for a specific set of colour constants for the menu instead, allowing it to default to B&W, but still allowing user control over the colours. Thus preventing the "How dare you say that I can colour everything else, BUT the main menu" argument 😆

[jmxp69]

Sounds good Robert. I cannot wait to see this unfold. I'm happy to be a guinea pig and test anything.

[offer-shmuely]

Looks great Robert!
Did you tried it outside on the sun?
I found out that sometime (on the LogViewer for example) black background work much better on the sun

[pfeerick]

I've not tried the simulator Lua yet, but I have watched the video walkthrough. I take it that in order to navigate to other screens in at the same level (i.e. inputs/mixes/outputs, or setup/trainer/hardware) you need to keep bringing the main menu up? Have you thought about instead of the top left corner being options for the current screen, for it to be a menu for other screens to switch to? I'm not sure there are many screens where whole page options are actually needed - they are mostly all contextual so could be brought up with long press/long enter like they are now.

Can we still navigate from page to page at the same level with the page hard keys? As this seems to sacrifice some of the ease of hard key navigation (as well as where previous and next would take you since the tab bar is now gone) in preference to touch navigation. i.e. if I want to go from inputs to mixes to outputs with the current model, it's one key press (page) or one tap of the tab. This would be a swipe, and then a tap, each time I want to change "tabs"? All in all, I generally like the concept and am looking forward to seeing what other feedback you get.

[JimB40]

1. Yes you can use PAGE> & PAGE< and swipe left & right to navigate through Feature Pages within same group. No need to bring Main-Menu. Forogt to mention it in video

2. Context menu valid point. Not so much functions. Adding item to a list but that can be done via pop-up (ENTER long press) instead this + button that needs scrolling.

Concept to discuss and test so we include what works best.

[jtaylor2]

I took the simulator to the field yesterday on my tx16s and showed it to 4 other tx16s users. All fixed wing and over age 60. I didn't know the answer the some questions that would make a difference so will ask here along with their comments.

1. First question was will this new UI be be required to stay current with firmware upgrades or an option? I didn't know but said probably required with edgeTX 3.0. Which brought up question 2.

2. Will all my model screens need reprogrammed? I didn't know, said a lot depended on the answer to my question 3 about top bar/status bar. If model screens need redone everybody disliked it already.

3. Everyone thought the status bar was worthless. Too small to read in good light let alone bright sunlight at the field and didn't necessarily contain the information they wanted anyway. They all (including me) like the top bar the way it is now. I told them the status bar can be turned off and they asked if it was would the top bar widgets be displayed as they are now or would there be a widget bar the size of the top bar to replace it. And again the question if the top bar goes away will my top bar widgets be converted to the new gui or will I have to reprogram 30 model's screens.

4. Picture icons with no text is a big deal to some (including me) and not to others. Even Microsoft and Android with their minimalist interfaces put text to tell you what the icon does. And seem to be backing off the boring black and white only a little.

Everyone likes the top bar the way it is now with the left touch area to enter and exit screens, widgets for the information they want and the system information on the right side and universally think doing away with it is a big mistake.

And the big question, will all my model screens need to be redone?

Question from most was the interface is very good as it is why are they changing it. My tongue in cheek answer was the drone kids want it to look like a smartphone.

Jim

[pfeerick]

1. Whatever the final design choice is, this is likely the be the default UI for 3.0 - it is going to be too hard to maintain two different UI types side-by-side.

2. The goal will be no - with any redesign we do, being able to bring your existing models and settings along with you without requiring you to redo anything is a major priority. Sometimes there will be changes to settings that make that not possible to do (i.e. new structure is incompatible with old one), but where-ever possible it will be migrated and kept to a minimum.

3. I generally agree... the proposed top bar is nice... if you like modern phone interface design. However, this is not a phone, and that design philology is not always transferable to other applications. I don't see why the top bar could not be optionally as big as the current one - i.e. two size options.

4. I'm on the fence myself with this... I think I know what JimB40 is trying to do with the icons, but I'm not sure it will work. Just about every icon-driven interface uses a combination of icons with text underneath or beside it, so that you don't need to remember what all these icons mean. After all, we have enough other things to do and remember in our lives without having to remember what every silly little icon means. Now, for key navigation, it's not such an issue, as the icon text is shown as you move from icon to icon - although that still means depending on how much you use the radio, it may be a bit of a "discovery" process rather than an decisive "I want the model setup, inputs screen". With touch, I'm still not sure how this will work... one tap to get the title, a second one to open it perhaps?

The main reason this is being proposed is to try and make things easier to use... as the current UI has sort of been put together bit by bit, rather than following a single unified design philosophy. As we get more input/feedback/discussion, things should get clearer, and changes can be made to make the interface concept more usable for all.

[JimB40]

My tongue in cheek answer was the drone kids want it to look like a smartphone.

Thanks for compliment. I'm 54. Racing drones, flying planes and bashing RC cars, so feeleing like a kid again.

1. UI is always part of OS. So there is no question if we can have Windows 10 interface using Windows 11.
   I have still Win10 on my HTPC and it serves well and does the job.

2. Peter you say goal will be no, but ditching TopBar in favor of bigger system widget being part of Main Screen destop will require to switch on System widget that shows RC LInk, TX Batt or whatever now is hardcoded into this topbar.

3. Yes we do modernize OS.
   I was reclutant to use Touch few years ago but technology is getting better and better. I don't know why everyone is reffering to mobiles. Touch screens are now mature Human Input Interface and I swipe nowadays in my car or in the morning preparing coffee on newest Krups coffee-maker. If done properly it can be very efficient particularly combined with old-good-physical inputs.
   If proof is needed - switch off in 2.9 on-screen keyboard and wait for reaction. People used roller to enter text so what is a big deal?
   Anyway with tech advancing goal is to include popular solution as an option and lot of thinking goes to retain key-inputs interface as good as it was.

4. What was done in concept is that icons now are centralized instead of being part of Feature Page. From the day one of Horus OpenTX version interface has icons that have no decscription. Nobody complains much but surely can be better. Adding desctiptive text we have to use small font (not good idea) strech UI to the point when scrolling is needed (loosing efficiency). Pro active approach will be to code that description is shown once you put finger on icon with selection action when its released. Then user can sneak peak icon meaning without selecting.

[philmoz]

I have a few additional concerns:

• Today swiping (to scroll) is finicky and prone to unexpectedly selecting an item or changing a setting. If this persists to more general swipe gestures it will make for a poor UX.
• Swiping down to pop up a menu feels clunky and not very intuitive - this is not how swiping on phones works.
• Swiping on phones has fade or slide transitions between old and new screens. I doubt very much we would have the horsepower to implement smooth transitions, and I'm not sure swiping with abrupt jumps to new screens would feel smooth, especially with the screens that take longer to build and render. There would be a noticeable delay between the end of he swipe and the screen changing - again leading to a poor UX.
• The main screen UI elements look pretty; but will be more expensive to draw, particularly the circular dial/slider elements. This will slow down the UI which is already less than brisk. Also the dial/slider elements take up a lot of space for very little information presented.

[pfeerick]

Swiping down to pop up a menu feels clunky and not very intuitive - this is not how swiping on phones works.

Just to counter that... what about the Android notifications/"quick settings" drawer? 😝 And IIRC iOS also used a similar mechanism at one point... not sure about the current versions.

But yes, we're not going to get nice animations/transitions - especially on radios like the TX16S which need the display rotated (which has to be done in software). And I do wonder how reliable we can get swiping. It's annoying enough when it doesn't work on a phone, I can see more than a few radios being thrown in ponds (I'm not joking... I've had the privilege of seeing an owner of a new Futaba radio a hairs breath from chucking it in the lake due to frustration with the UX... he had to be talked down from throwing it! 😮 ). That's why, at minimum for radios with hardware keys, whatever the OS swipe actions do, hardware keys would need to be able to mimic. That is a non-negotiable requirement. Can't help touch-only radios... it's a hazard of them being touch-based/centric.

[JimB40]

1. Have to disagree about swipe. Swipe is one of the most intuitive touch UI gesture. So swipe is good and it's bad implementation that makes it feel wrong. Swiping to scroll icons on NV14 simply sucks. Overusing swipe is bad practice but, edge screen "hot" area you start swipe can be done propely. Gave to Radio wth SIM to my relative (23 yrs old) just saying screen has touch interface. First thing he did was to swipe left, right up and down.

And let's be proactive ... what is alternative, particularly on NV14/EL14? This small icon to tap squezeed into a corner is not.

2. Why you insist on those animations? Somene did TopBar animation while switching Main-Screens and that's the reason I've stopped to use swipe in favor of PAGE keys that do change it without any fancy stuff immediatly..
   We have what we have. In 2-3 years radio MCU horsepower will be better and then it is the time for animations.

3. As I wrote visualised wigets are my free-mind-design. It's not core part of concept and I can live with old not-so pretty old ones. ;)
   Most importannt is to give good Main-Screen layouts. People can bring nice solutions like those LUA reactive widgets based on libGUI that have everything C++ widgets should have, just nobody had time or interest to do it :)

[offer-shmuely]

just nobody had time or interest to do it :)
LogViewer use them :-)
I hope to enter them to the plane wizard on the next round (this round is for capabilities)

[philmoz]

I'm not saying swipe gestures are bad; I'm questioning the ability to actually implement this given the limitations of the hardware/software. Swiping becomes the primary navigation for radios without hardware buttons - if the implementation sucks it will be a terrible UX. Swiping with no immediate feedback and a noticeable delay before the screen changes will be a bad experience for users; but this is exactly what will happen with the current radios. Until and unless we can find ways to vastly improve the current UI page build/render times, and fix the whole selecting instead of scrolling problem then a UI that relies on gestures will be problematic.

Your design is great - it is the ability to implement it that I have concerns with.

[JimB40]

IMHO we should try to implement it with some simplifications (no fancy animation). We are Edge ;)
Key input navigation will be retained and working well on TX16S and others key equiped radios while NV & EL will benefit.
TouchUI is now and will be for quite long secondary input method.
For those who don't like TouchUI we can code "Touch UI OFF" and display "Don't touch" ;)

[factoryroll]

I think it would be great to be able to switch the touch UI off, and to reclaim some of the on-screen information lost in previous UI changes. I'd suggested this back in #2062

[richardclli]

I have given the 3.0 UI concept to a China user group to comment. Summarizing their concern is:

1. Need to works for both horizontal and vertical screen layouts
2. Too small widget for information display is not easy to read
3. It will be good to minimize the no. of tap/swipe operation to access a function.
4. Full touch screen support is necessary (some radio do not have physical buttons for control and need trim emulation.

[JimB40]

Thank you Richard

1. Will work well both on Horizontal and Vertical. Both layouts was in my mind from very beggining.

2. Seems like System Bar in current form has to be changed (visually) or ditched at all

3. I did tap counting and numbers are equal or lower.
   Plus there are cases with huge reduce of taps/clicks (ie opening monitor while editing something)

4. Convince @pfeerick ;) this will really render NV/EL as efficient tool. As I wrote TouchUI is still secondary method.
   Trim hats/joysticks as menu navigation aids on NV14 #904
   OS wide key emulation for NV14/EL18 #3202

[mhotar]

Hello all. I was curious if it is even possible to fit icons so they are click friendly and have enough space for text. Here you can see how it came out. It is not so bad I think, It may even fit both display orientations. Another question is if 10 items is enough :)

[mhotar]

A bit more realistic serie follows. I would personally prefer Robert's version with tabs/items if it could have text description.

[arthurson]

icons should be consistent in one side, otherwise my eyes need jump all the time

[offer-shmuely]

Looks very nice & modern
On the “model setup” sample, i am missing a circle around the buttons, it confusing when we need to press

[pacogalvan]

Hi, It is very good!!!
I will check the simulation on my TX16S.

Only one question, I have several radios with w/b screen, as RM pocket, Jumper T20, Taranis QX7.
What are the changes in theses radios using EdgeTX 3.0??
Pardon for my wrong English!!!!