4 ms·

"Now the programming cost of allowing filtering by anything is minimal" Not only is this not true except in your imaginary app but it's also disregarding the i

"Now the programming cost of allowing filtering by anything is minimal" Not only is this not true except in your imaginary app but it's also disregarding the incredibly bad UI that can come from allowing everything to be filtered. A good design has constraints and thoughtful choices. A shitty design has everything possible thrown on the screen because "allow filtering by anything is minimal".

Joeri 10y ago
A good metadata layer can generate appropriate filter controls, so it is the case that a system can be architected so that filtering by anything provides little programming overhead. The system that i work on is like this. Whenever you see a grid, you can filter by any column, with appropriate controls for that column's datatype. Whether it is desirable to do such a thing depends on the nature of the product and its users, but my point is that the dev overhead can indeed be minimal.
sitkack 10y ago
> except in your imaginary app That kind of language isn't going to further the discussion. --- Arbitrarily adding constraints doesn't make design better. The default container for tabular data probably should allow for sorting by any column. Show the OP the benefit of the doubt.
wallacoloo 10y ago
This is highly application-specific. If you're looking for components to use in some design, for example, it's useful to have the component value, power rating, cost, form-factor, etc, all displayed together and filterable/sortable. If the application doesn't allow for filtering in this context, then that's something that the user ends up doing mentally. Worse, if the application doesn't allow all this information to be displayed as a summary, you end up with 50+ products for which you have to manually click a link and skim the product brief of each one individually. For example, here's Newarks's procuct chooser [1]. You can sort and filter by any field. It remains uncluttered by default-populating only the most commonly-used fields, but it avoids sacrificing any capabilities via making these hidden fields easy to access (click the "extended" button right above the table header). I'd like to point out that in lists like these, the parent comment is 100% correct in saying "[the] cost of allowing filtering by anything is minimal". And while I'm sure an experienced designer could improve the UI, this is a scenario in which sacrificing capability for beauty is absolutely an inappropriate thing to do. [1] http://www.newark.com/eeprom http://www.newark.com/eeprom

Joeri 10y ago

A good metadata layer can generate appropriate filter controls, so it is the case that a system can be architected so that filtering by anything provides little programming overhead. The system that i work on is like this. Whenever you see a grid, you can filter by any column, with appropriate controls for that column's datatype. Whether it is desirable to do such a thing depends on the nature of the product and its users, but my point is that the dev overhead can indeed be minimal.

sitkack 10y ago

> except in your imaginary app That kind of language isn't going to further the discussion. --- Arbitrarily adding constraints doesn't make design better. The default container for tabular data probably should allow for sorting by any column. Show the OP the benefit of the doubt.

wallacoloo 10y ago

This is highly application-specific. If you're looking for components to use in some design, for example, it's useful to have the component value, power rating, cost, form-factor, etc, all displayed together and filterable/sortable. If the application doesn't allow for filtering in this context, then that's something that the user ends up doing mentally. Worse, if the application doesn't allow all this information to be displayed as a summary, you end up with 50+ products for which you have to manually click a link and skim the product brief of each one individually. For example, here's Newarks's procuct chooser [1]. You can sort and filter by any field. It remains uncluttered by default-populating only the most commonly-used fields, but it avoids sacrificing any capabilities via making these hidden fields easy to access (click the "extended" button right above the table header). I'd like to point out that in lists like these, the parent comment is 100% correct in saying "[the] cost of allowing filtering by anything is minimal". And while I'm sure an experienced designer could improve the UI, this is a scenario in which sacrificing capability for beauty is absolutely an inappropriate thing to do. [1] http://www.newark.com/eeprom http://www.newark.com/eeprom