New data structure for UI

[JimB40]

Since we are prior to release 2.4 these changes to drop-downs should reflect it and make finding proper firmware easier

So first dropdown should be fairly simple

1. Main or Releases
2. Development

In case of selecting 1. Main second dropdown should show only releases eg. 2.4, 2.4.1, 2.4.2 etc with sorting from the latest. Name should be descriptive like EdgeTX release 2.4.0

In case of selecting 2. Development there should be additional dropdown
So second dropdown would have ‘type of development firmware’ like: Nightlies, ‘Branch name 1’, ‘Branch name 2’ etc
Then third dropdown will have list of firmwares. Name should have creation timestamp and hex firmware identifier

Idea behind is that common user will not see several dev firmwares until he/she switches first dropdown to 2.Development, the we can have short info those firmwares may be unstable

[CoderElectronics]

So I just updated to UI to make this much simpler, take a look and see what you think!

I like the approach you suggest and i may end up moving to that design in the future

[pfeerick]

This can probably be closed now as there is a filter in place ;)

[JimB40]

Hey @CoderElectronics. I've downloaded today last ver of flasher. Good work.
Few minor adjustments

1. Advanced Mode should be OFF by default

• We target non-advanced users primarily

2. Nighly & RC should have own 'Branch'

• Writing branch I don't actually mean GH thing but separate dropdown item. By Releases we mean stable. Nightly and RC are not (ie 2.4.0 RC4 has serious bug). So IMHO they should be visible only in Advanced Mode

3. I would change 'Flash' in left menu to 'Radio firmware'
4. Last selected radio model should be preserved.

• People usually have 1 radio or mainly used radio.

[pfeerick]

1. Advanced Mode should be OFF by default This was off for me when running flasher up for the first time on a different PC, so perhaps you turned it on in the past? And I would also like the non advanced mode to have 'releases' only show non RC builds. I think if someone wants to use Flasher for anything other than a release build they should tick the advanced option, so nightly can be hidden also.

…

On Tue, 27 Jul 2021, 2:24 am Robert, ***@***.***> wrote: Hey @CoderElectronics <https://github.com/CoderElectronics>. I've downloaded today last ver of flasher. Good work. Few minor adjustments 1. Advanced Mode should be OFF by default - We target non-advanced users primarily 1. Nighly & RC should have own 'Branch' - Writing branch I don't actually mean GH thing but separate dropdown item. By Releases we mean stable. Nightly and RC are not (ie 2.4.0 RC4 has serious bug). 1. I would change 'Flash' in left menu to 'Radio firmware' 2. Last selected radio model should be preserved. - People usually have 1 radio or mainly used radio. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KO55L6V6NOKWLMGBKLTZWD3RANCNFSM5AXIZAYQ> .

[CoderElectronics]

@JimB40 Here are just some pieces of info:

1. Yes, on the first time starting the app it will be off by default. If the app has been opened before and it defaulted to something different that will stay persistent.
2. We could do that, but again to avoid hardcoding it's going to be sort of messy... I personally think unless we add release name patterns it would not work very well
3. Adding now...
4. I'm looking at this now.

@pfeerick Updates!!

1. Yes, exactly.
2. I can do that, that would be handy (releases in advanced mode)
3. I think nightly should still be shown if someone wants to try that "edge" out but still stay relatively safe

[pfeerick]

Exclude by .*RC\d+?

[JimB40]

Ad 2
Hardcoding is always the worst solution so as far as I understand
a. We have to adjust GH so Release candidates and Nighlies land in separate branch
b. We can agree naming scheme so @CoderElectronics can filter them now or ever after same way
What is your point of view Raphael?
PS.
As soon as we do it we'll put good 'how-to' video on line

I was playing more with flasher so few more things:

5. I'd change 'About' to 'Welcome

6. Welcome text proposition
   "Here you can flash your radio firmware with different versions of EgdeTX or prepare SD card content.
   You can also check progress flashing development versions (which are not considered as stable). To do that activate 'Advanced Mode' in Settings tab.

7. Settings Tab
   Text in parentheses -> (Development & unstable versions available)

8. Radio firmware tab (now Flash)
   I Like radio target selection however I would opt for version you used in SD card (drop down). Pros are

• better visual confirmation what target is selected
• Manufacturer name easily fits and is visible.
  This is very important point in flashing procedure. If someone makes mistake @ this point it may cost new radio. So 'Jumper T12' and 'Radiomaster TX12' is way safer than 'T12' & 'TX12'

[raphaelcoeffic]

Hardcoding is always the worst solution so as far as I understand
a. We have to adjust GH so Release candidates and Nighlies land in separate branch
b. We can agree naming scheme so @CoderElectronics can filter them now or ever after same way
What is your point of view Raphael?

We do have some sort of naming convention already:

• Release: git tag; we use semantic versioning and prefix with v. Example: v2.4.0

• Release Candidates: git tag; same as Release, prepended with -rcX, where X is the RC number (up to 2 digits).

• Nightly: git tag; single tag called nightly. This will stay to be nightly build on main.

