Alphabetically list order to eyes or navigate obvious exhausting sorted in any other is not your with it's this which logical

[Bit Disappointed]

Alphabetically list order to eyes or navigate obvious exhausting sorted in any other is not your with it's this which logical.

(It's exhausting to navigate this list with your eyes, which is not sorted alphabetically or in any obvious other logical order.)

[Old Bruce]

I would guess this is so the different languages will follow the same order. There is a sort of method to the apparent madness:

Curves and Shapes (Vectors).

Art Text and Frame Text  (Text).

Pixel Layers, Images, Masks, Adjustments and Live Filters  (Raster Stuff layers).

Groups and Symbols (kind of go together).

I would put Tables in with the Text stuff.

I would put Picture Frames between Text and Raster Stuff.

[Bit Disappointed]

I don't navigate the lists that way myself, but by what I know for sure I'm looking for, the name. Code can easily sort such a list regardless of the selected language.

Assuming that people will want to see them listed in type order in this case, or will intuitively adjust to it, is naive. And if that is the case, one should clearly section with labes them so that it is apparent and the logic is visible. Apparent logic is great usability, apparent madness is just madness.

So I think what we're left with is apparent madness that appears as madness to anyone who hasn't rehearsed and memorized the types of layers in Affinity. That's probably the majority.

🙂

[Old Bruce]

Grouping by kind/type/group is quite common. I doubt anyone arranges the tools in the tool palette alphabetically.

We should perhaps be happy that they didn't decide to use the icons from Layers panel instead of text. That way they wouldn't have to deal with correcting translations.

[Bit Disappointed]

Navigate looking for sort lists name selected language types of layers Affinity naive apparent madness great usability madness section clearly labes rehearsed memorized apparent logic majority I don't the lists that way myself but by what I know for sure I'm the code can easily such a list regardless of the assuming that people will want to see them listed in type order in this case or will intuitively adjust to it is and if that is the one should with labels them so that it is and the is apparent is just So I think what we're left with is that appears as to anyone who hasn't and the of in that's probably the.

My previous answer sorted by these types of words:

Navigation and search words
Subject and context words
Assessment and perception words
Action and method words
Descriptive and qualitative words

🙂

[Bit Disappointed]

10 minutes ago, Old Bruce said:

Grouping by kind/type/group is quite common. I doubt anyone arranges the tools in the tool palette alphabetically.

These are two completely different types of user interface; one place you navigate by symbols (how the brain was actually designed to navigate), the other by words (opposite brain scenario). With words, it's much, much, much harder to decode such categorization unless it's directly obvious from the words: War Ammunition Milk Butter.

In any case it is common practice in other companies to user test this before releasing a thing to the public - even a beta - and Serif doesn't do this. So here we are.

[bbrother]

When it comes to the appearance of this list, I think that the best solution would be to use one background color and a simple separator (1 pixel divider) between the list rows instead of using an alternating background coloring with such a distinct color difference, the so-called "zebra stripes".

UI designers use "zebra stripes" in large data sets, but that's not the case here. They use this type of coloring very wisely and as a last option tool.

This method is often overused, as in this case.
Such a noticeable color difference between list rows causes visual noise and is unpleasant to the eye.

P.S The UI designer knows this stuff and would definitely not design the list this way. Another proof that there is no UI/UX design specialist on the Serif team.

[GarryP]

Sorting UI items alphabetically can cause at least two major problems.

The first is that the software would have to take account of which language the user has selected when the UI elements are being displayed and rearrange the UI items by their ‘display name’ at run time, rather than just having them in an order set by the UI designer at compilation time. Not an insurmountable challenge, but a dynamically-modifiable UI is just one more thing that could go wrong.

The second is that different languages will often order the items differently, which would make software support and things like following video tutorials more difficult. It’s more difficult for support because support staff can’t simply say, for example, “Click the third menu item from the top” or “Select the second from last item in the list”, and it’s more difficult for watching tutorial videos as a difference in language would cause the UI of the tutor’s software to look different to the UI of the student’s software, and people could be making all kinds of mistakes without knowing it, causing further confusion/frustration.

An option for each user to be able to organise their UI alphabetically would also cause the same problems as above whenever they need to communicate with other users in different languages, and it would add more ‘complication’ to the UI at the same time.

(Yes, we can configure the various Toolbars as we wish but those tools have tooltips and icons which can make it easier to find things other than purely textual lists, so I don’t think that’s the same issue.)

Unfortunately however, sorting UI items by ‘most-used to least-used’ or ‘simple to complex’, or any other specific order, also has its difficulties as the question comes up of what you would do as new items are added because users get used to items being in a specific order, and place, and adding new ones somewhere into the middle would cause confusion/frustration/complaints with ‘broken workflows'.

Grouping items can often make things easier find but there’s then the question of whether the groups are alphabetically ordered or are they are ordered in some other way, which brings me back to my earlier concerns.

Basically there’s probably no ‘best’ solution to this, and there’s always going to be some problem or other.

The least-worst option of simply learning where things are is probably going to have to be what we need to accept.

[GripsholmLion]

I admit that I am not familiar with Objective C. But in those programming languages with which I am reasonably familiar, alphanumeric array sorting is trivial. So I looked it up and it did not take much effort to find out that there is a function for it in Obj C, just as one would expect. So if this were to be implemented, it should not present any "major problem". Languages do not need to be accounted for; and supported non-Latin alphabets, i.e. Cyrillic, should already have been accounted for – there is a function for that as well – when the translations were added. In other words: it's technically trivial.

[bbrother]

15 hours ago, GripsholmLion said:

So I looked it up and it did not take much effort to find out that there is a function for it in Obj C, just as one would expect. So if this were to be implemented, it should not present any "major problem". Languages do not need to be accounted for

I agree with you my friend. Sorting alphanumeric arrays, which is what strings are, is not a challenge at all.
More distracting to the eyes are the overly expressive colors used to create "zebra stripes."

[Affinity Info Bot]

The issue "States - Query > Layer Type is Fruit Salad" (REF: AF-1924) has been fixed by the developers in internal build "2.4.0.2279".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.