search

pkp / pkp-lib

The library used by PKP's applications OJS, OMP and OPS, open source software for scholarly publishing.
https://pkp.sfu.ca
GNU General Public License v3.0
307 stars 447 forks source link

[OPS/OJS] Enhancements to list of categories #6836

Closed alexxxmendonca closed 5 days ago

alexxxmendonca commented 3 years ago

Describe the problem you would like to solve The list of category works fine when you have a short list of categories and not a lot of parent/childs. However, when you have a very long list of categories and sub-categories, it can be quite troublesome for authors to search through the list and select the categories. In addition, there is not an embedded scrolling so the page gets as long as the list is:

image (the list just keeps growing the more items are added)

Describe the solution you'd like Better handling of long lists (scrolling?) Ability to search through itens instead of having to read them all (As-You-Type suggestions?) Better handling of parent/child relationship (indentation?)

Suggestion: image

Who is asking for this feature? Basically we want to replace the use of "Sections" to "Categories" in OPS, because we can't have hierarchy in Sections, but with Categories we can. However we have a very comprehensive list of categories and the way this functionality is set up it's not very helpful for authors to classify their own submissions.

NateWr commented 3 years ago

@alexxxmendonca this is something we are likely to improve with the submission wizard work planned for 3.4. cc @israelcefrin and @ewhanson.

alexxxmendonca commented 3 years ago

Excellent! Would be happy to assist with feedback and testing.

diegoabadan commented 3 years ago

As @alexxxmendonca requested us, we look for a simple way to solve the problem of many categories.

We implemented this solution for when there are more than 10:

Peek_2021-06-16_14-35

Does PKP accept a PR with these modifications?

We hope it can be a good solution, at least until there is something better in 3.4.

asmecher commented 3 years ago

That looks really good, @diegoabadan -- we'd be happy to look over a PR!

NateWr commented 3 years ago

Sorry to put the brakes on here, but I suspect that's going to have accessibility problems that will prevent us from adopting it. I'm happy to take a closer look though if you have an example o can inspect.

diegoabadan commented 3 years ago

@NateWr, I was concerned about this after posting the previous comment.

I'll put an online OJS with this modification for you to evaluate. We hope to get a solution that meets the accessibility requirements.

asmecher commented 3 years ago

Thanks for the PR, @diegoabadan! @NateWr, could you have a look at https://github.com/pkp/pkp-lib/pull/7157?

diegoabadan commented 3 years ago

@NateWr, can you test the behavior on http://149.28.39.191:81/index.php/test/submission/wizard?

This behavior change only occurs when we have more than 10 categories.

NateWr commented 3 years ago

@diegoabadan, I'm sorry it's taken me so long to look at this. They keyboard controls for this are pretty good! However, there are some problems that would make it difficult to use with a screen reader. The <label> element is not related to the fields, so a screen reader can not associate the label "Categories" with the options. This is complex, because you'll need a <label>/<input> relation for the search, but also a <fieldset>/<label>/<input> relationship for the checkboxes. You may need to explore the aria-controls attribute to relate the search and the options, as well as a aria-live attribute to alert the user when options have changed. This is, frankly, difficult to get right.

The other UX issue I noticed is that when searching, existing selected options disappear. This will cause confusion, because it's possible for me to have options selected but not see them. I could submit with options I didn't intend.

Is this an urgent need for scielo? If so, you may want to make the changes I described and customize this on your install. However, if you can wait until 3.4, we are redoing the submission wizard. Once that's in place, it will be easier to make use of our existing autosuggest component. This will get an accessibility audit alongside our new submission wizard, so we can be confident that any accessibility issues will be addressed down the line.

I'm hesitant to merge in a new UI control for 3.3.0-x, only to remove it for 3.4.

diegoabadan commented 3 years ago

Thanks Nate.

Let's see if it's relatively quick to adjust for better accessibility. Dealing correctly with accessibility also seems to us to be a relevant learning experience, even if it cannot be used for OJS/OPS/OMP 3.4.

With the improvement effort made so far, just using it for 3.3 might be worth enough.

Thank you for making us more aware of these important requirements.

diegoabadan commented 2 years ago

A late record: we had a lot of difficulty bringing accessibility to the proposed solution. Due to the imminent release of OJS/OPS 3.4 we chose to wait for it.

NateWr commented 2 years ago

Thanks for the update. I'll leave this issue open and we can revisit it after #7191 is in place.

asmecher commented 1 year ago

Hoping this is still somewhere on your list, @diegoabadan, but I'm deferring it from the initial release of 3.4.0!

jardakotesovec commented 5 days ago

Was just reviewing this issue and already seems addressed in 3.4. There is logic that when there is more 10 categories, it switches to autocomplete component in submission wizard, where its possible to search and quickly add from long list of categories.

So I am closing this, but please re-open if you think there is still something to address!

Thanks!

Image