iNavFlight
Dark theme, UI elements unification, UX enhancements
THIS IS DRAFT, please do not merge since some parts of this huge PR is still in progress.
Please Note: I didn't test these changes in Windows, because I do not have this OS, if there are any problems please send me screenshots.
I'm going to write detailed docs for all changes. But for now this short description is: Mostly all changes are cosmetic, the biggest UX changes were in Failsafe tab (simplified visual part). In this PR I use bootstrap sass framework for unification UI elements like buttons, tables, lists, etc. Also, it supports dark themes out of the box. However, developers still can use regular CSS files as they used to be.
Apart from Dark/Light theme, I've added an inverted sidebar & header according to this reasonable request.
Some screenshots:
[27 October '24]
Ready for testing tabs:
- Welcome
- Mission Control
- Firmware Flasher
- SITL [25 October '24]
- Status
- Calibration
- Mixer [27 October '24]
- Outputs [27 October '24]
- Ports
- Configuration
- Failsafe
- Tuning [24 October '24]
- Advanced Tuning
- Programming [24 October '24]
- Receiver
- Modes
- Adjustments
- GPS
- Alignment Tool
- OSD [25 October '24]
- LED Strip
- Sensors
- Tethered Logging
- Blackbox
- CLI
- Options
Added responsive "screen" in the OSD tab
Changed behavior of "helpicon" when it is actually a link (In my opinion it was not obvious that this is the external link)
Changed behavior of "Highlight profiles" checkbox, now it works without "reloading" of page
Simplified Failsafe tab UI, now you do not see any inputs if they do not needed for current procedure
Mobile friendly design (at least elements should not be overlapping each other)
Unified styles and design tokens across the app
And a lot of other fixes/improvements, everything will be described in docs
I appreciate the UI changes you've been working on. Looks like a lot of small positive changes! To clarify since you're talking about a mobile-friendly design, will this become a web-app like betaflight's configurator? or is it still going to be a standalone app only?
@trailx This is still a standalone app, when I say "mobile friendly" I mean it looks ok and is usable on narrow screens. In other words, It has a responsive design.
@bfmvsa I gotcha, I wasn't sure if there was something I had missed. There are often times when I use it half screen, so just being more responsive to window size will be nice!
Since you're in there, one idea that came up in a discussion was creating a button in the blackbox tab that would put the FC into MSC mode. Betaflight has this, and it's handy rather than having to look it up on GitHub every time. This seems like a relatively easy add and would bring more attention to the MSC function. Since you're working on the UI, you seemed like the best person to bring this up to. Thanks for the consideration!
@trailx It looks like somebody was trying to add this button (at least it is presented on the tab). But if I am not mistaken this button is not working (always disabled and there are no any click handlers for this button), also this button is added only for SD cards, need it also for onboard dataflash chip.
As a part of this huge PR I decided to not change the current logic a lot, but in the future your suggestion will be implemented, this is already in my todo list :)
@sensei-hacker @trailx Just updated the PR, now Everything is ready from my side. I probably will do some commits, but in general, it is ready for testing.
I'm on a windows machine for reference, running a Holybro H7 with a fixed wing configured on one of the nightly releases of 8.0. Since this PR was all about UI updates, my plan was to note issues with the UI generally. I recognize that not all of these issues are likely due to your code, but I have no better place for these notes.
I'll try to continue looking through this a little more when I have time, but here are a few thoughts, I tried to prioritize the list. I'll also try to grab some screen shots when I can as you mentioned on discord.
-
Code Error: In the Advanced tuning tab, in the RTH settings box, the "climb before RTH" cell has an error in the help icon code. Likely just a missed '<'
-
Code Error: On the alignment tool tab, on the second box on the bottom right, there's some text that is struck through "align mag roll, align mag pitch, align mag yaw". I don't think this is supposed to be there.
-
Code Error: On the logic programming tab, the GVARS listed across the header are all named GVAR 0, despite them actually being linked correctly with GVAR 0-7, possibly a copy paste error in the code?
-
Bug: I wasn't seeing any of the "changing profile parameters" highlighted colors so went to look in the menu. It was toggled 'on' by default, but it wasn't showing the color coding of the parameters. I had to toggle the setting in the menu off then on to have the input box color highlights actually display.
-
Responsive formatting: The mixer tab output mapping table is too long. S14 starts falling off of the table at about 75% screen width for me (I'm on a 1080 screen, so this is likely at around 750px window width). This may be fine, but it would be nice to have it all display on the smallest width screen.
-
Responsive formatting: On the top menu bar, I noticed that the 'control profile' and 'battery profile' drop-down menus aren't wide enough to display the full name of the profile: 'profile 1'. It's clipping off half of the control profile number. Increase the drop down button width by a few pixels.
-
Functionality issue: My potato of a workshop computer doesn't like the animation of the 'showing' and 'hiding' of the log at the top of the screen. It's motion is jerky and clipped. Likely its just an issue of my potato, but I feel like animations like this generally aren't a necessity in my opinion.
These are the majority of the more necessary notes I had. I'll try to separate these notes from more "general UI" suggestion notes.
Edited to add images.
General UI thoughts (for lack of a better place to put them):
First, I feel like we should standardize on a set of colors for things. In some places we use blue as good, sometimes red as good, sometimes yellow as an indicator, etc. As a very basic human factors guideline: Red = bad or stop Yellow = caution, or "working" / something is happening Green = good, positive outcome, or done Blue = notice / informational / status
I bring this up because off the bat, I haven't flashed a board in nearly a year, and as the flashing was occurring, my eye kept being drawn to the red bar creeping across the screen. It made me think the flashing had failed, when it was just doing normal flashing stuff. Even when it completed, it turned blue, which is an interesting choice. In this case, I believe the status bar shouldn't go red unless the flashing failed in some way. Blue should be the default state. Yellow or blue when its flashing the board, and the bar would turn green upon a successful flash, or red if flashing failed.
This is similar to the calibration tab. As you are going through the calibration process, the checkmarks should turn green to indicate successful calibration of the various orientations, not blue. Green would be clearly marking a success.
Continuing the color coding theme, along the top menu there are status symbols for the various sensors. I turning those red if they have bad data makes sense, but why is the default color blue if they are operating correctly? Again, for clarity it may make sense to turn these green rather than blue. I hate to admit it, but it took me years to understand that these colors signified anything.
The Mixer tab has its own color coordination issues. There are two sets of colors on this page. (This could probably become its own issue report, but I'll do it here anyway.) Timers are colored pastel shades, and Servos are colored with bold primaries. These are super confusing especially considering you can't see the servo color coding image at the top and the servo table at the same time. A lot of this could be helped by adding the servo colors to the bottom half of the output mapping table, but its still confusing calling the pins S1, S2, S3 and not being extra clear that these are not "servo 1", "servo 2", and "servo 3". Would this be worth adding a pin column to the motor mixer and servo mixer tables to include S1, S2, S5, S6, S7 etc? I'd mark this up but my markup software is super rudamentary.
Continuing the discussion on color coding, I really appreciate that the battery and control profiles have highlighted boxes that show that these change according to the profile in use. The problem is that I didn't understand this until very recently. To me, this looks like these are being highlighted because I did something wrong, or there's some error.
Likewise, the green control profile boxes look to be saying "I'm a good number" or something positive. Having the color coding with the dropdown boxes at the top bar does help clarify this, but its a loose association. Could we be more overt? Like place a little battery symbol with a 1, 2, or 3 next to the text box instead? Then at least you could roll over it and get a floating tool tip. Likewise, for the control profile specific text boxes, could we place the "tuning" symbol with a little 1, 2 or 3 next to the text box?
Tuning tab -> rates and expo:
I just noticed the second box should probably be "Stabilized Expo", not "Stabilized Rates" again.
Along our previous theme of color coding, it kinda makes sense that the stabilized boxes are both blue. But why are the Manual Rates and Manual Expo tables different colors? Make them both yellow.
Finally, on the OSD tab, why are some parameter element names highlighted blue? Hovering gives no indication. What does this highlight and why?
Thanks for listening.
If I'm being brutally honest. Reducing the height of the top bar has made it look extremely cluttered. I much prefer the taller top bar and it's layout. The sensors were easier to read (old icons were better). The old connect/disconnect button is also something I don't think should change. The rectangle button is just boring. The original button is classic and looks cooler. Plus the Configurator and Firmware version numbers shown in the top bar are extremely useful.
IMHO, the top bar needs to go back to looking more contemporary.
General UI thoughts (for lack of a better place to put them):
First, I feel like we should standardize on a set of colors for things. In some places we use blue as good, sometimes red as good, sometimes yellow as an indicator, etc. As a very basic human factors guideline: Red = bad or stop Yellow = caution, or "working" / something is happening Green = good, positive outcome, or done Blue = notice / informational / status
INAV's main colour is blue. So everything you think of as green, should be blue. Red should be used for bad/stop/danger. Yellow should be used for warning/caution. Green is not really used in configurator other than for distinguishing matching entities, like the on the mixer page when green will signify stabilised roll, for example.
I bring this up because off the bat, I haven't flashed a board in nearly a year, and as the flashing was occurring, my eye kept being drawn to the red bar creeping across the screen. It made me think the flashing had failed, when it was just doing normal flashing stuff. Even when it completed, it turned blue, which is an interesting choice. In this case, I believe the status bar shouldn't go red unless the flashing failed in some way. Blue should be the default state. Yellow or blue when its flashing the board, and the bar would turn green upon a successful flash, or red if flashing failed.
That is a fair comment. Perhaps the bar should be blue unless there is an error.
This is similar to the calibration tab. As you are going through the calibration process, the checkmarks should turn green to indicate successful calibration of the various orientations, not blue. Green would be clearly marking a success.
No, blue is perfectly acceptable here. It is the primary colour of Configurator.
Continuing the color coding theme, along the top menu there are status symbols for the various sensors. I turning those red if they have bad data makes sense, but why is the default color blue if they are operating correctly? Again, for clarity it may make sense to turn these green rather than blue. I hate to admit it, but it took me years to understand that these colors signified anything.
Again, INAV's primary colour is blue. So blue for operating normally is perfectly fine.
The Mixer tab has its own color coordination issues. There are two sets of colors on this page. (This could probably become its own issue report, but I'll do it here anyway.) Timers are colored pastel shades, and Servos are colored with bold primaries. These are super confusing especially considering you can't see the servo color coding image at the top and the servo table at the same time. A lot of this could be helped by adding the servo colors to the bottom half of the output mapping table, but its still confusing calling the pins S1, S2, S3 and not being extra clear that these are not "servo 1", "servo 2", and "servo 3". Would this be worth adding a pin column to the motor mixer and servo mixer tables to include S1, S2, S5, S6, S7 etc? I'd mark this up but my markup software is super rudamentary.
With the mixer. You do see the servo colour coding on the image at the top. If this is not in this updated UI PR it would need to be added,
I do agree that the servo colour coding also appearing on the output mapping table would also be useful.
Continuing the discussion on color coding, I really appreciate that the battery and control profiles have highlighted boxes that show that these change according to the profile in use. The problem is that I didn't understand this until very recently. To me, this looks like these are being highlighted because I did something wrong, or there's some error.
Likewise, the green control profile boxes look to be saying "I'm a good number" or something positive. Having the color coding with the dropdown boxes at the top bar does help clarify this, but its a loose association. Could we be more overt? Like place a little battery symbol with a 1, 2, or 3 next to the text box instead? Then at least you could roll over it and get a floating tool tip. Likewise, for the control profile specific text boxes, could we place the "tuning" symbol with a little 1, 2 or 3 next to the text box?
Not understanding about the colour coding on the profiles is really a documentation issue. I don't think using colour is a problem. Icons could also be misinterpreted. As a battery icon for a battery parameter could just be taken that it is something to do with batteries. Without the documentation explaining that it relates to profiles leaves it open to interpretation.
Finally, on the OSD tab, why are some parameter element names highlighted blue? Hovering gives no indication. What does this highlight and why?
To be honest. I've never known why some OSD elements have blue text and the rest are black. Again, an issue with lack of documentation. I'm sure it was done for a reason. Perhaps recommended elements to have on your OSD? Though the elements that have blue text doesn't reflect that. The code doesn't help either. It just has a css class called blue.
To be honest. I've never known why some OSD elements have blue text and the rest are black. Again, an issue with lack of documentation. I'm sure it was done for a reason. Perhaps recommended elements to have on your OSD? Though the elements that have blue text doesn't reflect that. The code doesn't help either. It just has a css class called blue.
This is for the stock DJI HD OSD (Beataflight compatible).
Elements in blue font are displayed in the craft name element.
General UI thoughts (for lack of a better place to put them): First, I feel like we should standardize on a set of colors for things. In some places we use blue as good, sometimes red as good, sometimes yellow as an indicator, etc. As a very basic human factors guideline: Red = bad or stop Yellow = caution, or "working" / something is happening Green = good, positive outcome, or done Blue = notice / informational / status
INAV's main colour is blue. So everything you think of as green, should be blue. Red should be used for bad/stop/danger. Yellow should be used for warning/caution. Green is not really used in configurator other than for distinguishing matching entities, like the on the mixer page when green will signify stabilised roll, for example.
I get that the INAV branding color is blue, but that doesn't override good UI practice for functional indication to a user. I run our human factors team at work, and the stoplight analogy is the base rule for status indicator colors. Can you imagine if all of your dash warning lights were blue just because you were driving a BMW? I'm not talking about getting rid of all blue accents, thats a UI branding choice, but status indicators are a different thing. Blue is a fine indicator color for informational items that are not indicating good or bad.
There are lots of internet design guides for functional indicator colors that cover this convention: https://carbondesignsystem.com/patterns/status-indicator-pattern/#status-palette https://medium.com/eightshapes-llc/color-in-design-systems-a1c80f65fa3#:~:text=Most%20systems%20reserve%20a%20certain,challenge%20quickly%20and%20moving%20on.
I bring this up because off the bat, I haven't flashed a board in nearly a year, and as the flashing was occurring, my eye kept being drawn to the red bar creeping across the screen. It made me think the flashing had failed, when it was just doing normal flashing stuff. Even when it completed, it turned blue, which is an interesting choice. In this case, I believe the status bar shouldn't go red unless the flashing failed in some way. Blue should be the default state. Yellow or blue when its flashing the board, and the bar would turn green upon a successful flash, or red if flashing failed.
That is a fair comment. Perhaps the bar should be blue unless there is an error.
That would probably be better, but I still think if its actively doing something, yellow isn't a bad indicator color. You probably want some caution while its flashing because you don't want to disrupt the flash. Green to indicate a successful flash also makes a lot of sense to me.
This is similar to the calibration tab. As you are going through the calibration process, the checkmarks should turn green to indicate successful calibration of the various orientations, not blue. Green would be clearly marking a success.
No, blue is perfectly acceptable here. It is the primary colour of Configurator.
But if everything is blue, then nothing is indicating anything. The blue probably isn't going to confuse anyone here due to the checkmark, but this sort of consistency would be nice.
Continuing the color coding theme, along the top menu there are status symbols for the various sensors. I turning those red if they have bad data makes sense, but why is the default color blue if they are operating correctly? Again, for clarity it may make sense to turn these green rather than blue. I hate to admit it, but it took me years to understand that these colors signified anything.
Again, INAV's primary colour is blue. So blue for operating normally is perfectly fine.
My issue is that you may understand blue is good here because you've known what it meant. A new user doesn't understand the color coding that blue = good. If we're stuck on the blue color, then can we at least add some hover text or something like that?
The Mixer tab has its own color coordination issues. There are two sets of colors on this page. (This could probably become its own issue report, but I'll do it here anyway.) Timers are colored pastel shades, and Servos are colored with bold primaries. These are super confusing especially considering you can't see the servo color coding image at the top and the servo table at the same time. A lot of this could be helped by adding the servo colors to the bottom half of the output mapping table, but its still confusing calling the pins S1, S2, S3 and not being extra clear that these are not "servo 1", "servo 2", and "servo 3". Would this be worth adding a pin column to the motor mixer and servo mixer tables to include S1, S2, S5, S6, S7 etc? I'd mark this up but my markup software is super rudamentary.
With the mixer. You do see the servo colour coding on the image at the top. If this is not in this updated UI PR it would need to be added,
I do agree that the servo colour coding also appearing on the output mapping table would also be useful.
It is indeed there on the new PR, but you can't actually see it at the same time as the Servo colors due to the window height. You used to be able to see them at the same time which was helpful. Currently Timer 12's color is awfully close to S3, and without seeing the Servo table at the same time, its not obvious that this isn't the proper conclusion.
Continuing the discussion on color coding, I really appreciate that the battery and control profiles have highlighted boxes that show that these change according to the profile in use. The problem is that I didn't understand this until very recently. To me, this looks like these are being highlighted because I did something wrong, or there's some error.
Not understanding about the colour coding on the profiles is really a documentation issue. I don't think using colour is a problem. Icons could also be misinterpreted. As a battery icon for a battery parameter could just be taken that it is something to do with batteries. Without the documentation explaining that it relates to profiles leaves it open to interpretation.
Its a good idea never to solely rely on color as an indicator because 1 in 12 men have some form of color blindness. Even stop lights aren't totally reliant on color, since you can also determine position (bottom, middle, top) of the illuminated light. Symbols can be correlated more clearly, especially if you can provide some sort of hover text functionality to help explain it. If we utilize the same symbol for the profile selection dropdowns, and the parameters, it should help a lot with disambiguation.
I literally had no idea why these parameters were different colors until about a month ago, so I'm quite certain that the current color coordination doesn't work.
Finally, on the OSD tab, why are some parameter element names highlighted blue? Hovering gives no indication. What does this highlight and why?
To be honest. I've never known why some OSD elements have blue text and the rest are black. Again, an issue with lack of documentation. I'm sure it was done for a reason. Perhaps recommended elements to have on your OSD? Though the elements that have blue text doesn't reflect that. The code doesn't help either. It just has a css class called blue.
Thanks @Scavanger for the explanation here. I don't fly DJI, so I never would have found this. Can we make it so these elements only turn blue when that toggle is selected? And again - a hover tooltip on the blue elements would be great to help explain this functionality.
@trailx That's awesome you know about these things and pay attention to them, from running the human factors team at your job. Your input could surely be valuable. Currently the developers are all programmers, and we aren't always particularly good at interfacing with actual human beings. :)
Knowing humans, and the topic of making things clear and avoiding confusion: As you know, to make things clear and understandable, it's helpful to avoid having two different conversations at once. Or in a UI, of there are a bunch of settings related to two different features and functions, you would have two different pages / sections - one for each. That would be much more clear than mixing two different things together.
Your input is valuable, the topic you've brought up is worth attention. I don't want it getting lost in some confusion. So please, make a Discussion for that topic. Any colors or other factors that are in the existing Configurator are a separate topic from this PR. I don't want that getting lost by putting it here in this PR that's going to be closed soon. Any colors or other things you see in the existing Configurator aren't part of this PR.l, so we should keep those open in a discussion that stays open after this PR is closed.
Since this is in its way to be closed, let's use these comments to discuss this PR.
Thanks.
@sensei-hacker I'm not saying I'm an expert, and I'm no psychologist, I struggle to understand humans too.
With this PR being general UI and UX enhancements, I didn't know exactly where to draw the line. I believe most of the things in my first review comment are related to this PR, so I'll make a discussion for some of the things in my second comment. Good suggestion.
Hi guys, thank you for your comments, and sorry for the delays from my side. @MrD-RC
If I'm being brutally honest
This is what we actually need.
I much prefer the taller top bar and it's layout.
The problem with the existing topbar is that it's hard to put everything correctly on the narrow screens (or when the configurator is opened at half of the monitor). On the narrow screen we need 2 rows for topbar layout to put everything correctly, and if we 2 tall rows it will be too tall in that case.
The rectangle button is just boring.
The connect button is aligned with the other buttons and the general design of this PR. We can put some icon there, but I'm not sure the rounded button will look good in the current implementation of the configurator.
Plus the Configurator and Firmware version numbers shown in the top bar are extremely useful.
I've moved this text to the right bottom corner of the configurator to save some space in the topbar. But we can try to revert these changes somehow.
@trailx Regarding your comments, I'll check it and will get back to you. Thank you for your work!
@MrD-RC So your suggestion is to revert everything in the topbar as it used to be? I'm asking because I want to know what I have to do to fulfill your expectations.
@bfmvsa Honestly yes. I think the original top bar looked better and cleaner.
I understand your comments. But to me some things are trying to fix non-issues. Or at least things that should be compromises.
For example.
The problem with the existing topbar is that it's hard to put everything correctly on the narrow screens (or when the configurator is opened at half of the monitor). On the narrow screen we need 2 rows for topbar layout to put everything correctly, and if we 2 tall rows it will be too tall in that case.
Does this really matter? It shouldn't be used at less than 1024px wide. If someone has a small monitor they should just run at full screen. Configurator isn't made for smartphones. It would probably be fine on tablets in landscape orientation. But again, it's made for desktops and laptops.
The other thing is if someone chooses to run Configurator at a narrow with. There will need to be compromises. There are no free lunches. This could mean that they lose a little vertical retail as the top bar needs to be higher.
Or we could simply hide some aspects of the top bar to keep it tidy. For example, the sensors block could disappear when the screen is less than 800px (or whatever the limit is).
I think having a compromise when the application is being used in an unintended situation. Is better than a compromise all the time, so that it can run under those circumstances.
@MrD-RC
If I'm being brutally honest
This is what we actually need.
👍🏻
The rectangle button is just boring.
The connect button is aligned with the other buttons and the general design of this PR. We can put some icon there, but I'm not sure the rounded button will look good in the current implementation of the configurator.
The connect button is a special button. It doesn't need to match the "Save & Reboot" button, for example. It can be individual. I think it looks great in the current implementation. I don't see why it wouldn't in these changes.
Plus the Configurator and Firmware version numbers shown in the top bar are extremely useful.
I've moved this text to the right bottom corner of the configurator to save some space in the topbar. But we can try to revert these changes somehow.
I think it was better where it was. It was also more obvious what version was for which part. This is important, especially for newbies.
@MrD-RC FYI, I want to continue working on this PR after v9 is released. Unfortunately, it took me a lot of time to keep the PR in working condition due to merged changes every few days (I need to resolve merge conflicts manualy often, especially in HTML files).