Support versioning in the reader interface #4870
Comments
|
@NateWr, what about reserving |
|
I was thinking just to leave it like So am I right in thinking that we shoudn't seek indexing for older versions? Just set them all to point to the canonical URL for the article, which will show the latest published version? |
Yes, that makes the most sense to me (and seems unlikeliest to open a Pandora's Box). |
|
Some mockups for the reader interface from @israelcefrin. An article that has previous versions:
Viewing an old version of an article:
Viewing revision message for an article:
|
|
A couple of thoughts on these. First, I like the presentation of "Previous versions" in the sidebar. However, the "Published" date should still show the original date of publication. I'm thinking something like this:
Second, the banner notification at the top is really important. I like how it's done, however, I'm not sure what the date "March 3rd 2005" is meant to link to? Also, I think that revision information should appear below the abstract, rather than in a popup/modal. Modals are common sources of UX problems so I like to minimize their use. In this case, I think that we can display the revision information below the abstract and above the references. What do you think @israelcefrin? Lastly, I don't think we'll have a detailed record of revision changes as shown in the mockups here. We don't know exactly what's changed, we might only have a single line of text. What do we think about that? Should the revision information be a full rich text area where people can write a detailed summary of changes? Or just a single line? |
|
Hi All, My comments bellow:
@NateWr the idea is to keep the original published date and creating the link on "Updated" date? Or all this label is a link to the current version? This linking?
I would prefer the second.
I think we can remove the link and create a visual relation with menu item (color/bold) maybe. It won't be required to create a self-link there actually. Regarding the modal, it makes sense your point. It is usually a stress point and has accessibility issues to make it work properly. In fact I am not totally sure about showing a log of revision to the reader user.
Please, check what has been update for this latest version:
What do you think? Wouldn't it be easier to ask to select than write a description? For data metrics we could also have info regarding what is the most update field also ( thinking in the future features). |
I'd prefer no link at all. The "Published" date can be set manually, and may not reflect the date the article was published on the site, for example when journals import back issues. And this date stays the same from version to version, unless they manually change it. The "updated" text will only appear on versions after the first one, and will always show the date of the version that is being viewed. So I don't think there is any reason to link it, since it will already be the version in view. For navigating between versions, I think the list directly below is good and the clearest way to identify the versions.
I'm not sure what you mean by this. Can you give an example? Are we still talking about the date of the version being viewed?
I don't want to specify each possible type of data, because we will always face requests to add more possible types of data to check off. And in terms of metrics, I don't trust this kind of data when people are entering it. If we want to pursue a full diff in the future, we can do that automatically. It will be more accurate and easier for the user because they won't have to touch anything. The revision details I had in mind were more of a human-readable message that describes intent. Like "This version was updated following comments at X workshop. The Y section was revised to account for Z feedback." I'm not sure if either part is necessary for our first iteration of versioning. But the second is easy to implement and would work for lots of different scenarios. |
I thought to remove the link from the top banner warning.
I gotcha! Agree, this use case makes much more sense and it releases editor's from a multiple-choice decision which is a heavier mental work. I think that one field would be sufficed. Do you think it could be a rich text area? Like the example below: |
Yeah that's what I was thinking. And then it could be added below the abstract, like this:
|
@NateWr how would be the URL public identifier ? Would it be added a suffix |
|
The public URL identifier goes where |
|
Comments from Google Scholar:
Re: URL format for different versions
Re: How to deal with metatags, especially citation_pdf_url, for each version.
Re: linking to other versions of the article in the UI
|
|
Great, this seems to align 💯 with our previous discussion. The one thing we need to ensure that I think isn't mentioned is that the Google Scholar metatags should not appear at the versioned URLs and we should use a |
|
@jmacgreg ok, we have a slight hiccup with this:
And maybe this:
A URL to the galley of the latest publication follows the format However, the galley ID changes between versions. So when a new version is published, the article part of the URL will stay the same, but the galley part will change to something like this: Worse, we have no distinct link between two galleys of different versions. So galley If I understand the guidance quoted above, Google Scholar wants a URL like In the latter scenario, the
If this is ok, then I think this is a solved problem and we don't need to worry. In your understanding, would this be ok with Google Scholar? I suspect it will not, and that in fact they want an identifier for each galley that is retained from version to version. I can think of a couple ways to do this:
My sense is that this feels like something we should do automatically for the user to enforce consistence usage and ensure journals are getting indexed properly in Google Scholar. But to do so we would have to remove editors' ability to set custom publisher identifiers and have those identifiers reflected in the URL. We could do some work to ensure existing URLs do not go dead, but the visible URL in the browser would still change and editors would not have control over it. I eagerly await your input. 😂 |
|
The following PRs address most of what's been discussed, with the exception of the outstanding issue with galley links discussed at #4870 (comment). These PRs update the PRs: |
#4870 Support display of versions in reader UI
pkp/pkp-lib#4870 Support versioning on article landing page
pkp/pkp-lib#4870 Support versioning on book landing page
- Add support for versions - Migrate code to use publications - Use own copy of spectrum colorpicker after it was removed from OJS. - Migrate to theme option
|
Some additional work required to prepare our themes for 3.2. |
pkp/pkp-lib#4870 Adapt for 3.2
pkp/pkp-lib#4870 Update theme for 3.2
pkp/pkp-lib#4870 Adapt for versioning and publications
pkp/pkp-lib#4870 Add notice when viewing outdated PDF version
#4870 Allow themes to access property directly
pkp/pkp-lib#4870 Adapt themes to versioning
pkp/pkp-lib#4870 Adapt theme for versioning in 3.2
/article/view/:submissionId./article/view/:submissionId/:galleyId./article/view/1/version/1/article/1/5will still work even after it is no longer the current version. This should be updated to redirect to the version URL (/article/1/version/1/5) when it is no longer the current version. This will depend on an answer for Support versioning in the reader interface #4870 (comment).Acceptance Criteria
All criteria should be performed as a logged out reader accessing the reader interface.
<head>of the article landing page, thepdf_urltag always goes to the PDF of the latest version, even when a submission has more than one version.The text was updated successfully, but these errors were encountered: