Timeline for Should we kill the features that users are not using frequently, to improve performance?
Current License: CC BY-SA 3.0
60 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 24, 2019 at 14:58 | vote | accept | Deniz Erdal | ||
| Sep 2, 2018 at 1:29 | answer | added | rezand | timeline score: 0 | |
| Jun 20, 2018 at 13:16 | history | edited | Deniz Erdal |
edited tags
|
|
| Apr 4, 2018 at 22:22 | answer | added | user3719694 | timeline score: 0 | |
| Jan 12, 2017 at 8:40 | answer | added | Spacemoose | timeline score: 1 | |
| Jan 10, 2017 at 1:14 | comment | added | Mike D. | Alternate related xkcd: xkcd.com/1172 | |
| Jan 9, 2017 at 13:28 | comment | added | Lilienthal | Putting aside the very valid general question, surely no one in their right mind could ever seriously argue that a list-based data view intended to display up to 100 items should not have a sort option? The fact that (power) users will expect there to be a sort option alone may be enough to kill that suggestion. | |
| S Jan 9, 2017 at 11:44 | history | suggested | Søren D. Ptæus | CC BY-SA 3.0 |
corrected grammar and typos
|
| Jan 9, 2017 at 11:44 | answer | added | gnasher729 | timeline score: 1 | |
| Jan 9, 2017 at 11:31 | review | Suggested edits | |||
| S Jan 9, 2017 at 11:44 | |||||
| Jan 9, 2017 at 2:38 | comment | added | SplittyDev | Related: xkcd.com/1770 | |
| Jan 7, 2017 at 22:36 | answer | added | rbaleksandar | timeline score: 3 | |
| Jan 7, 2017 at 20:39 | answer | added | Harper - Reinstate Monica | timeline score: 0 | |
| Jan 5, 2017 at 21:28 | answer | added | industry7 | timeline score: 11 | |
| Jan 5, 2017 at 16:51 | comment | added | HopefullyHelpful | Users on some sites which remember logins, rarely ever login, should we remove the login feature altogether ? My point is, if you know that only 10% of your users use the sort feature at all, then yeah, the rational is ok. If all users use the feature 10% of the time, then you're removing an essential feature instead. Also how is removing the option to search, going to improve the performance of the app ? | |
| Jan 5, 2017 at 15:39 | comment | added | Cody Gray | Read the rest of the comment, @bparker. Power users may compose only a small minority of users, but they're the ones who either evangelize your product to new users or trash-talk it. When a non-expert computer user is deciding which program to use, they're probably going to solicit recommendations from their (perceived) "computer geek" friends. If those people don't like your program because it isn't customizable or otherwise frustrates their expectations, they're going to recommend your competitor. This phenomenon has existed since the BBS days. Add blogs, Twitter, etc. and multiply by 1000. | |
| Jan 5, 2017 at 15:35 | comment | added | bparker | @CodyGray How can removing features only used by a small minority cause the rest of the users to stop using your program? | |
| Jan 5, 2017 at 15:26 | comment | added | Fattie | Hire better programmers. | |
| Jan 5, 2017 at 11:30 | comment | added | user207421 | If they're not using them how can they kill performance? | |
| Jan 5, 2017 at 10:56 | vote | accept | Deniz Erdal | ||
| Apr 24, 2019 at 14:58 | |||||
| Jan 5, 2017 at 10:53 | vote | accept | Deniz Erdal | ||
| Jan 5, 2017 at 10:56 | |||||
| Jan 5, 2017 at 10:53 | vote | accept | Deniz Erdal | ||
| Jan 5, 2017 at 10:53 | |||||
| Jan 5, 2017 at 10:07 | vote | accept | Deniz Erdal | ||
| Jan 5, 2017 at 10:53 | |||||
| Jan 5, 2017 at 8:15 | comment | added | hvm2hvm | You didn't directly answer my question but it seems that it's likely all users use the sorting function but rarely. That means you won't just piss off a few power users if you remove it, you'll piss off most of them. And having your work flow slower, even if it's just having to click a few times more once in a while is exactly what makes people very annoyed. You don't want to do that to your users. | |
| Jan 5, 2017 at 4:58 | answer | added | Loren Pechtel | timeline score: 0 | |
| Jan 4, 2017 at 23:25 | answer | added | Robyn | timeline score: 2 | |
| Jan 4, 2017 at 19:38 | comment | added | Wayne Werner |
People rarely cat /proc/cpuinfo, but I would be royally pissed off if that magically disappeared from Linux, as would many others who actually use that feature.
|
|
| Jan 4, 2017 at 17:36 | comment | added | barbecue | "Issue getting the data in postgresql becuase of the amount of call needed to update this data, just so that we can sort of it" Sorting should not require updating any data. It's just sorting data that's already there. Unless they are doing something like remembering the sort order and storing it or something this makes no sense. And even that should not be a big performance hit. | |
| S Jan 4, 2017 at 17:35 | history | suggested | Jon of All Trades | CC BY-SA 3.0 |
Corrected an obvious missing word in the title
|
| Jan 4, 2017 at 17:24 | review | Suggested edits | |||
| S Jan 4, 2017 at 17:35 | |||||
| Jan 4, 2017 at 15:42 | answer | added | Andy Rice | timeline score: 4 | |
| Jan 4, 2017 at 15:08 | answer | added | Rumi P. | timeline score: 214 | |
| Jan 4, 2017 at 12:17 | comment | added | roetnig | @DenizErdal I think the key is on "sorting feature causing problems in database and creating discrepancy in the data". If you have this kind of problems with 100 items, then there is some design flaw. I have grids with huge number of items and no problem with sorting or filtering. As long as you sort the data locally (in the front-end) there should be no impact at all in the database. I'm using pqgrid, usually with grids of 1000+ items. I have a couple with 100000+ items and albeit a slow loading (7 seconds) the sorting/filtering is done in a twist (locally) | |
| Jan 4, 2017 at 11:35 | history | edited | Deniz Erdal | CC BY-SA 3.0 |
added 9 characters in body
|
| Jan 4, 2017 at 11:34 | comment | added | Deniz Erdal | Users use the search function very often as you can see on the heat map, but they don't use the sorting ( sort by date, impression, clicks etc) I don't think we can compare it to + sign, as the absence of the + sign will block user to execute some tasks, but absence of sorting mechanism will just slow user's search | |
| Jan 4, 2017 at 11:23 | answer | added | Gray Roberts | timeline score: 0 | |
| Jan 4, 2017 at 6:37 | comment | added | hvm2hvm | Not an answer but a request for clarification. How does the heat map work? Does it actually tell you that most of the users never use the search function or that all the users rarely use it? If you disable a feature that people use rarely but that is a life saver when they do, expect huge rage about it. You rarely use the + plus sign on a keyboard but if keyboard manufacturers looked at heatmaps and concluded that they can remove the + key there would be riots. | |
| Jan 4, 2017 at 4:14 | comment | added | jamesdlin | Why would removing sortability improve performance? If sortability significantly hurts performance, then couldn't you do that work lazily only when the user actually asks to sort? | |
| Jan 4, 2017 at 1:47 | comment | added | Izkata |
our lists can reach to 100 items ; Usually, you get 50 lines per page - A possible reason they're sorting in the database instead of the frontend, like prior comments recommend: they only want to query for the data that will actually be shown to the user. This would mean that not all of it is available on the page in order to do client-side sorting. But if your first statement is right and not a typo, that still seems trivially small - there's no reason not to pull it all down.
|
|
| Jan 3, 2017 at 22:46 | comment | added | Demi | @DenizErdal The solution is to sort in the front-end | |
| Jan 3, 2017 at 19:29 | comment | added | Salman Arshad | Does your app get slow when the user actually use the sort function? | |
| Jan 3, 2017 at 19:27 | comment | added | Arielle Lewis | A plugin like datatables (if you're running jQuery) gets you frontend sorting (and realtime search if you want it) for almost no effort. Any dev who doesn't want to do frontend sorting shouldn't be at the helm of commercial software. As an aside, if I saw that page I would have zero clue that columns were sortable. I'd probably try to click on one just because I assume columns to be sortable by default these days, but there's practically no visible cue they are. It just looks like it's sortable by name. | |
| Jan 3, 2017 at 19:27 | comment | added | MonkeyZeus | Thanks for the update and this further solidifies my stance on the dev's ineptness. "Issue getting the data in postgresql becuase of the amount of call needed to update this data" tells me that they are pulling data from millions of rows and making the users suffer for it. They should be able to easily create an aggregate table from which your datagrid can query/sort and update that aggregate table via scheduled server task. The fact that they are placing the onus on your end is wrong. | |
| Jan 3, 2017 at 19:16 | comment | added | Aerdan | It sounds to me like you're (pre)sorting on the server side; is there any reason that you can't offer sorting on the client side? | |
| Jan 3, 2017 at 18:44 | comment | added | Deniz Erdal | @MonkeyZeus Thanks for the question, I added a short explanation made by one of our developer to the original post. Apparently, it affects other parts of the product and they said they choose to do the sorting in back-end and it would be much more performing if it was front-end but as the feature used less than 0.5 % of users they suggest to kill it instead of refactoring. | |
| Jan 3, 2017 at 18:34 | comment | added | Delioth | Not an answer, but sorting on that scale can easily be done client-side; there doesn't need to be any special database or server-based ordering, javascript will do it well enough (and is always going to be faster than creating, executing, and waiting for a database query). | |
| Jan 3, 2017 at 18:16 | history | edited | Deniz Erdal | CC BY-SA 3.0 |
added 785 characters in body
|
| Jan 3, 2017 at 17:53 | history | edited | Deniz Erdal | CC BY-SA 3.0 |
added 3 characters in body
|
| Jan 3, 2017 at 16:40 | comment | added | MonkeyZeus | I think you should step back and re-evaluate your situation. You state that developers say that removing the sort feature will improve performance. Next you say that that the data grid is fast; so there is no performance to be gained, correct? So this leads me to believe that the devs are incompetent and want to hide a data discrepancy by not allowing users to sort. So sorting is not slow, it's broken... Please correct me if I am wrong. | |
| Jan 3, 2017 at 16:14 | answer | added | Josh Olsen | timeline score: 10 | |
| Jan 3, 2017 at 16:11 | answer | added | Micah Montoya | timeline score: 25 | |
| Jan 3, 2017 at 16:07 | comment | added | Cody Gray | You will seriously piss off power users if you blindly follow heat-mapping data. Just because most users—even >90%—don't use something doesn't mean that no one uses it. And if you piss off power users, you might as well kiss your product goodbye, because they're either your biggest cheerleaders or the reason no one else uses your application, either. | |
| Jan 3, 2017 at 15:54 | history | edited | Deniz Erdal | CC BY-SA 3.0 |
added 716 characters in body
|
| Jan 3, 2017 at 15:53 | answer | added | Kristiyan Lukanov | timeline score: 4 | |
| Jan 3, 2017 at 15:29 | answer | added | kettch | timeline score: 40 | |
| Jan 3, 2017 at 15:07 | history | tweeted | twitter.com/StackUX/status/816300016637710336 | ||
| Jan 3, 2017 at 14:33 | answer | added | DarrylGodden | timeline score: 1 | |
| Jan 3, 2017 at 13:34 | answer | added | Jasmin Javia | timeline score: 1 | |
| Jan 3, 2017 at 13:34 | answer | added | Alvaro | timeline score: 86 | |
| Jan 3, 2017 at 13:27 | history | asked | Deniz Erdal | CC BY-SA 3.0 |