How best to handle a long option list for a select box

[NickMNS]

Problem, I have many instances, up to 7, of a select box appearing on one page. This select box has roughly 800 items to chose from (it's an emoji picker). I say up to 7 because each instance is added dynamically. The user can create an entity, and with the new entity a form is generated, and then the user can enter or select various options, including an emoji. Currently each time an entity is created a fetch request is made to the server to get the list of emojis, and select box is created from the response. In production that request would be cached.

A list of 800 options is not great for UX. Obviously not all emojis are relevant to the page, so I suspect that a few will be used more often than others. Ideally I would like to order the list from most often used to least used. Or most recent to never used. This would require some kind of feedback loop with the server.

Now updating 7 option lists of 800+ items each time an emoji is selected is no small task.

My idea is to store the list of emojis in memory, likely with the initial page load. Then take the first 30 or so items of the list and display these in the select boxes, with a show more option. Then each time an emoji is selected the list in memory is updated pushing the selected emoji to the top of the list. If the user selects the show more option and chooses an emoji not in the top 30 then that one is pushed to the top of the list. Existing instance are not updated, and new instance will be generated with the new order. Then once the user successfully completes to "goal" and interacts with the server, the top items of the list are sent back to the server where the initial list is updated accordingly.

Any thoughts?

The one issue I see with this approach is that the next user sees the last user's selection. If a user or multiple user or one user over multiple sessions decide's to use only what can be perceived as offensive emojis (eg: eggplant, peach, etc..) then a new user may get a bad impression of the website. So maybe some kind of weighted approach might be necessary. Note that users do not need to be logged in, so saving a list for each user is not a solution.

I'm looking for ideas.

[lammert]

On one site I use personalized menu item lists where the sort order is determined by how often a menu link is clicked. More often used items are higher in the list. All menu items are stored in a database and have a priority value attached. This is a floating-point value. Initially, this priority value is 0.0 for all menu items.

When a menu item is selected, I add 1.0 to the priority value for that menu item. After that, I multiply all values in the database with 0.99. This decays the values in the database. Menu selections in the past will, therefore, have less influence than more recent menu selections. It also caps the maximum value in the database for each menu selection.

Changing the 0.99 value will make the menu shuffle more or less aggressive. with a lower value, say 0.7 it will cause menu items which were used just a few times in the recent past to rise quickly. A higher value like 0.9999 makes the menu sorting much more stable. The value should always be less than 1.0 because of the decay effect.

[NickMNS]

Very interesting idea.

The only thing that concerns me is this:

After that, I multiply all values in the database with 0.99.

This seems fine for a short table, but if the table and number of users grow this could amount to a significant load on the server for a simple UI feature. There is certainly a method that can achieve the same outcome that only requires you to update selected menu item and not the others.

[lammert]

This works also fast with a long table. In MySQL, it is just one line of code. All the calculations are done by the MySQL server and the query returns almost instantly.

UPDATE `menu_list` SET `priority`=`priority`*0.99 WHERE `user_ID`='$curr_user'