#1223 feature: sorting key maps

[maksimowiczm]

I've made some progress on the sorting feature.

I've created a simple UI where users can choose the field priority and sort order of the fields, which are applied to the home key maps list. I don't think a bottom sheet is a good idea for this especially with the drag interactions, but I couldn't think of a better alternative. (I replaced help button 😅)

Sorting preferences are stored in PreferenceRepository. I think it would be annoying to have to apply sorting every time the app is launched.

I'm unsure about using sorting in ListKeyMapsUseCaseImpl. Currently, key maps are sorted every time, which might result in a poor user experience if someone has a large number of key maps. I think it might be a good idea to create a separate screen for searching, where key maps could be sorted.

It might also be a good idea to implement sorting with SQL for better performance.

Additionally, there doesn't seem to be an obvious way to sort triggers and options, so I need some help with that.

Closes #1223

[GfEW]

That's great news! I can't currently test PRs, but I'm not really into coding, anyway. Hope @sds100 finds time to take a closer look.

I can, however, comment on the UI/UX side of things. Some remarks:

1. persistency

Sorting preferences are stored

Makes sense, sort/filter prefs should indeed persist until changed or reset by the user. To keep forgetful users from missing something, it's important to clearly indicate (e. g. by the filter icon) whether the current listing is filtered.

2. sort delay, main vs. separate list

Currently, key maps are sorted every time, which might result in a poor user experience if someone has a large number of key maps. I think it might be a good idea to create a separate screen for searching, where key maps could be sorted.

Is this really an issue? Could you give some figures of the expected sort delays with 30, 100 and 300 mappings, or estimates thereof?

Sorting and filtering would be much more beneficial in the main listing than only in a separate search screen with limited functionality. To justify the inferior, latter option, the performance difference between the two would have to exceed 1.5 s with 30 mappings, or 3 s with 100 mappings (which already is a lot, but would mainly affect the relatively small fraction of users who know they are stretching the limits).

I think it's reasonable to assume only very few will end up using more than a few hundreds mappings. And if done right, sorting a list of a few hundreds items shouldn't take more than one to two seconds, even on ageing hardware (for a relevant example, see the apps list in AppManager).

3. sorting triggers or options

there doesn't seem to be an obvious way to sort triggers and options

Ideally, sorting by triggers would be consistent with their exact name strings as they are presented to the user (including Left/Right, parentheses etc.), e. g.
"Shift Right (Any device * Do not remap) + Delete"

Sorting by options is trivial for mappings that have either no or exactly one option enabled. (As with every key, "no option enabled" should come before all possibly enabled options, as the empty string is the smallest possible value.)

The case of multiple options being enabled is a bit awkward, because their presentation order currently doesn't follow an obvious scheme. However, sorting according to the presented string would be the best we could do here, too, e. g.
"Vibrate * Show an on-screen message"

p. s. Nice PR ID.

p. p. s. I've visually improved the sorted list example in #1223, to make it easier to comprehend.

[sds100]

First I'm going to complete version 2.7 and then I will work on this.

[maksimowiczm]

I worked on it a bit.

---

@GfEW

2. sort delay, main vs. separate list

I might have underestimated the performance of modern devices. I don't think it will be an issue with such a "small" list.

---

I applied your suggestions. @sds100

---

Current sort order for each field:

• Trigger

1. Keys are sorted one by one until one trigger runs out of keys (different size of keys list)

   Keys are sorted by

   1. Code
   2. Click type (short, long, double)
   3. Device
   4. "Do not remap" option

2. Keys' length - the shorter the better

3. Trigger mode (sequence, parallel)

• Constraints
  Sorted by their name. If names are identical, they are sorted by their value (e.g., package name, Bluetooth address, etc.).

• Actions
  Sorted by their name (e.g., all Launch app actions are treated as the same name). I am currently working on sorting them by their value, similar to constraints.

• Options are not sorted at all. Not sure where to find all options in the code I need some help with that. @sds100

---

I think users should be able to choose sorting options and arrange them according to their needs. For now, I’ve implemented a very basic UI with all field.

24-11-17-17-47-26.mp4

---

What's next?

• I will finish sorting actions by their value
• I will try to sort options
• Think about user interface

[maksimowiczm]

Everything except the UI is done. Additionally, this commit 11e736f somehow broke part of the multi-select menu functionality. If reverted, it works fine.

[maksimowiczm]

So, I did some research and I came up with a solution where the sort fields are displayed as chips in a scrollable row. It could also wrap, but at this width, it looks awkward because one element will jump between the first and second row.

The bottom sheet could also be used with filters, where it would be added below the sorting feature.

This is a similar solution to the one used by TikTok.

[sds100]

Hey! I think the chip row option is good, as you mention, it provides more space to add extra options. Can you merge the develop branch into this so the merge conflicts are solved?

[GfEW]

Sorry about the long delay - very busy days here.

@maksimowiczm

sort fields are displayed as chips in a scrollable row

Chips have proven to serve well for simple sort operations, and the established UI paradigm certainly helps users to get along easily.

As far as sorting by multiple fields is concerned (which makes a lot of sense in the case of keymapper's bindings), I don't fully understand your implementation, yet. Tinted chips are obviously "active", grey ones "inactive" - that works. But can the chips themselves be sorted? If not, how else do you indicate sort priorities, i. e. which active field matters most, which second, etc.? (In this regard, your "very basic UI" was appreciably clear.)

The bottom sheet could also be used with filters, where it would be added below the sorting feature.

Sounds promising! Great to see progress in these improvements to keymapper's long awaiting list UI.

[sds100]

I guess if its critical to have the ability to also sort the filters by priority, then the first implementation with a drag-drop list is the best option? But is it not overkill? Surely for 99% of users it is sufficient to sort by just trigger or the actions? To give that extra level of organization the grouping/folder feature should be implemented #320

[maksimowiczm]

Chips can now be moved around. I don't have much experience implementing lists with draggable elements, so it looks a bit clumsy. I went a multi-line chips list because IMO it's more convenient for moving them.

I'm not sure whether animations improve the user experience or not.

This is without animations.

Screen_recording_20241219_173226.webm

This is with animations. There are some issues with shadow if the user moves item too quickly

anim.webm

[sds100]

Thanks for the demo. I think if we want to reorder them then the list (not chips) provides a better UX and makes it clearer it is possible to reorder them cos its similar to the trigger list. What does @GfEW think?

[sds100]

Sorry @maksimowiczm did you already see my review comments before I submitted them?

[maksimowiczm]

First time seeing those. I will check them right now.

[maksimowiczm]

@GfEW I just realized what you meant about these help messages being adjusted according to the available space. I tried to make it work, but it didn’t look right, and I can’t spend infinite time on it, so it is what it is and its cool.

[sds100]

This looks good now, I'm just doing some minor refactor/style changes to make it more consistent with the other code then I think its done!

[GfEW]

@GfEW I just realized what you meant about these help messages being adjusted according to the available space. I tried to make it work, but it didn’t look right, and I can’t spend infinite time on it, so it is what it is and its cool.

Sure, go ahead. Things can be revisited anyway later on, should the need arise.

[sds100]

@maksimowiczm @GfEW I'm now sorting actions and constraints primarily by their type and then by secondary data such as the app name etc. Can you verify it is working as intended?

[maksimowiczm]

Sorting by types is not alphabetical, but I think it is good enough!