New author system UI changes #6824
Conversation
|
Why is the build failing? "No such file or directory" error for people.yaml |
|
Because it was created before the transitioned data was merged into |
|
Weird, but why did restarting the jobs not help... let's see if merging the base in helps |
|
I also assume this PR should be a draft at this stage, and not ready for review? |
|
Build successful. Some useful links:
This preview will be removed when the branch is merged. |
|
Okay, I created a TODO list at the top in the description. Please feel free to edit it or argue with the priorities. My thinking is that our goal should be the minimal set of changes needed to put the new author system into production. Many pieces can be done after the transition even if they are important. |
Not sure what you mean by "entries"—can you be more specific? I was thinking that, as a first step, it would be OK just to signal (un)verified status at the top of people pages. We should have a process in place for verifying authorships (i.e. person-paper pairs) before displaying authors of a paper differently. |
The ingestion scripts do not need to match ORCIDs, the library implements all of that already. Modifying these scripts to use it is a blocker for future ingestions, though, after we merge this. |
|
@nschneid Sorry, I copied blindly from the wiki: these were options for how to implement the distinction between verified and unverified papers. I've updated the text. @mbollmann Yes, it will be a blocker for future ingestions, but that's a good pressure to have. |
In the case where we name-match papers to an author page, the ORCID at the top would lend credibility to a paper assignment that was just done based on the name matching (and might be wrong). I thought that was a reason for considering this more important. |
I would like to talk this through. My basic worry is that adding visual distinctions to paper assignments is going to create an unsatisfying aesthetics, and that this will trigger fastidious people to manually verify those assignments—in order to fix the aesthetics and the sense of "incompleteness"—creating lots of work for us. For example, almost no paper before ~2020 will be verified, since there were no ORCID iDs at ingestion. Do we really want this to stick out, even subtly? From the user perspective, what does it matter what the paper's status is? It only matters that the assignments are correct, and next, that there is a mechanism to correct mistakes. This line of reasoning to me suggests we should do away with visual distinctions on papers altogether. |
|
It certainly is a goal for the final design—in any listing of a paper's authors, the authors who are verified for that paper are displayed differently from the ones who are unverified. But as soon as we make this distinction salient to users, we will get lots of requests to update the info. And most pre-2023 authorships will be unverified, except for papers of manually disambiguated authors, right? Maybe there is a subtler temporary solution (e.g. a popup saying verified vs. unverified on hover)? I don't think it would hurt to modify individual paper pages so the ORCID icon occurs next to any author with an explicit ORCID. I think users will understand that it means the ORCID was provided at submission time. |
This is a good distinction. On listing pages (author, volume), we would make no distinction. But on the paper page itself, we could add a field noting its status: one of {matched by ORCID, matched by name, explicitly verified}. |
|
And it would be good to develop a longer-term roadmap. E.g. maybe we prioritize getting as many authors as possible to submit ORCIDs in the next couple of major venues, so most active authors will have an ORCID in the database, then start nudging authors to verify their older authorships (with an appropriate UI for doing that). |
In my mental model, a paper assignment is verified if an explicit author ID is assigned in the XML, which doesn't mean it has to have an ORCID. |
That mechanism is not entirely unrelated to the paper's status, I think. A verified assignment should normally not need to be corrected, for example, since "verified" implies either "assigned via ORCID" or "manually checked at some point in the past". But I would have to think through the updated correction process in more detail to have a good idea here of the implications. |
|
^ What about #6518? |
I guess in the task list above, it is implicitly covered that the issue template for author page requests should be adapted too (cf. "Update issue templates once new author representation/URL is in place" #6414). We might want to change terminology and think about what kind of requests we'd like to distinguish and how the workflow should look like. |
|
Two comments I have while navigating through the preview: (1) Why do some author page URLs in the preview end in (2) Imagine author A has one or more namesakes (all verified), so that disable matching is true: is there any hint on verified author pages to the unverified page (if it contains papers?). My thinking is, that a verified author A (or someone interested in what papers author A has published) will wonder why their paper X is not on the verified page? Do we want such a link similar to the "other authors with the same name: list-here"? Sorry if this has been discussed somewhere else already, I'm starting to get lost in the different issues with discussion threads and closed PRs on author representation changes... |
Huh, that looks like a bug, I will investigate
This should happen automatically via the "similar names" functionality (same as we can specify via the "similar:" key in the YAML; and identical names should automatically be considered "similar"), but if this doesn't consistently happen on the preview that may be a bug also. |
|
To me, it looks like all unverified pages actually have the pattern For the case of linking verified and unverified pages, here are some more examples:
All of them have in common that unverified page (e.g. How do we want to link verified pages and unverified page? EDIT: revisiting the mockup slide set I like the phrasing there (slide 17ff) "This author may have additional unlinked papers."). For the unverified page it is suggestion to link to a disambiguation page instead of listing all verified Yang Lius? And the disambiguation page will have as last point "Other papers by 'Yang Liu' (that have not been linked to a specific individual)" |
Ah, then this probably comes from my changes to switch this around to |
Just as you posted this, maybe I've found the PR (closed without merging: #5471 ) you're referring to. |
|
In #5991 it was discussed to maybe have a three-way distinction when it comes to adding a symbol to the canonical name: verified with ORCID, verified but without ORCID ( Here are some examples for verified but without ORCID and unverified so you can decide whether the preview for them should be different somehow or not:
(As you probably noticed, I picked examples from the list of ACL Lifetime Achievement Award recipients) I've also just revisited the Mockup Slide set, slide 33 also mentions the quasi-verified (id, but no ORCID) case as separate from unverified. |
The following are the tasks that should be done on this branch (see Hugo template changes):
The following are important tasks, but need not block merging:
Administrative tasks: