Skip to end of metadata
Go to start of metadata
Comparison Tables

Purpose: Demonstrates recommended table layout and configuration for use with comparison tables which are used to compare two or more different versions of something.

Category: Tables, Comparison tables

Related jiras: UXI-289 - Data cannot be retrieved due to an unexpected error KULRICE-8881 - 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

Description

Comparison tables are used to present information for two or more items or versions, often identifying the differences between the items via row highlighting or other visual indicators. One objective is to present the information in such a way that preserves the relationships within the information even when users cannot see the table or when the presentation format is changed. Information is considered tabular when logical relationships among the text, numbers, images, or other data exists 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. 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

13 Comments

  1. Is the styling on this table complete? The JSFiddle example is looking somewhat incomplete and different from what tables look like currently. It is looking like a spreadsheet table that is housing a table, headers, labels, etc. Some items that seem strange are:

    • Spacing: Seems like there should be some padding separating the different sections (course info, Crosslisting) to make it easier to track what information belongs in what section, and the headers shouldn't be intruding into the comparison area (e.g. "Course Information" sits between "Version 2" and Version 2's information, except when the screen is very wide).
    • Cell Borders: The border lines are showing throughout the example, which can be awkward (most notable the upper left empty "cell") and reinforce the look of an spreadsheet page.

     

  2. The styling on JSFiddle includes Bootstrap styles, but not our additional table styles. The goal is to illustrate proper markup and usage.

    I can add in our additional stylesheets if you think that'd be more helpful? I'd just need to link to a publicly accessible CSS file...

  3. I think my confusion was coming from the purpose as written above: "Demonstrates recommended table layout, styling, and configuration for use with comparison tables." In particular, the point about styling. Are we not trying to land on a final style/universal with these components?

  4. Per UX Rice KRAD Working Group on 6.4.14

    Do users need the ability to make edits in a column with new values? Are there use cases for this? Maintenance docs? Check with KAI.

    1. Yes, we will need to support the "new" column being editable.  It was discussed at KAI that it doesn't make sense to have the approver view (with two read only columns) look different than the initiator view.  Whether we can do away with the two column view for initiator is a larger usability question that we will need to investigate at a later time.

  5. I have several questions, especially given the latest fact that this is supposed to be editable.

    • Now that this component is editable what is the main functional difference between it and the standard table maintenance view? Is it just the 'grouping' aspect. I question why making this component now.

    Here is image of current table maintenance view:

    Here is image of new component:

    • The spec says 2 or more versions can be shown. I am coding it that the user will define the number of versions (actually properties), the order, and which ones are editable. A developer will have to layout this component defining the location of headers and fields that will be displayed.
    <bean parent="Uif-TableComparison3">
    <property name="propertyNames">
    <list>
    <value>oldDummyData</value>
    <value>newDummyData</value>
    <value>dummyData3</value>
    </list>
    </property>
    <property name="items">
    <list>
    <bean parent="Uif-HeaderTwo" p:headerText="Group 1"/>
    <bean parent="Uif-DataField" p:label="field1" p:propertyName="field1"/>
    <bean parent="Uif-DataField" p:label="field2" p:propertyName="field2"/>
    <bean parent="Uif-HeaderThree" p:headerText="Group 2"/>
    <bean parent="Uif-DataField" p:label="This is Field1" p:propertyName="field1"/>
    <bean parent="Uif-DataField" p:label="field3" p:propertyName="field3"/>
    <bean parent="Uif-HeaderFour" p:headerText="Group 3"/>
    <bean parent="Uif-DataField" p:label="Boolean 1" p:propertyName="bool1"/>
    <bean parent="Uif-DataField" p:label="Boolean 2" p:propertyName="bool2"/>
    </list>
    </property>
    </bean>
    • How should this component show subobjects that are lists? For instance the old version has a course of english and PE, new version has chem, english, and history. Not sure how to do side by side compares. How determine the primary key for the subobjects.
    • Not sure how can call this new component complete until there is an actual developer in another project using it.
  6. Jeff Heckel, to answer your questions:

    1. We are investigating the answer to this first question. William Washington submit this as an idea a while ago, but we're also curious what the "missing piece" is between comparison tables and maintenance tables.
    2. Un/ordered list items should appear as lists, using list markup. Since the comparison (and maintenance?) tables show those values that are different, the list(s) should be shown in all present columns indicating that the values were changed.

     

  7. Chris, I think will need to talk about the lists. Unclear still on how to deal with them and the editing capability. May need some examples from you. Here is a more recent screen shot:

  8. The JIRA created by William which spawned the creation of this component spec was just requesting that the changed fields in a maintenance doc be highlighted somehow.  Sorry for any confusion.  The spec for this brings the maintenance view in line with the design of the rest of the tables, plus it incorporates the highlighted rows for changed fields.

    1. Perhaps so where do I go with this? The new layout and look, along with grouping, are not in current maintenance view. Grouping is not something that I can see being added into current setup. I think a review/talk on this in the next meeting would be useful.

  9. Per UX Rice Working Group 6.25.14:

    KHR needs this for a transactional document. Needs to be editable. This is also a KNS equivalency item vs. just being a new component. Jeff H, Matt S, and Jerry will discuss this post-meeting.

  10. View with standard, existing components.

  11. This is meant to replace the existing KRAD comparison tables.  We are going to move forward and put this in V1 of the design guide so that styling is in line with the table/collection component spec.  We also are going to look at making this more responsive for approvers so they can quickly review/approve a change on any device.  

    To Do:

    • Investigate options to show only changed rows.