Using optimized and non-optimized tables
Using optimized and non-optimized tables
Tables as a structural component
When adding a table layout to your application, you can configure a table to be optimized or non-optimized. Optimized tables offer new features and functionalities to improve user experiences, but have slight differences in capabilities compared to non-optimized tables. Understanding the functional and configurable differences between the two configurations is essential for designing your applications to meet your user needs.
Accessibility features and benefits of optimized tables
The optimize code configuration setting was introduced a few years ago as a dive into new capabilities in browser and front-end technology to create a modern table layout with a more accessible experience. Following are some of the enhanced and new capabilities when optimizing your tables.
End-user personalization
With the optimize code checkbox enabled on a table, you can allow end users to personalize tables. End users can modify which table properties are presented in the columns, adjust the order and width of columns, and sort and filter as necessary. After making their desired personalization changes, users can save their customizations as one or more table views that can be swapped out or modified at any time.
Search capabilities
Optimized code also allows users to easily search for specific data in an optimized table. This, in combination with the personalization features, allows for an efficient and user-friendly experience when viewing or manipulating the table data at runtime. In numerous scenarios, especially those with large amounts of data and many unique columns, the speed and ease that users can find the information in the table has been greatly improved.
Cleaner markup
One great stride for a cleaner and more accessible experience can be seen in the underlying markup in the DOM (Document Object Model) that comprises an optimized table.
In non-optimized tables, the component contains a much larger amount of pure markup than the optimized variant, to account for some of the table’s formatting and structure. With just one table tag in the markup of an optimized table, screen reader users can understand the structure and content of the table more easily, and accessibility testers will see less issues in both automated and manual testing. The reduced amount of markup consequently improves browser processing as well.
Keyboard users can easily navigate column headers and cells in optimized tables. Focusing on the headers of a table behaves very similarly to a tab group. Once a user focuses on one of the headers, they can use the arrow keys to navigate between headers. Pressing Enter allows the user to use the sort and filter menu options easily. From here, pressing escape returns focus to the header itself. Within the table cells, using the tab key will focus on the interactive elements within cells, rather than entire cells themselves. Arrow keys will allow users to navigate between data cells within the table contents, and screen reader users will hear those contents announced to them as focus moves. Following is a breakdown of this navigation pattern:
- Tab or keyboard shortcut to bring focus within the table.
- Arrow keys to navigate between cells.
- Enter key to bring focus within the currently focused cell.
- Arrow keys to move within the cell's interactive elements.
- Escape to exit the cell.
This navigation style is modeled from the grid layout standard in the WAI (Web Accessibility Initiative) authoring practices.
Captions
Optimized tables allow users to add a caption tag within the table itself. The caption allows users to add further contextual information to the table, without needing to squeeze all the necessary information into the table title. It is also useful for screen reader users to have extra information on the contents of the table they are interacting with.
Responsive UI
Depending on the amount of data sourcing a table, the length of the data, and the number of properties displayed, you may find yourself with quite a sizable table. Optimized tables have moved away from using forced size adjustments through JavaScript, and instead naturally resize and align themselves respective to the browser dimensions. This not only helps with performance but provides a consistent and flexible experience for various user groups and channels.
Key differences between optimized and non-optimized tables
As shown, optimized tables can provide a wide range of improvements across several areas of user experience. When considering which table to use in your application for your needs, it is best to weigh the differences between both table types in configuration and user experience.
The main difference in user experience between optimized and non-optimized tables comes in the form of users navigating a table with the keyboard. Non-optimized tables primarily use the tab key to navigate the headers and rows in the table. However, tab navigation will only allow for navigation to the following parts of the table:
- Table headers, including any interactive elements in a header cell such as a filter icon.
- The first cell of each row in the table. This is goes up and down the rows (depending on tab or shift+tab) with focus remaining on the first cell of each row.
- Any cells containing interactive elements.
This navigation style primarily targets interactive elements within the table, with the exception being the first cell of each row. Keyboard users would be unable to move to each individual cell using tab, and assistive technology users would use keyboard shortcuts to navigate between cells if needed.
Row editing and source
While both optimized and non-optimized tables have configuration options that allow for table data editing at runtime, non-optimized tables also offer the "Master-detail" editing option. This allows for users to edit row contents either in a modal dialog or directly beneath the row in a section that can expand and collapse. In the case that having minimal modal dialogs in the applications is a requirement, this form of row editing offers a viable alternative.
When sourcing your table, only non-optimized tables allow a report definition as a source for the table data. This is generally not recommended as it can lead to lowered performance as the report definition will query the source for data each time the table is rendered. The recommendation is to move towards using other options such as data page as a source to take full advantage of the advantages of optimized tables.
Following is a breakdown of some of the configuration options present in both table configurations:
| Table type | Keyboard Navigation | Labelling | Sort and Filter | Unique Personalization | Search Data | Performance | Source | Row editing |
|---|---|---|---|---|---|---|---|---|
| Optimized | Arrow keys/Enter | Grid Caption | Yes | Reorder/Resize/Group/Hide/Save columns | Yes | Less performance impact | Property/Data Page | In modal |
| Non-optimized | Tab | Grid Summary (deprecated) | Yes | Reorder/Resize columns | No | Greater performance impact | Property/Data Page/Report Definition | In modal/In-line/Expandable Rows |
Going forward with using tables
The optimize code checkbox brings with it several enhancements and new functionalities. However, it is good to be cognizant of what configuration options are supported and what are not.
Though it is an ongoing work-in-progress with new features and enhancements being added over releases, optimized tables currently do not have all the features that a non-optimized table presents, such as master-level detail editing and report definition as a data source. Depending on your application requirements and the origin of your data, these differences may be decisive factors in determining which table is best for you, so it’s best to consider which options work best for your application and user needs.