New - Document List Component

[owensgit]

Type of request
New component / pattern

Component, pattern or foundation?
Component or Pattern - not sure which :)

Nature of request

This was originally intended to be added to Canopy, but due to time pressures it was instead implemented as a custom component.

I'd like to now add this to Canopy as a new component.

It renders a list of documents that the user has, with the ability to show unread documents.

Screenshot shows the current custom build.

Proposed API

<lg-document-list>
  <lg-document-list-item
    [read]="true"
    [url]="documentUrl"
  >
    <lg-icon name="pdf"></lg-icon>
    {{documentName}}
    <lg-document-list-item-date [date]="unixTimestamp">
      <!-- can also manually add text if needed, 
           but date input preferred -->
    </lg-document-list-item-date>
    <lg-document-list-item-size>
      100 - 500kb
    </lg-document-list-item-size>
  </lg-document-list-item>
</lg-document-list>

[elenagarrone]

Thanks for submitting the request @owensgit 👍

My first thought is: do we need a specific component for this? why not use a simple Canopy table and create a pattern? That's how it is in one of our project:

If we go with your approach how would you develop it semantically?
My assumption is that it would be:

• lg-document-list => role="list"
• lg-document-list-item => role="listitem" and have an inner button that wraps the whole content?

And the components would have to add some access text e.g. the lg-document-list-item should add text like PDF before or after the document name, the lg-document-list-item-size should say Size: <size-data>, etc.

Also, on another note I don't think the dot for "read/unread" is very intuitive 🤔

[michelleallendavey]

Yeah I think we're going to have limited time in my current product team for this so potentially either using the existing non-Canopy component, or making this a Canopy component that we come back to later would be a good option for us I think... (though I suspect Alex might have something to say about the latter plan 😃

If we were to use a table, are we able to make a whole row clickable like it is in the existing non-Canopy component? Or would it have to be a link like the example Elena added above?

[owensgit]

Thanks @michelleallendavey, I'm happy to convert the existing non-Canopy component into Canopy so it can be used by both teams, and others. It seems like the right thing to do considering it's already needed for two produc types and there won't be any time seem to revisit the design. @alexcanning @elenagarrone are you also happy with this approach?

If we were to use a table, are we able to make a whole row clickable like it is in the existing non-Canopy component?

It's possible, but I don't think that's a good idea for a table, given that users may want to copy and past data from a column - e.g. payment history table containing dates, amounts, descriptions etc. If we were to use a table, I would recommend just making the title clickable.

[elenagarrone]

@owensgit form a development point of view, if you have time to consider accessibility for it then I think we can add it.

Instead of the list role we could use the table role: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/table_role
Also from an accessibility point of view we should add the read/unread as a new column.

I don't think just copy pasting the non-canopy component is enough. We should make it better if we add it to the library :/ otherwise it's easier to use the table which is more accessible.

[alexcanning]

My preference would be to not convert the existing non-Canopy component for the reasons articulated previously - it was a placeholder which is not distinct enough from the table component. If we're not designing something wholly different, we should just use a table with traditional links for document titles.

[owensgit]

Cool thanks all, I'll leave the originally component as-is for now 👍

[owensgit]

Decision: Do no implement
This component was orignally a placeholder and not intended for wider use. The design team would like to revisit it to fully consider the final design and accessibility. For now teams should use the existing Table component.