I’m a UI/UX professional as part of my day job and also consult in that space. I completely understand and agree with your point. Long scrolling data sets are ideally avoided, but the issue of initially hiding data from users is also equally problematic. When it comes to UX I like to equate user actions (scrolling or clicking) to a form of currency, and think of every user as having a limited budget before they throw in the towel. The fewer actions you can put between a user and their end goal, the better. While both scrolling and clicking expend the user’s budget, clicks are far more expensive than scrolling. Scrolling is a near-passive action and clicking requires more focus and typically evokes a UI state change that requires some adjustment.
The challenge here is that the entire data set is overwhelming for “typical” users (lots of scrolling), and a data set parsed dow to only 10 items is too limited to be of practical use to nearly any user (prior to searching). In my current gig I’m dealing a lot with reporting and analytic software, and I find most data grids default to between 50 and 100 items per page. I think we just need a goldilocks compromise in the UI to increase its usability. That sweet spot should be somewhere between 10 and 5000
As an exercise I took common terms associated with bot usage (tip, poll, raffle, mod, playlist, request, game, twitter, etc) and found that in most cases the results were between 15 and 80 items. Meaning to find a specific command when limited to a listing of only 10 items, almost every case would require multiple user interactions (beyond the initial search) to consume the results.
Then there is the case scenario of a user that is new to the bot wanting to review the entire list, as for many users (myself included) reviewing the commands is the first glimpse into the full functionality of the bot. With a limited set of 10 commands per page, and the pagination UI at the bottom of the page, a user on a smaller screen/window would have to read down the list, click the next page, then scroll back to the top of the list to view the first item on the new page. This means the initial goal of reducing scrolling by limiting the results may actually require more scrolling, as users have to scroll down and then back up to review next 10 results.
Future versions of the command list could offer filtering based on command level (admin, moderator, user, etc) to help narrow the data set based on use case scenarios. I’m sure there are other great filtering options that could be implemented based on different modules or functionality types as well.
I’m an avid supporter of PhantomBot (best damn bot out there!) and just want to help make using it (and the supporting resources) as easy as and intuitive as possible. Having been frustrated by the command list on many occasions I figured it was a good time to finally post something about it. I’m not saying the command list is bad, but there’s always room for improvement!