search

creativecommons / vocabulary

A cohesive system of design for Creative Commons
https://vocabulary-docs.netlify.app
Creative Commons Zero v1.0 Universal
2 stars 0 forks source link

[Functionality] media attribution consistency and improvements. #30

Open possumbilities opened 1 month ago

possumbilities commented 1 month ago

Description

Currently the ability to attribute images is varied, but does exist and was a top priority within the design given Creative Commons position in the space.

However, there is a lack of consistency in some areas, and also a lot of visible real-estate taken up in some of the use cases (like the Images Attribution list).

The approach, overall, needs to be streamlined and improved. Questions such as: is this one component, that operates differently within various contexts, or a series of related components?

Implementation

TimidRobot commented 1 month ago

I'm not sure if this will impact implementeation, but it would be nice to be able to easily audit attributions.

For example, our current documentation[^1] recommends TASL[^2] but needs to be updated to TASIL[^3][^4]. There's a good chance that we may want to update a lot of our attributions to use TASIL.

(Uh oh! TIL: GitHub Flavored Markdown supports footnotes[^5])

[^1]: Recommended practices for attribution - CC Public Wiki [^2]: TASL: title, author, source, license [^3]: TASIL: title, author, source, institution, license [^4]: Nudging Users to Reference Institutions When Using Public Domain Materials, Creative Commons Guidelines [PDF] linked from Open Culture Resources - Creative Commons [^5]: Footnotes now supported in Markdown fields - The GitHub Blog

possumbilities commented 1 month ago

It's a good point, for the WordPress specific vocabulary-theme implementation in almost every case I can think of, the attribution is stored as its own field/meta-field which would make that at least foundationally possible to script out some kind of audit.

Baking it into Vocabulary might aide with other areas of implementation, but it would merit further exploration to script it in some way and it might not be a great fit here, but exploring it might show differently.

Where it might work well in Vocabulary is outlining the UX/UI for catching and nudging this behavior.

For example: I could also see this being something we split out as various routes to do this, like a UX flow that's baked into form elements where it nudges this use and then it could be represented by Vocabulary as static field validation, but would then be up to whatever implementation framework/language/etc. is used to make it programmatically dynamic.

We could also reference this in Vocabulary documentation too, pointing back to the standard the way we might WCAG or HTML specs.

Also: Footnotes, uh oh...