A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
2 added 70 characters in body
source | link

Tables are soooo 90s (they are about to turn 30)

HTML tables were proposed in 1993 and took off around 1996. During this time, few considered accessibility and even less predicted responsive design. UX was never considered in the process.

This case isn't unique, there are many other HTML standards that nowadays look ludicrous - selects and radio groups all have design and usability flaws.

The real problem is that (due to the existence bias) designers keep applying familiar solutions to new problems. The killer feature in tables is their auto-fit ability, which is really a presentation businessbusiness; other than that, they offer little compared to alternative solutions.

A complex component

In contrast to their original intent, the various features tables might need in today's web are nothing short of monstrous. Amongst them:

  • Column resize
  • Column show/hide
  • Sorting
  • Sticky header/column
  • Hierarchical header
  • Inline editing
  • Row editing
  • Single row-selection
  • Multi select
  • Progressive loading
  • Summary rows
  • Responsive support
  • Accessibility support

The point is that there isare so many requirements for tables that aren't part of the HTML standard that you may just as well write your own component, and you may just as well not base it on HTML tables.

Enter grids

Having struggled with tables a lot, particularly with exactly the same issues you mention, this is what I've found to work much better:

  • Instead of using tables, use a simple <ol><li></li></ol> markup. This make it accessible.
  • Use CSS to remove the list presentation.
  • Use grids to create a table presentation. This makes it responsive.

This is what the bare version looks like:

A screenshot of a table

Now this will obviously work under a very limited set of requirements; namely, when you are happy with fixed (and constrained) column widths. The benefit is that you get an orderly visual flow for the whole page, which normal tables nearly always break.

So for more complex tables we had to tuck in some javascript and for the really complex stuff the whole presentation was javascript based (so no CSS grids).

Progressive disclosure

Another thing about tables worth remembering, particularly with large datasets, is that again - we use a solution without considering the problem. In other words, we throw everything at the user.

From a UX perspective, there's a limited amount of information people can digest and more often than not there is limited amount of information they really need.

So the way we solved it is by using table views to allow users to locate with ease the record of interest, but only showing columns that may be of 'locate interest'.

Additional data is either presented as a tool tip, or by collapse - clicking on a row reveals the full record (or on mobile will actually 'navigate' to the detailed view).

This practice also promote accessibility with the 'table' row marked (eg, aria-label) as 'overview' and the collapsed area as 'full details'.

Tables are soooo 90s

HTML tables were proposed in 1993 and took off around 1996. During this time, few considered accessibility and even less predicted responsive design. UX was never considered in the process.

This case isn't unique, there are many other HTML standards that nowadays look ludicrous - selects and radio groups all have design and usability flaws.

The real problem is that (due to the existence bias) designers keep applying familiar solutions to new problems. The killer feature in tables is their auto-fit ability, which is really a presentation business.

A complex component

In contrast to their original intent, the various features tables might need in today's web are nothing short of monstrous. Amongst them:

  • Column resize
  • Column show/hide
  • Sorting
  • Sticky header/column
  • Hierarchical header
  • Inline editing
  • Row editing
  • Single row-selection
  • Multi select
  • Progressive loading
  • Summary rows
  • Responsive support
  • Accessibility support

The point is that there is so many requirements for tables that aren't part of the HTML standard that you may just as well write your own component, and you may just as well not base it on HTML tables.

Enter grids

Having struggled with tables a lot, particularly with exactly the same issues you mention, this is what I've found to work much better:

  • Instead of using tables, use a simple <ol><li></li></ol> markup. This make it accessible.
  • Use CSS to remove the list presentation.
  • Use grids to create a table presentation. This makes it responsive.

This is what the bare version looks like:

A screenshot of a table

Now this will obviously work under a very limited set of requirements; namely, when you are happy with fixed (and constrained) column widths. So for more complex tables we had to tuck in some javascript and for the really complex stuff the whole presentation was javascript based (so no CSS grids).

Progressive disclosure

Another thing about tables worth remembering, particularly with large datasets, is that again - we use a solution without considering the problem. In other words, we throw everything at the user.

From a UX perspective, there's a limited amount of information people can digest and more often than not there is limited amount of information they really need.

So the way we solved it is by using table views to allow users to locate with ease the record of interest, but only showing columns that may be of 'locate interest'.

Additional data is either presented as a tool tip, or by collapse - clicking on a row reveals the full record (or on mobile will actually 'navigate' to the detailed view).

This practice also promote accessibility with the 'table' row marked (eg, aria-label) as 'overview' and the collapsed area as 'full details'.

