entities layouts: ease external ids links customization #464
Conversation
maxlath
force-pushed
the
displayed-links-settings
branch
from
932505d
to
1d3d049
Compare
| type="checkbox" | ||
| checked={selectedBibliographicDatabasesCount === bibliographicDatabasesNames.length} | ||
| indeterminate={selectedBibliographicDatabasesCount !== 0 && selectedBibliographicDatabasesCount !== bibliographicDatabasesNames.length} | ||
| on:click={() => toggleAllSection({ names: bibliographicDatabasesNames, selectedCount: selectedBibliographicDatabasesCount })} |
There was a problem hiding this comment.
I recall a conversation where you where against this checkbox-that-modify-everything behavior. The reason behind was that it is not very accessible, as what is going to happen after clicking on the checkbox is left unknown to the user. Usecase: one crafts their ids customization, then discovers the general checkbox, and on their first click on it, they deletes their own customisation for good.
Select All button pattern seems to be the accepted solution since inventory browser implementation. And is now in other parts of the app (ie. items map, entity homonym selections).
So, i think it would make sense, on a less central display than inventory browser (where space is less compact/important), to reuse this pattern, wouldnt it?
There was a problem hiding this comment.
The problem with the inventory browser is that the selection can be much bigger than what is on the screen (ex: "select all" might select 1000 items, while only 20 are displayed), so I think my reasoning was that in absence of visual feedback, it was better to make explicit buttons. But in the present case, as we display all the options, I like the minimalism of that single global checkbox: you can still manually select all or none without using it, but it respects a known convention which users might discover, and have direct confirmation that it has the effect they expect.
There was a problem hiding this comment.
it respects a known convention
I couln't find this convention anywhere in the codebase though. On the contrary the "select all" pattern appears in more than the inventory browser (ie. map filters)
I would still be more comfortable with an already in use pattern (and more accessible (cf. my last comment)) to not have different display with same behavior.
If you want to continue with this unnamed checkbox, can the input element be extracted into its own component (to make it reusable for map filters) ?
There was a problem hiding this comment.
I couln't find this convention anywhere in the codebase though
I meant a known convention in general, but that has indeed not been used so far in the codebase
There was a problem hiding this comment.
This implementation with the button and a dynamic label seems to work nicely
There was a problem hiding this comment.
I dont know how to continue this, i think its a mistake to present two different ways to display the same behavior. And sure, its minimalistic, but also more difficult to understand whats going on. This app is already complicated enough to make the user guess what will happen if checking the box.
You seem definitive, so i will swallow it, can we at least extract it in its own component to reuse it elsewhere ?
app/modules/entities/components/layouts/category_external_ids.svelte
Outdated
Show resolved
Hide resolved
to make it less tedious to select many
maxlath
force-pushed
the
displayed-links-settings
branch
from
1d3d049
to
7d89edc
Compare
… available but none are part of the preferred
… "display more" as suggested by #464 (comment)
maxlath
force-pushed
the
displayed-links-settings
branch
from
7d89edc
to
9f2258c
Compare
As we now have plenty of links from external ids to display, having good interfaces to customize what should be displayed seems important. In particular, a user that doesn't explore the settings might not realize that they can display all those links.