search

EdgeTX / edgetx

EdgeTX is the cutting edge open source firmware for your R/C radio
https://edgetx.org
GNU General Public License v2.0
1.58k stars 336 forks source link

Intrinsic issues with labels #2451

Open RC-SOAR opened 2 years ago

RC-SOAR commented 2 years ago

Labels are at first sight a nice idea, but the way there are implemented could lead to a lot of confusion. See screenshots below:

screen-2022-10-02-184507 screen-2022-10-02-184514

Each screen shows two models with the same names.

Question: how many unique model instances are there?

Answer: It's impossible to know just by looking at the screens. Entries with the same name may be duplicates with different labels, or single instances with multiple labels.

(In this case the FRSKY entries refer to a single instance with two labels. The FlySky models are duplicates with different labels.)

Users will need to take great care when duplicating and labeling models, both of which are common activities.

Folders are IMO a much safer way of categorising, since every model instance must belong to one and only one folder.

Describe the solution you'd like

Replace labels with folders,

1 model instance : 1 folder

(Can still mark individual models as 'favourites'.)

Describe alternatives you've considered

An alternative would be to keep labels, but force unique names for every model instance.

Additional context

No response

gagarinlg commented 2 years ago

You can also select more than one label and get all models that have both labels. This is intentional. Probably nobody thought that someone would have multiple models with the same name. Forcing unique names might be a good idea.

RC-SOAR commented 2 years ago

Probably nobody thought that someone would have multiple models with the same name.

Unfortunately, that happens whenever you select 'duplicate' - the cloned model is given the same name. Many users will just assign a different label, without changing the name. Then start making programming changes to one or other instance.

A month later, and they may not remember that there are two different instances, and just assume that it's one instance with two labels. There is then the possibility of choosing the wrong instance and crashing. (yes, they can select multiple labels, and with a bit of Boolean algebra they may get a clue as to what's going on, but how many users would do that in practice?)

With a folder/category system as in Ethos and OTX, users know that each entry refers to a unique instance. There is no confusion, and a reduced possibility of error (no system is perfect!).

If we must have labels, then it would be useful to display the (unique) filename.

pfeerick commented 2 years ago

It's not so much an oversight but a user generated confusion that it would be nice to prevent. It's no different to me copying the same model into different folders/categories ... Can and have scrambled myself up quite nicely there also. Do we start altering models when there are duplicates (since the current process is to make a true duplicate, so of course the name is the same) and appending a number, etc. Do we enforce unique names (but why should we limit - e.g. I can tell them apart quite easily with different images?). What about showing a indicator, or extra info (like the filename, last modified date) when duplicate model names are detected?

dlktdr commented 2 years ago

I don't see how it's that much different than creating two duplicates in a category, but I see where this is coming from. If your not sure how many total instances you have can always uncheck all labels to see everything, then rename as you see fit. Keeping the same name in either case is going to be confusing.

I think forcing unique names could cause a lot of issues/work in code, to many what if's.

I think the idea when creating a duplicate to append a -2, -3 or something to that effect to the name would be a good addition. Then it will would be obvious, and up to the user to properly rename it.

RC-SOAR commented 2 years ago

I think the idea when creating a duplicate to append a -2, -3 or something to that effect to the name would be a good addition.

That would work. Alternatively, display the filename of the highlighted model.

Eiither way, it's essential to be able to identify unique instances easily.

Many users don't have computer skills, having maybe 20 or 30 models, are careless with duplicating and labeling. Expecting them to play around with labels simply to determine whether entries with the same name refer to distinct instances, and or just different labels for the same instance, is not practical IMO.

Eldenroot commented 2 years ago

I think this has one simple fix - not allow same names for models...every name has to be unique.

dlktdr commented 2 years ago

Not sure how to handle all cases of the unique name, for instance if I copy a model from one radio to another that has the same name. Which one should be renamed, or once again have a duplicate.

How about something like this? I don't really want to see the filenames all the time, so use a checkbox to enable/disable them. Not a lot of room left on the top bar for the filename of the highlighted model, especially on NV14.

snapshot_05 snapshot_04

JimB40 commented 2 years ago

Agree name appendix is better idea. If you really need filename add it on top bar in brackets not changing UI layout. But IMHO then 'after months' user will also not remember that model6 is right and model9 i wrong.

RC-SOAR commented 2 years ago

I think filename has a major benefit - it's simple and unique. It's also useful if you want to refer to the YAML file for any reason. (Name appendix may be re-used after deletions so is not truly unique.)

To save on real estate, and avoid scrolling, the option to display filename could be in System settings.

dlktdr commented 2 years ago

I've been contemplating this and think what I will work on for 2.9 is have the model name as the filename. Then it has to be unique. Add some logic to rename and duplicate and we get the best of both worlds, no need for extra GUI info and clear what file is what. Will also take into account trying to copy a same filename from one radio to another.

gagarinlg commented 2 years ago

I am not sure if the file system driver is compiled with UTF support and if windows, MacOS, Linux and the EdgeTX driver will harmonize when using UTF-file names.

dlktdr commented 2 years ago

Just a thought at the moment. I'm sure there will be lots of other issues that could arise and make this not possible as well.

RC-SOAR commented 2 years ago

I've been contemplating this and think what I will work on for 2.9 is have the model name as the filename. Then it has to be unique. Add some logic to rename and duplicate and we get the best of both worlds, no need for extra GUI info and clear what file is what. Will also take into account trying to copy a same filename from one radio to another.

I can't see how this will work. Model names are... descriptive labels. Filenames are properties of the file system.

Why not blatantly copy from a system that is known to work. In Ethos, when you highlight a model, it displays the filename and last updated date. In tiny font, so tiny you almost have to use a magnifying glass. So it takes up little screen real estate.

Best to keep it simple.

pfeerick commented 2 years ago

If you really need filename add it on top bar in brackets not changing UI layout.

That isn't going to be very useful, the problem is trying to workout when looking at multiple models with the same name whether they are the same or different (via filename) - so this would mean you need to keep opening models to find out which is which.

To save on real estate, and avoid scrolling, the option to display filename could be in System settings.

Good point. But it would be nice for it to be right there if you want to be able to just turn it on to check something, and turn it off. And if it's right at the bottom of the list, you'll only see it if it's a short list, when you scroll to the end, or if you specifically go looking for the opt. Or we get fancy and put an option button at the side, and we can then have more model select display-related options go in there.

How about something like this? I don't really want to see the filenames all the time, so use a checkbox to enable/disable them. Not a lot of room left on the top bar for the filename of the highlighted model, especially on NV14.

Sounds good as a quick-fix for now to help prevent confusion, and we make it look pretty in 2.9 :) I don't think filenames are going to really make it work, and it does mean need to keep updating the index and stuff when you rename the model.

Best to keep it simple.

Indeed. I vote we go back to fixed model01, model02 names, and just use sticky notes to remember which model is which! 😆 But, yes, something like that could work quite well. Or, the model filename could be shown in the popup menu, so it doesn't detract from the model images...

RC-SOAR commented 1 year ago

Related issue:

When opening the Model Select menu, I have no idea what the label(s) for each model. I can only determine the labels by opening the Label editor, or the Model Setup menu.

This is so confusing... when I go to the Model Select menu, I want to know exactly what I'm opening now, without fiddling with other menus. Click, bang, done.

One solution would be to show all the labels along with each model, but of course there is the lack of screen real estate.

The more I try to use labels with my own models, the more I feel that they're a complicated solution in search of a real problem.

I keep coming back to the folder system, where each model is associated with one folder. You could still tag individual models as 'favourites', and add a filter. That's all people need.