According to the heat map that we generated for our app (an ad server), users rarely sort the items in the lists, they usually use the search to find the items they wanted to find. Developers said it will highly improve the performance of the app if we remove the sorting feature.
I am very skeptic about this change as it's a best practice to be able to sort the data in the long lists ( our lists can reach to 100 items) but in the same time the performance (loading time) of the app is very important for the company.
Thanks to kettch for these questions :
Do your users know that the columns are sortable? - Yes in the user tests almost all users noticed the sortable header
What is the average size of the data set? - Usually, you get 50 lines per page, but a standard campaign manager (our targets) only need 4 - 5 items per page for now
Why are the users who do sort using the feature? - I don't have a clear answer for that, I would say they try to find underperforming campaigns by sorting them by pacing or CTR
Is the data grid so painfully slow that the users never user it? - No it is fast actually, but – apparently – the sorting feature is causing problems in the database and creating discrepancy in the data
Developer's notes for the issue :
- Issue getting the data in postgresql because of the amount of calls needed to update this data, just so that we can sort it, if less than 5% of our users are actually using this to sort.
- Won't scale forever the way it is now
Also what we would be winning by doing this the way we are planning :
- Realtime. Like, really real-time. Every time you refresh the page you would see the latest performance (and not 2 minutes after or whatever)
- Better performance not only for the list, but for the whole product. Less "freeze" in part of the apps
- Cost optimisation, because we wouldn't need to compute it every 2 minutes, although no one would actually see the data (during night or whatever). We would compute it only when necessary