Details view

[jeffmcaffer]

Need a reusable component that shows the full detail of a definition. It should optionally allow editing of the values in definition in a way that is shareable with other components. That is, the detail component described here does not "own" the definition. This component will show up in two primary places/ways

1. as a popup/overlay on the main Definitions page when the user wants to dive into a given definition in the list
2. as an independent page with a deep link URL allowing users to talk about definitions and reference them easily

A mockup of the page is in the jm/detailsPage branch. This is just a mockup and is not intended to be the implementation. There is tons of duplicate code etc

some key points

• the details component should be standalone so it can be used in page, an overlay, ...
• Over time we will undoubtedly redesign the layout.
• As the user progresses from the two line entry to the expanded panel to the full details view of the component, the experience should be smooth. With visual and content continuity. They are just looking at more data about the same thing so the data they have already seen should be similar.

There are a few new components and related features that will show up here

• Facet picker (https://github.com/clearlydefined/website/issues/202)
• File List (https://github.com/clearlydefined/website/issues/191)
• Editing (https://github.com/clearlydefined/website/issues/196)

[AlexWebYourmind]

Hi @jeffmcaffer (and all). We have just completed an Adobe XD prototype showing the main flow (Read / Edit / Contribute) for the Full Detail Screen (Modal view, DeepLinking version will be added soon)

The prototype is available at https://xd.adobe.com/view/1fef18d7-16f1-4264-57f3-75cb6d1cf9ac-69de/

We have a few questions around the Deeplinking version, one of which being:

• Should we add a contribute button when the full details is visited directly (deeplinking) as the flow will not be started from the "Browse" Page?

@jeffmcaffer please review the prototype, @storrisi and @gianpaj will start actual implementation this week. As long as we are all happy with the protoype, we might use it as our goto document when we need to review the UX on that section.

[jeffmcaffer]

@AlexWebYourmind prototype looks good. There were a few things we talked about in the team call just now but overall, +1.

For deep linking

• The contribute button should be on the full details PAGE but not on the OVERLAY version.
• Separately you asked about the URL for the deep link. From a user point of view it seems to make sense to have clearlydefined.io/definitions/npm/npmjs/-/foo/1.0 as the link. I'm personally not worried about the lack of RESTfullness of the plain clearlydefined.io/definitions page. The UI is not a REST api. We might need to do something interesting in the routing or just have a switch in the render.

[AlexWebYourmind]

@jeffmcaffer thanks for the recap.

1. Contribute Button Confirmed that the Contribute Button will be available on the Full Details PAGE and not in the OVERLAY/MODAL version (Save/Undo available anyways, most likely these 2 buttons will be disabled if no EDITS are made?)

2. URL UI Routes 100% agree that the UI is not a REST API, and I think as well is beneficial to the user to have a URL like that.

My consideration was more general and in relation to existing Backend REST APIs that we will use to retrieve the data to display in the UI, but I double checked the service repository and we have everything we need. Ignore my previous misleading comment. Apologies.

[storrisi]

Hi @jeffmcaffer and @fossygirl, I would like to ask some questions about the SAVE button.

Currently, we have different SAVE buttons with different behaviours:

• the one in the Browse list, which builds a .json file and performs a download of it
• the one in the Full Details Modal View, which performs an update of the modified data to the Browse list
• the one in the Full Details Page View, which is currently without an operation

The questions are:

• is the behaviour we developed of the Save button inside the Modal correct?
• given the action of the Save button in the Browse List, could be a better label "Download" or "Export"?
• the Save button inside the Full Details Page View, should perform the same action of building a json file and download it? In this case this button should be renamed for consistency as well.

[jeffmcaffer]

Suggestions:

• The "save" on the Browse view that writes the json file should be called "Share" and should give people the user the option of sharing as a file (current behavior of save) or sharing as a URL (the behavior of the Share button I think). So Save and Share merge into one concept as they really are just different forms fo the same thing.
• the Modal should have OK and Cancel buttons. That avoids the concept of Save, where it would go, ... The user is looking at a component in Browse, clicks the magnifying glass (let me see more) when they are done they can OK or Cancel. OK should only light up if they did some changes.
• The full details page should have a Contribute if the scenario is such that the page is read/write

So short answer is, there should not be any Save buttons. :-)

[storrisi]

Makes sense. For what concerning the Share functionality on the Browse page, it could be something like this? https://ant.design/components/dropdown/#components-dropdown-demo-placement (the examples in the top left corner)

[jeffmcaffer]

Yup that's the idea.You might consider Bootstrap in this instance as the rest of that part of the UI is using it and this is not particularly complicated. See https://react-bootstrap.github.io/components/dropdowns/

[jeffmcaffer]

This seems done