Masthead Management 2

[bozana]

This is a part of the JII and this issue: #8957

Masthead roles management:

• As JM I would like to define masthead service roles, by default these will be there: Editor in Chief, Associate Editor, Section Editor, Book Review Editor, Special Issue Editor, Editorial Board Member, Reviewer. -- JM can define if a role will be consider for masthead, and JM can change the name of the role. (s. Add masthead option to user roles #9552)
• As JM I would like to define the order of masthead service roles, in which they will be publicly listed. The users will then be listed alphabetically. S. Allow ordering of masthead roles #9736.
• As JM I would like to edit a masthead service (e.g. to correct the role, start or end date)? This is not possible -- the role, start and end date are defined by the invitation and cannot be changed any more. The invitation is either accepted as is, or a new invitation needs to be made.
• As JM I would like to thank the user and end an active masthead service, defining the end date.
• As JM I would like to see all active masthead services (s. Public masthead page #9860)
• When a user is disabled all active masthead services will be ended for that user. Disabling a user functions differently -- currently no roles are ended, and the user can be reactivated again. Thu disabling a user will not end the masthead services.
• If a user is removed all masthead services will be ended for that user.
• If a user is merged with another user, and thus fully removed form the system, also all masthead services will be deleted for that user.
• When a reviewer submits a review, the reviewer should be assigned to that year for the masthead (s. Public masthead page #9860)

Masthead publication/display:

• The active masthead services will be publicly displayed by role, name, affiliation, ORCID, start date, with the order of roles, as it applies: Editor-in-Chief, Associate Editor, Section Editor, .Book Review Editor, Guest Editor, Editorial Board Member. -- The order of roles will be defined by JM, s above. (s. Public masthead page #9860)
• The last year reviewers will be listed on the active masthead page. (s. Public masthead page #9860)
• The ended masthead services will be publicly displayed. (s. Editorial History #9914)

Editorial history:

• As JM I would like to be able to enter the masthead old history, as text in a text input field. (s. Editorial History #9914)

TODOs:

• Consider start and end date for user roles (#9426)
• Add masthead option to user roles (#9552)
• Add masthead to user_user_groups (#9709)
• Upgrade script for existing default masthead roles and user assignments (s. Upgrade script for existing default masthead roles and user assignments #10041)
• Consider only external reviewers for the display on the Editorial Masthead page in OMP. (s. Consider only external reviewers for display on Editorial Masthead page #10080)
• Remove Editorial Team and introduce Editorial Masthead and Editorial History in all theme plugins (s. Remove editorialTeam.tpl from theme plugins #10200
• Style the Editorial Masthead and Editorial History page appropriately (s. Style Editorial Masthead and Editorial History page appropriatelly  #10392)

Fixes:

• Corectly consider roles removed from masthead with the custom order of the masthead roles in website settings #10375

[bozana]

From @Devika008 (s. #7406 (comment)):

I have integrated ORCID iD verification with inviting users to take a role in OJS and the flow and UX/UI for it can be found here: #3022

Further to this issue, I worked with @willinsky, @bozana, @asmecher and @jardakotesovec to further the integrity initiative and display the users association with the journal under a setting in "Users & Roles" section called the Masthead. A new tab will be added for the same in the section and the landing page will look like:

On clicking "View" under any users name will lead to the following page:

Notes:

1. When we kickoff the JII initiative, it will be a plugin. Those with the JII plugin, will have "appearing the masthead" as a compulsory option when adding users to the roles since they are endorsing the PFL as well. So the option to toggle between "appearing" and "not appearing" from the user invitation process will be switched off. However, there could be exceptions wherein the from the settings we can turn off the compulsory appearance of certain roles like assistant editors on the masthead. But the editors and board membership are required [to be on] the Masthead for JII.
2. Those who are not yet endorsing PFL or JII, we will still show them an option for "appearing in the masthead" but it can be fidgeted with wrt to toggling between appearing or not appearing in the user invitation process. We still would request and encourage editors and board membership are required [to be on] the Masthead.
3. Reviewers will be listed on the Masthead only when the review is submitted by them.
   Masthead records will only be for users who can provide consent to their names being displayed. No historical data wrt users being deceased or unable to give consent can be added to the masthead by the Journal Manager. However, if the user has been a part of the Journal for years prior to JII being initiated and has the means to provide consent, then that user could be displayed on the Masthead.

@bozana please do add anything you feel I've missed in this.

[bozana]

Thanks a lot @Devika008! That all looks great, and I can then start working on this masthead part... :-)
I will surely have further questions once I start... :-)

[jardakotesovec]

@israelcefrin Hi Israel, if you have moment, I would appreciate if you have suggestion how to structure the table above. I am not sure how to encode the grouping by Role/Issue.

[israelcefrin]

Hi @jardakotesovec , there are more than one possible solution to code this table structure. If we are willing to keep as a single table, then it is called a "complex table". Hence, we will have just one table which contains the whole data.
A possible solution for this , aiming accessibility, would be the usage of table ids and headers.
I've drafted a simple example using the first two roles:
https://codepen.io/Israel-Cefrin/pen/rNRWWVr

You will notice that table headers (<th>) are marked up with and id attribute and I am concatenating these id into table data cells , e.g. headers="name mh-eic". The ids are made by a convention, we can set anything we'd like. On this case, mh-eic=> MastHead Editor-In-Chief.

However, the approach of complex tables, with multi-level headers is not recommended because even using the correct markup, may cause some confusion to users who rely on screen readers. Hence, I would recommend a second approach, splitting this single tables in small tables. I will paste an example on the post bellow.

[israelcefrin]

Hi @jardakotesovec , here is the example using small tables. You will notice that there is a first table only with headers. Its purpose is to show the headers to regular sight people the labels. This table has the aria-hidden="true" then it is not going to be announced to users by screen readers.
All other data table are coded with the thead with a class that hides them visually but keeps them annouceable by assitive technology, i.e. class="visually-hidden".

See the code:

<table id="masthead" aria-hidden="true">
    <thead>
        <th></th>
        <th>name</th>
        <th>username</th>
        <th>email</th>
        <th>date</th>
        <th>affiliation</th>
    </thead>
</table>


<table id="editor-in-chief">
    <caption>Editor-in-Chief</caption>
    <thead class="visually-hidden">
        <th scope="col">more info</th>
        <th scope="col">name</th>
        <th scope="col">username</th>
        <th scope="col">email</th>
        <th scope="col">date</th>
        <th scope="col">affiliation</th>
    </thead>

    <tbody>
        <tr>
            <td><button>more info / icon</button></td>
            <td>Kathy Singley</td>
            <td>ksingley</td>
            <td>[email protected]</td>
            <td>2021/09/31 - present</td>
            <td>University of Cambridge</td>
        </tr>
    </tbody>
    <tfoot>
        <tr>
            <td colspan="5"><a href="http://">View Masthed Information</a></td>
        </tr>
    </tfoot>
</table>



<table id="associate-editor">
    <caption>Associate Editor</caption>
    <thead class="visually-hidden">
        <th scope="col">more info</th>
        <th scope="col">name</th>
        <th scope="col">username</th>
        <th scope="col">email</th>
        <th scope="col">date</th>
        <th scope="col">affiliation</th>
    </thead>

    <tbody>
        <tr>
            <td><button>more info / icon</button></td>
            <td>Kathy Singley</td>
            <td>ksingley</td>
            <td>[email protected]</td>
            <td>2021/09/31 - present</td>
            <td>University of Cambridge</td>
        </tr>
    </tbody>
</table>

It will stil require some CSS polish, but it might be a better approach. However, notice that the first table is not connected to the other, if any cell on the tables stretches the width, it might be difficulty to keep the visual matching. Maybe, it worthy to discuss with @Devika008 if she cames up with a third approach on how to deal with these table headers.

[israelcefrin]

And just a final note: I haven't had the chance to test this code with all screen readers. I would recommend that we draft a table and run a round testing using all main screenreaders vs browsers:

• JAWS, NVDA, Narrator (windows)
• VoiceOver (MacOS)
• Chrome, Firefox, EDGE, and Safari

This is the current support for headers attribute on tables by screenreader vs browser (OS). Please notice, it is fully supported only on Chrome and Edge using JAWS on windows or Firefox using NVDA.

Source: https://a11ysupport.io/tech/html/headers_attribute

[Devika008]

Hello everyone,

Soon @bozana and @jardakotesovec will be kicking off development work on this. After a few meetings with @jardakotesovec , reading the comments on the top from @israelcefrin and some brainstorming later, I have redesigned the masthead page to make it more accessible and help process information easily.

1. The Masthead Landing Page
   a. Instead of one long table with subheadings in addition to the main headings, I divided the tables into smaller tables, each one pertaining to a user role. When this happened I realised that for someone using assistive technology, discoverability of information could become difficult when it comes to seeing peer reviewers listed in the masthead or users not listed in the masthead. In my figma testing, the screen reader was reading everything and then moving to peer reviewer making it quite frustrating. Hence I divided the tab into sub tabs to ease discoverability.
   b. I've also let the arrow functionality (may it rest in peace) in the start of the row go and replaced it with three dots which are known world wide as more options in order to improve the accessibility of the table and familiarise OJS with other web applications

2. There's also a possibility that the amount of users could be really high and hence I also introduced filtering options as you can see below to sort information better for the user.

3. The view in detail screen has no change

Let me know what you all think of this

[Devika008]

Hello Everyone,

John, @asmecher, @bozana, @jardakotesovec and I got into a discussion and analysed the pros and cons of having a separate masthead management page in the Settings > Users & Roles Section.

Main Points of Consideration

1. All data points and important actions to manage users, their roles and their appearance on masthead is happening through the Users Section in Settings > Users & Roles (see here)
2. There is no new functionality or added advantage a separate masthead management page can offer
3. There is a main Masthead Page on the Journal Website which the point of truth for everyone

Keeping these considerations in mind, we decided not to have a separate masthead management page in the Settings > Users & Roles Section. There will be a public journal masthead page for listing everything and as mentioned above will be the point of truth. There will be the current/active masthead page, and the masthead history page (where all users we have the data for are listed, the users which roles ended and we have that data in the DB) -- both created automatically by the system. There will be an input text filed where JM can enter the longer/older history of the journal's masthead (that we do not have the data for) and that will also be presented publicly

Other Point
What about user account evolution (changes), user deletions, etc?

• When a user is "deleted" through the Merge Users tool, any editorial board records are deleted.
• User information will not be stamped on the board listing, so if user names, affiliations, etc. change, the board listing will also change.

Next Steps

• @Devika008 to design the publicly available masthead
• Open Discussion Point: Inclusion and categorisation of users based on special issues
• @bozana to continue work on backend for masthead.

@asmecher @bozana @jardakotesovec please add anything you think I might have missed