Column data links to trigger filters in back-end tables

[Bloke]

In various panels, there's an opportunity to make more items in each row clickable. e.g. on the Articles panel:

• Click a category name to filter by that category (1 and/or 2?)
• Click the section to filter by section name
• Click the author name to filter by author

Considerations:

• On other panels (e.g. Sections or Languages panel), clicking the numeric value takes you to a different panel and filters the corresponding assets. Here, we're considering filtering content on the same panel, which is inconsistent. People might think that clicking the section will take them to the sections panel to edit the section metadata? So we need to be clear in signposting. A convention is fine. e.g. if the content is in parentheses it will take you to another panel, if not it'll keep you on the same panel. This might be unattainable as it would mean putting parentheses around every value in the Article column on the Sections panel table. And what would we do about the currently linked Status column on the Articles panel, which takes you to the front-end to view the article?
• When filtering by article category, which do we filter by? Only the corresponding category (1 or 2) depending on what's been clicked? Or filter by both all the time? Or somehow permit both. Also project forward to when we repurpose Keywords as Tags. What will we display on the panel here, and what would clicking a tag (if we permit that or even show the column) do?
• Some column items already trigger the Edit step (e.g. clicking the article ID or title of any main asset type). This proposal would trigger a different outcome when clicking a 'filter' column, which might be unexpected. The difference is semi-obvious: if the content is in some way unique (as the id/title/filename/image name/etc are) then it triggers the edit step, otherwise it's a filter. But if there could be some visual cue that the actions are going to different (colour, shading, icon, different underline, whatever) then that might be handy.

Lots to think about, but if we're careful and consistent, this can be an asset to back-end navigation and/or content management.

[Bloke]

Looking at the Categories panel, the links from there to the articles panel use "categories" as the search criteria. There's no option to search one or the other, so that makes that an easy win. I've updated the OP to reflect this.

We could actually do this in 4.8.8 if we can come up with a sort of convention so people know that clicking the link will filter the content on the Articles panel, rather than opening the Categories panel (or whichever panel the link refers).

[philwareham]

We could actually do this in 4.8.8 if we can come up with a sort of convention

Well, we have have the following text string in 4.8.8 now...

category_count="Items in this category: {num}."

...so that can be the tooltip and aria-label for the link. Going back to our conversations around telegraphing everything, I don't feel we need more than that to explain it. Once a user has clicked it once it's fairly obvious what this pattern does.

EDIT: I'd have to move that string to 'admin-side' or (probably preferable) to 'common' but since I haven't synced it to Crowdin yet that's trivial.

[Bloke]

I'm all for it then. If you could kindly move that string to either admin-side or common depending on whether this is applicable on the front-end too, I'll have a play with the Articles panel later and we can see if we like it.

EDIT: Then again, see below.

[Bloke]

Actually, hang on. We don't know in each row how many of these are actually available so this string isn't much use here. The {num} will never be reconciled. So maybe we need a generic admin-side string "Filter by this item" (or "Search by this item", or something, since it actually triggers a search) instead?

[philwareham]

Is it a problem to introduce a counter? Would be handy for UX I think.

[Bloke]

Are you intending to display the articles like this then?

Or maybe have the category name link to the category Edit step and the (num) link to the current Articles panel to filter them?

Or is this num just for tooltip purposes?

[Bloke]

Also, since our multi-edit actions are performed by Ajax, we'd have to make sure we recalculate the counters in case you delete articles or mass reassign categories.

It may be wired up to do that already and just returns the entire (paginated) HTML block that we replace. Not sure; would have to test it.

A counter that joins the articles table to the category table (and sections table, and user table, and tags table in future) might make the query pretty heavy.

[philwareham]

Or maybe have the category name link to the category Edit step and the (num) link to the current Articles panel to filter them?

This would be the most consistent behaviour.

Or is this num just for tooltip purposes?

Initially it was, but when thinking about it further it would be useful to keep it permanently visible.

A counter that joins the articles table to the category table (and sections table, and user table, and tags table in future) might make the query pretty heavy.

If this proves problematic, we could just settle for the category link being the search filter, with a simple tooltip. However, the ideal UX would be the edit/filter combination IMO, as you suggested.

[Bloke]

Okay, let's leave string wrangling alone for now. I'll tinker with the panel to see what's possible. If the query turns into a tyrannosaurus rex wading through treacle when we start getting to a few thousand articles, we'll abandon it and just try the filter approach with a generic tooltip term, and no counter.