Tables are soooo 90s (they are about to turn 30)

HTML tables were proposed in 1993 and took off around 1996. During this time, few considered accessibility and even less predicted responsive design. UX was never considered in the process.

This case isn't unique, there are many other HTML standards that nowadays look ludicrous - selects and radio groups all have design and usability flaws.

The real problem is that (due to the existence bias) designers keep applying familiar solutions to new problems. The killer feature in tables is their auto-fit ability, which is really a presentation business; other than that, they offer little compared to alternative solutions.

A complex component

In contrast to their original intent, the various features tables might need in today's web are nothing short of monstrous. Amongst them:

  • Column resize
  • Column show/hide
  • Sorting
  • Sticky header/column
  • Hierarchical header
  • Inline editing
  • Row editing
  • Single row-selection
  • Multi select
  • Progressive loading
  • Summary rows
  • Responsive support
  • Accessibility support

The point is that there are so many requirements for tables that aren't part of the HTML standard that you may just as well write your own component, and you may just as well not base it on HTML tables.

Enter grids

Having struggled with tables a lot, particularly with exactly the same issues you mention, this is what I've found to work much better:

  • Instead of using tables, use a simple <ol><li></li></ol> markup. This make it accessible.
  • Use CSS to remove the list presentation.
  • Use grids to create a table presentation. This makes it responsive.

This is what the bare version looks like:

A screenshot of a table

Now this will obviously work under a very limited set of requirements; namely, when you are happy with fixed (and constrained) column widths. The benefit is that you get an orderly visual flow for the whole page, which normal tables nearly always break.

So for more complex tables we had to tuck in some javascript and for the really complex stuff the whole presentation was javascript based (so no CSS grids).

Progressive disclosure

Another thing about tables worth remembering, particularly with large datasets, is that again - we use a solution without considering the problem. In other words, we throw everything at the user.

From a UX perspective, there's a limited amount of information people can digest and more often than not there is limited amount of information they really need.

So the way we solved it is by using table views to allow users to locate with ease the record of interest, but only showing columns that may be of 'locate interest'.

Additional data is either presented as a tool tip, or by collapse - clicking on a row reveals the full record (or on mobile will actually 'navigate' to the detailed view).

This practice also promote accessibility with the 'table' row marked (eg, aria-label) as 'overview' and the collapsed area as 'full details'.

1
source | link

Tables are soooo 90s

HTML tables were proposed in 1993 and took off around 1996. During this time, few considered accessibility and even less predicted responsive design. UX was never considered in the process.

This case isn't unique, there are many other HTML standards that nowadays look ludicrous - selects and radio groups all have design and usability flaws.

The real problem is that (due to the existence bias) designers keep applying familiar solutions to new problems. The killer feature in tables is their auto-fit ability, which is really a presentation business.

A complex component

In contrast to their original intent, the various features tables might need in today's web are nothing short of monstrous. Amongst them:

  • Column resize
  • Column show/hide
  • Sorting
  • Sticky header/column
  • Hierarchical header
  • Inline editing
  • Row editing
  • Single row-selection
  • Multi select
  • Progressive loading
  • Summary rows
  • Responsive support
  • Accessibility support

The point is that there is so many requirements for tables that aren't part of the HTML standard that you may just as well write your own component, and you may just as well not base it on HTML tables.

Enter grids

Having struggled with tables a lot, particularly with exactly the same issues you mention, this is what I've found to work much better:

  • Instead of using tables, use a simple <ol><li></li></ol> markup. This make it accessible.
  • Use CSS to remove the list presentation.
  • Use grids to create a table presentation. This makes it responsive.

This is what the bare version looks like:

A screenshot of a table

Now this will obviously work under a very limited set of requirements; namely, when you are happy with fixed (and constrained) column widths. So for more complex tables we had to tuck in some javascript and for the really complex stuff the whole presentation was javascript based (so no CSS grids).

Progressive disclosure

Another thing about tables worth remembering, particularly with large datasets, is that again - we use a solution without considering the problem. In other words, we throw everything at the user.

From a UX perspective, there's a limited amount of information people can digest and more often than not there is limited amount of information they really need.

So the way we solved it is by using table views to allow users to locate with ease the record of interest, but only showing columns that may be of 'locate interest'.

Additional data is either presented as a tool tip, or by collapse - clicking on a row reveals the full record (or on mobile will actually 'navigate' to the detailed view).

This practice also promote accessibility with the 'table' row marked (eg, aria-label) as 'overview' and the collapsed area as 'full details'.