Skip to end of metadata
Go to start of metadata

Purpose: Demonstrates recommended table layout, styling, and configuration for use with tabular data.

Category: Tables, Tabular Data, Datatables

Related jiras: UXI-283 - Data cannot be retrieved due to an unexpected error UXI-205 - Data cannot be retrieved due to an unexpected error

Process Phase:

  • UXI JIRA Created (insert link above)
  • Component Specification draft complete
  • UXI code review complete
  • Reconcile with UIM and KRAD existing designs
  • Conduct user testing (if needed)
  • Routed for review with Kuali UX Working Group and UX/KRAD Working Group
  • Reviewed with KAI
  • Rice JIRA Created (in KULRICE Project)
  • KRAD Implementation complete
  • Component released (insert rice release version below)

Version: 1.0



The objective of tables is to present information in a way that preserves relationships within the information even when users cannot see the table or the presentation format is changed. Information is considered tabular when logical relationships among text, numbers, images, or other data exist in two dimensions (vertical and horizontal). These relationships are represented in columns and rows, and the columns and rows must be recognizable in order for the logical relationships to be perceived.

Datatables are tables that have been enhanced with the jquery.datatables.js plugin, which allows column ordering and sorting, data filtering, and table pagination. Tables by themselves are fairly accessible, but consideration should be taken when enhancing them with the datatables plugin.

This document provides requirements and recommendations for markup and styles, as well as accessibility information and considerations.


The license could not be verified: License Certificate has expired!

  • No labels


  1. Issues with the first spec:

    • We already use the Details language elsewhere for similar functionality within the table - is this an extension or alternate option to this functionality?
    • We already have grouping within a table implemented
  2. Is inline editing only for tables?  If so it needs to be explicitly stated here.  We also need to explain whether or not all controls types are supported.

    1. It appears we are using the inline edit language for 2 separate functionalities, we need to rename this one to edit row or something

  3. Change language from “inline editing” to “in row editing” because inline editing is a separate function within KRAD.

    This new component may replace what currently exists in KRAD:

    1. I thought we were still on the fence about the wholesale replacement (maybe as an option?).  The current version still has value in being able to see multiple details at once which the new version cannot solve, since the new version requires open dialog -> close dialog -> open dialog -> try to remember what was in first dialog

      1. Changed "would" to "may" - I agree that this is still a discussion.

  4. I'm curious about the necessity of the "sectioning" in the table above: "Sections within a table received a colspan <td> with the class of "row-separator". This will give it a gray background with bolded text as seen above.

      • Used to separate groups of content within a table collection"

    I'm wondering when and why we would use that? Why not just use two tables? It seems that the addition of these sections would serve to undercut the sortability that makes tables useful in the first place. Using two tables would avoid having items in a column that aren't actually related to the column header (e.g. "From Proposal..." sitting in the Person column)

    1. This also would require the manual separation of these related things into multiple data sets that those tables could use (and then putting them all back together to persist).  This also can be done if the design calls for it.

      Value in this is seeing all related objects in the same table, but categorized by some type that makes sense.  Also, sorting within each category itself still works.

      1. I am still having a hard time thinking of scenarios where that would provide a lot of added utility, but if it's an optional feature, it probably wouldn't hurt to have as an option.

  5. Per UX Working Group meeting on 6.5.14
    1. Seems like a lot of lines. KS got rid of vertical lines, but kept horizontal just to reduce visual clutter


      2. Looking at displaying tabular data vs. search results (above link is search results)

      3. Above example does display an issue with the sorting functionality - which header label does the sort apply to?

      4. Without vertical lines how does this look when screen size is smaller?
  6. KSAP is working on some tables for the bottom half of the Course Details page that will have functionality of clicking on the entire row to add an item: . Love this screen's design... 

  7. Please add the specification and interaction for adding and deleting lines from tables to this spec.  See KULRICE-5284.  

  8. From KAI 6.12.14:

    1. What use cases where it’s helpful when something appears read-only but is editable when click Edit? Cleaner appearance.

    2. Might potentially be use cases for bulk editing/checkboxes.
  9. I've added additional table markup examples on JSFiddle for tables with only horizontal dividing lines (simple class change) as well as un-sectioned tables for those cases where sorting with sections is a technical problem.

    As for sorting within tables that have sections, I imagined the sorting would still function as intended, but sort per section too. But I guess that's kind of confusing technically. How about tables that don't have sorting (like those found in Budget Personnel, Non-Personnel, etc.) we use the sectioned tables, and tables that have a lot of data that may need to be sorted, we use unsectioned tables? Examples of both can be found in the JSFiddle.

  10. Please add the following to the spec: How would you "select" something from the table.  I.E. UXI-278.


    We need to be consistent with how we are selecting an item from a collection.

    In some cases, we make the unique identifier the link to open the item:

    In other cases, we have a "select" button. (sponsor lookup)

    In other cases, we have a radio button. (add personnel)

    The recommended design should be spec'd in this component spec.

  11. Need to indicate interactions for adding, deleting, modifying content in tables.

    Need to indicate how to show more details about a row.

    Need to show mobile view.

    1. Christie, see the "Working with content" tab.

  12. Issues regarding the consistent interaction for selecting a row will be resolved with the new list/search results component.  This component spec can be considered complete.