3 ms·

Good searching and filtering should be on the first place. May be you don't need long tabular presentation at all because of this.

by bvrmn 7y ago

omgtehlion 7y ago
Sometimes it is better to take advantage of web browser builtin search function (Ctrl+F). Unfortunately some overly-eager implementations break it when supplanting with their own...
- bvrmn 7y ago
  Most real data is too big to fetch in one piece by a client. Internal admin interfaces come to mind. On each job every time support people ask to include monstrous sorting behavior over multiple columns to be able to find group in question. However simple search would be enough.
  - omgtehlion 7y ago
    Yeah. There are different sizes of data, that's why there is no good control for everyone. Size of data can be: 1. Small, so you can display it all at once and the user will have luxury to ctrl+f what he/she wants; 2. Big to display, but small enough to push to client: then you will need to create pagination or virtualized view. Ctrl+F will not work (at least without some tricks), but you can easily filter/search it yourself in JS; 3. Too big to transfer: the only way to search/filter is on the server and separate controls (of course Ctrl+F won't work).
    - TeMPOraL 7y ago
      I'm worried at what size 1 becomes 2. I've seen web tables that choke on 100 rows. I feel that if a table can't handle 10-100x that without destroying site's performance, it's done wrong. I also wonder whether we shouldn't have new <table> tag, meant specifically for data tables. Say, <datatable>. It would have all sorts of sorting and filtering and pivot tables built-in, and it could exploit native code to ensure high performance. Case 3 could be handled by a well-defined API that translates table operations to JS calls, in case a full dataset can't be sent to the browser.
      - omgtehlion 7y ago
        It will be a heck of API to agree on. And then to implement correctly. As another poster linked ag-grid this is how API surface should look like: https://www.ag-grid.com/javascript-grid-server-side-model/ https://www.ag-grid.com/javascript-grid-server-side-model/
LeonM 7y ago
This. I've been preaching this for years now. Paging is an anti pattern. You need good search and filters, not paging. With paging all you do is overload the user with information, forcing them to scan mountains of irrelevant data over and over again until they find what they were looking for. If you need paging, your UX design is wrong.
- davidivadavid 7y ago
  That's a really good heuristic, but unfortunately, lots of users are still stuck in the "I need an exhaustive list of all of our data, ever"-mindset because that's what their manager mandates. Then they print it and put it in a drawer. shrug
kgwxd 7y ago
This can be overkill for searching something like a product catalog, though I'd love to have something this detailed on Amazon. For exploring large data sets with hundreds of data points, it's required, and paying customers will demand it because they know how much it helps them do their work without having to request and wait for new features every time a new type of use case comes up.

Good searching and filtering should be on the first place. May be you don't need long tabular presentation at all because of this.

by bvrmn 7y ago

Good searching and filtering should be on the first place. May be you don't need long tabular presentation at all because of this.

omgtehlion 7y ago

Sometimes it is better to take advantage of web browser builtin search function (Ctrl+F). Unfortunately some overly-eager implementations break it when supplanting with their own...

bvrmn 7y ago
Most real data is too big to fetch in one piece by a client. Internal admin interfaces come to mind. On each job every time support people ask to include monstrous sorting behavior over multiple columns to be able to find group in question. However simple search would be enough.
- omgtehlion 7y ago
  Yeah. There are different sizes of data, that's why there is no good control for everyone. Size of data can be: 1. Small, so you can display it all at once and the user will have luxury to ctrl+f what he/she wants; 2. Big to display, but small enough to push to client: then you will need to create pagination or virtualized view. Ctrl+F will not work (at least without some tricks), but you can easily filter/search it yourself in JS; 3. Too big to transfer: the only way to search/filter is on the server and separate controls (of course Ctrl+F won't work).
  - TeMPOraL 7y ago
    I'm worried at what size 1 becomes 2. I've seen web tables that choke on 100 rows. I feel that if a table can't handle 10-100x that without destroying site's performance, it's done wrong. I also wonder whether we shouldn't have new <table> tag, meant specifically for data tables. Say, <datatable>. It would have all sorts of sorting and filtering and pivot tables built-in, and it could exploit native code to ensure high performance. Case 3 could be handled by a well-defined API that translates table operations to JS calls, in case a full dataset can't be sent to the browser.
    - omgtehlion 7y ago
      It will be a heck of API to agree on. And then to implement correctly. As another poster linked ag-grid this is how API surface should look like: https://www.ag-grid.com/javascript-grid-server-side-model/ https://www.ag-grid.com/javascript-grid-server-side-model/

LeonM 7y ago

This. I've been preaching this for years now. Paging is an anti pattern. You need good search and filters, not paging. With paging all you do is overload the user with information, forcing them to scan mountains of irrelevant data over and over again until they find what they were looking for. If you need paging, your UX design is wrong.

davidivadavid 7y ago
That's a really good heuristic, but unfortunately, lots of users are still stuck in the "I need an exhaustive list of all of our data, ever"-mindset because that's what their manager mandates. Then they print it and put it in a drawer. shrug

kgwxd 7y ago

This can be overkill for searching something like a product catalog, though I'd love to have something this detailed on Amazon. For exploring large data sets with hundreds of data points, it's required, and paying customers will demand it because they know how much it helps them do their work without having to request and wait for new features every time a new type of use case comes up.