Display additional data for "Creator" and "Publisher" on the framework view screen

[siuc-nate]

This should include user-friendly data such as name, description, subjectWebpage, etc. This should ideally come from the registry on-demand.

[stuartasutton]

Whoa, what are we talking about here? Are we talking about the left-hand display in the CASS viewer or the TOC of frameworks? The TOC needs no more than the description and publisher name. I think that that is also sufficient for the left-hand panel in the CASS viewer.

[siuc-nate]

I'm referring to this:

A user isn't going to know what to do with the JSON at the other end of those URLs.

[Lomilar]

Accepted (I thought we had an issue already for this.)

Creator and Publisher should be a blue link with the creator/publisher name (if retrievable) that link to the data.

[stuartasutton]

I need to push back a bit. If you resolve all of these URIs so there is nothing left but pretty text, how does someone who needs the URI for linking get to the URIs? (I'll reserve the groan until you tell me I need to download the json-ld to get them.) This is an editor and the values of the properties are URIs.

Maybe we should have a little toggle by each object field (URI) that allows us to toggle the literal off and the URI on.

[Lomilar]

They right click and "copy link"?

like this?

[siuc-nate]

If you resolve all of these URIs so there is nothing left but pretty text, how does someone who needs the URI for linking get to the URIs?

Hence "additional" - the URIs should still be visible, but there should be something for the average Joe to look at, too.

[Lomilar]

We could also explore icons and whatnot.

I'm used to hovering links to see what the URL is. Is that not desired? Something like...

Creator Name 🔗 <-- with the URL in there.

We all may be the wrong people to make this decision, except Nate.

[siuc-nate]

Maybe something simple, e.g.

Publishing Organization Name
https://credentialengineregistry.org/resources/ce-[GUID]

Where the URL is a smaller font to downplay it and help keep it from wrapping on most screens (not a huge deal)

Although that might be misleading if people think the URL is supposed to be the publisher's website...

Thoughts?

[stuartasutton]

That would work, Nate. The problem is that the competency data has two audiences that must be served: (1) the total layperson just browsing and looking at the data--for whom URIs are inexplicable or misleading; and (2) the people creating data that need to have some modicum of ready access to URI's and not literals. We have to meet the needs of both without sacrificing or shortchanging either.

[siuc-nate]

As long as we need to show the URI, our options are a bit limited. If the subjectWebpage for the publishing organization can be retrieved, perhaps it can be displayed too (or maybe make the publisher name a link)?

Publishing Organization Name
http://publishingorganizationwebsite.org
https://credentialengineregistry.org/resources/ce-[GUID]

Perhaps prefix each URL with some icons as Fritz suggested. I'm not sure what would be best.

[stuartasutton]

Also (or maybe even best) is Fritz' suggestion of text with appended 🔗. Of course, some layperson will click it as well and be "confused"...but we have to find some middle ground. My take is that such a person will only click it once :-)

[siuc-nate]

Perhaps a small version of the JSON logo/icon?

[stuartasutton]

Nope, that would be confusing...prefer Fritz' link icon.

[Lomilar]

I have been chastised by designers about using emoji as icons, so I'd recommend for final implementation equivalents from FontAwesome or the like.

[stuartasutton]

As I think more about this, the functionality for the user is to copy a URI for pasting it into his or her own linked metadata, not to resolve the underlying link of a literal (can't assume that the user knows how to read json-ld). This is complex because we have taken the actual property value of, say, the creator, resolved that URI to get the associated literal and displayed it, and now want to provide the means for an end user wanting to link to that resource to grab the underlying URI that we resolved. No icon I am aware of works: (1) a link icon doesn't work because I don't want to resolve the URI, I want to copy it; and (2) a copy icon doesn't work because it logically means "copy the literal" to the user, which is not the affect.

So, I guess it means that we have to settle for the literal being an active link knowing that if clicked, it will confuse the naive user but resolve to something where the URI can be found by the user who understands json-ld that wants to link some other entity to the underlying entity. The savvy user will catch on quickly that they can do a fast link copy with keyboard sort cuts.

[stuartasutton]

The only solution that would be clear and serve both types of user would be to provide functionality that allows the user to toggle between two views: (1) a view of nothing but literals (all URIs resolved), and (2) a second view that displays URIs of all object properties as URIs (not literals).

[Lomilar]

I'm still not sure why a simple link wouldn't suffice.

Is copying the address from a link not standard practice? I probably do it a couple times a day.

[stuartasutton]

Yes, and you understand that you don't actually "click" that link icon, you "right click" to copy it--i.e., copy, not resolve. As I noted earlier, it's probably the best icon we have available. There's no "right click to copy" that I am aware of...

[Lomilar]

We could do a click based copy to clipboard (instead of navigate) with a little message... though that wouldn't be the expected behavior from clicking on a link. We'd need some sort of clipboard icon instead.

Creator.Name 📋 <-- copies the URL to the clipboard.

[stuartasutton]

Thanks, Fritz...this is right thinking...

[eddavies]

The copy icon works. Closing this. Feel free to reopen if there are additional concerns involving this.