• (once 2.5 gets forked) Nightly "next stable": git tag; [major].[minor]-nightly. Example: 2.5-nightly (does not exists yet).

• Branches: anything else. We might work out something to get the branch name into some metadata file, so it is easier, or whatever can be used.

[CoderElectronics]

@JimB40 @pfeerick

Issues 7 and 8 are fixed 5365aba, let me know what else should be changed!

[JimB40]

Great. I will do review in 2hrs.
BTW in interactive agency I was working for years some devs were initially "regretting" they've asked for review. By the end of the day both users and devs were pleased :)

[pfeerick]

Thanks for reminding me (to comment!) 😁

For 8, it still needs the manufacturer names - i.e. just like in the SD card tab. Preferably sorted like that is also, as it then keeps models from different manufacturers together.

After that, I would like to see

• Release's listed before nightly (in simple mode)
• Ensure that firmware versions (in advanced mode) are ordered by date (descending order) (sometimes they are out of order)
• Use commit hash rather the github action run id when building the filename for advanced mode

[JimB40]

1. Mentioning OTX Companion is not relevant anymore
2. Mentioning theme is misleading as this regards Flasher theme not EdgeTX theme. While most asked question is how to
   "how to flash nightly or dev

So:
Here you can flash your radio with different versions of EgdeTX firmware or setup SD card content.
To flash nightly or development versions (which are not considered stable) activate 'Advanced Mode' in Settings tab.

[pfeerick]

The 'releases' branch in "Simple" mode gives access to the latest nightly as well as release versions... so perhaps just
"To flash nightly or development versions (which are not considered stable) activate 'Advanced Mode' in Settings tab." for the second sentence?

[JimB40]

Droplists names should be visible all time. labels will serve as guide

1. Labels are light grey to focus attention on selection
2. Firmware branch -> Firmware type & Radio Target -> Radio model (branch and target are dev slang)

[JimB40]

The 'releases' branch in "Simple" mode gives access to the latest nightly as well as release versions... so perhaps just
"To flash nightly or development versions (which are not considered stable) activate 'Advanced Mode' in Settings tab." for the second sentence?

Which is wrong IMHO. I know due to some files structure they are in release group.
But nightly from user perspective is not 'stable or tested' version. And should not be available in BasicMode.
That's why I proposed

1. Releases (tested and stable)
2. Nightly (not so tested and may be not stable)
3. Other or Development (everything else - may crash every 2 seconds or go into EM etc)

[JimB40]

UI Flow

When there are selection dependent UI elements (droplists in our case) designing UI most prefered method is reveal. Using it we don't have to code empty or unselected state in unnecessary UI elements.

Example in Advanced mode
Step 0

• [Flash LOCAL FILE] visible as this independent form server source of *.bin
• only [Firmware type] droplist visible allowing user to select Releases, Nighly or Development

Step 1

• only [Firmware type] & [Firmware version] droplists visible allowing user to select FW version

Step 2

• Now we ask for radio model or pre-select with lastly selected (most probable user will flash same type)
• You can add later in Flasher settings 'My radios' so list will be narrowed only to user owned radios simplifying process even more.

Step 3

• we have *.bin file downloaded so notes and buttons are visible

[JimB40]

Firmware notes

When there is single one sentence note is okay but with long text like for 2.4.0 release is practically non-usable
To preserve compact form of Flasher that I like we should code button or icon that will open pop-up with scrollable firmware's notes.

[JimB40]

Plus manufacturer name and dropdown list sorted alphabetically mentioned already by @pfeerick. :)

[JimB40]

1. I don't see point to use collapsible folder. Features in all 3 folders must be selected to end procedure successfully. So collapsed folders increase only amount of clicks.
2. Radio target -> Radio Model
3. Same reveal method can be used because until you select proper "Radio model', at least one voice pack or select proper Disk you can't write anything to SD card. When using reveal method no need to display error messages or code buttons as inactive.

[pfeerick]

But nightly from user perspective is not 'stable or tested' version. And should not be available in BasicMode.

So, how do we structure this... separate toggles for showing nightly and development builds, or lump both under Advanced Mode? I'm leaning towards the former, as it is good to expose nightlies without the whole "what is the X branch about" (work in progress branches and PR merges).

For the firmware notes, perhaps just a link underneath that brings up the relevant/release notes page?

I do like (and hate) the 'step-by-step approach' ... it can be beneficial, but at the same time there aren't that many questions being asked, so it becomes more a question of is it beneficial in this instance. i.e. the ELRS configurator also shows all the options at once... which I quite like as there are no unknowns ("what question will it ask next").

[JimB40]

Any of your proposed solutions is okay. Just decide and 'Run Forest run" :)
To finish 'bootlader mode flashing procedure' we need one more feature:
Moving downloaded file to /FIRMWARE folder plus in case of B&W targets changing firmware name to 8+3 format (xxxxxxxx.bin)

[pfeerick]

@CoderElectronics I take it there has been some progress on this for the issue to be closed?

[CoderElectronics]

Yes, a lot has been solved since this thread was started. There may be more that needs to be done but this thread has been stagnant for some time so if the issues are still of concern we can resurrect this