Original report by [mikey_p]

I tried to write some tests for this after seeing #308458: TestingParty08: Tests for admin/content/node and ran into issues. I talked to chx about this and he suggested completely reworking the filters so that they no longer use session to store their values, but to change all the filters into $_GET params for easier testing.

The undo feature won't work after this conversion, and the whole interface for this is clunky so I talked to the usability team about adding a 'remove filter' type of link/button next to each currently applied filter and yoroy suggested something like the iTunes smart playlist filters (screenshot).

FYI: $_GET params are passed through drupal_get_destination, tablesort and pager links, so neither the pager, the edit links on a node, or the table sort header links will destroy the filtered set.

EDIT by mikey_p: I changed the issue author to Abandoned modules since I don't seem to be able to un-follow this issue (I keep getting re-subscribed with each followup) and I really don't want anymore update on this issue. Please feel free to change it to someone else that is more appropriate

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mikey_p’s picture

Oh and this will come with tests.

bcn’s picture

Issue tags: +Usability

Here's a link to the discussion concerning this. http://groups.drupal.org/node/18008

webchick’s picture

This issue is less about usability and more that it needs UX team review, so marking as such.

sun’s picture

subscribing

@mikey_p: Is this issue intentionally assigned to you? I.e. are you working on it?

mikey_p’s picture

Assigned: mikey_p » Unassigned

@sun: I'm not working on it at the moment as I guess I need to come up with some mockups for the usability team. This could be a pretty big patch and given it's mostly UX, I'd really like to get *some* feedback on the concept before writing a patch.

mikey_p’s picture

mikey_p’s picture

This is probably dependent on #299267: Add "Extender" support to SELECT query builder Assigned to: Crell getting in first so that we can build a dynamic query that can be paged and table sorted.

sun’s picture

Title: Fix filters at admin/content/node » Improve query filter UI on admin/content and admin/people
Version: 7.x-dev » 8.x-dev
naught101’s picture

The best design for this is surely something akin to the project issue queue's advanced search? http://drupal.org/project/issues/search/drupal, particularly as it means you can make multiple changes in one page load, instead of the current horrible system of making single changes per page load.

Something like that could be done with views with exposed filters, couldn't it?

Fields as in the columns:
Name (contains): textfield
Type: multi-select
Author (contains): textfield
Status: multi-select (I think - otherwise spilt published/promoted/sticky status into separate selects?)
Updated: select less than/equal/greater than, textfield/datefield.

naught101’s picture

David Lesieur’s picture

Here's the D7UX mock-up on this subject, which also adds a search box.

There is a request to add search to the content administration interface (#201493: Add a search box to content management option), and another to add search to the admin interface of each type of entity (#497804: [meta] Search entities (nodes, terms, etc.) within the administrative interface). Perhaps we could merge this issue with one of those two, as all are aimed at improving the admin interfaces, but I guess it would be easier to fix the filters first as a separate issue, then add the search feature.

David Lesieur’s picture

Status: Active » Needs work
Issue tags: +D8MI, +montreal
FileSize
7.32 KB

Here's my first attempt at this. It needs work but I'd like to gather feedback before going further. For now this is only for the admin/content page.

Notes:

  • Need to add some styling.
  • Need to implement similar change on admin/people.
  • The patch removes bits of code related to filtering by term and by translation status. Perhaps I'm missing something, but I could not find how those bits of code could work. It looked like remnants of some long-forgotten features (maybe only forgotten by me).
  • This confirms that $_GET parameters survive paging, table sorting, node editing and node deletion.
  • Adding the D8MI tag because this might help a little bit with the grand vision of a central place where to manage content translation.
David Lesieur’s picture

Just found out about the #empty_value and #empty_option form properties.

Gábor Hojtsy’s picture

Can you post a screenshot of how would this look like?

naught101’s picture

Re: mockup image:
- Has no filter on title. This is a killer for me.
- Filter on author name should probably be an autocomplete, not a select. It's quite reasonable for a site to have hundreds of content authors.
- Also, WTF are "draft" and "closed"?

Gábor Hojtsy’s picture

@naught101: well, the current patch just reorganizes the current filters as per the mockup. It does not add title filter or a user filter. Also, we can make the user filter be different depending on the number of users on your site. If you have a brochure site with 5 users, a dropdown would be perfect IMHO, otherwise we can make an autocomplete. However, once again, not for this issue :)

David Lesieur’s picture

To me this issue is only about making this UI suck less. :-) I'd leave title and author filtering to #497804: [meta] Search entities (nodes, terms, etc.) within the administrative interface.

@Gábor Hojtsy: Then I'll add some styling to the patch before providing a screenshot.
@naught101: "draft" and "closed" are, perhaps, ideas from the D7UX process. Not related to this issue.

David Lesieur’s picture

Here's an updated patch and a screenshot showing how it now looks.
Not sure about the labeling. I'll ask around.

David Lesieur’s picture

The status selectors are awkward and this UI won't work well with admin/people (which require multiple selections). emarchak has given me good ideas on how to do this well. Stay tuned.

Gábor Hojtsy’s picture

Yummy, yum yum yum.

emarchak’s picture

FileSize
60.25 KB

As David mentioned in #355820-19: Improve query filter UI on admin/content , we've been spending some time discussing this. Here is the first version of the admin/content screen. The admin/people screen will be coming along shortly.

Proposed content type filter improvements

We have kept the filters as drop down select lists inline with each other, as posted in previous mock-ups. In the previous version, we realized that there would be many usability and accessibility issues with requiring people to select multi items in the select box. Not only is this behaviour confusing, but it's near impossible for people with mobility issues.

What I did is use the select lists as the "label" of the fields, and list the active filters below the labels. Filters can be added by selecting them from the dropdowns, and then hitting "Add Filter." Filters can be removed by clicking on the "X" or the name itself and only the selected one is removed, this is communicated by marking up item as an anchor tag. This is similar to the current version, but adds a bit more functionality than the "Undo" or "Reset" buttons"

In terms of functionality, each of the filters act as an "or" search with in the select lists, and "and" filters between the select lists. This is communicated by displaying "or Filter Item" when a user adds more than one filter item from a select list. The search defaults to "All" when no filter items are selected from the lists. The actual search that is shown in the mock up would be:

  • Published Nodes
    AND
  • Promoted to Front page
    AND
  • All Sticky States
    AND
  • Article content type OR Blog Post content type OR News Items content type
    AND
  • English Language OR French Language
Everett Zufelt’s picture

Perhaps this UI is too complicated to explain in text, which might mean that it is too complicated :) #21 does a reasonable job at attempting to explain, but it is still unclear to me, in particular:

"What I did is use the select lists as the "label" of the fields, and list the active filters below the labels"

Bojhan’s picture

I do wonder, are we actually using the right form elements for this - I know we are set on select lists because its a) a common pattern b) it scales nicely. But its difficult to understand selection of several items and with few items, is better covered by a checkbox. I mean, faceted search is a pretty common pattern - with some tweaking it could very well apply here.

I do really love the thinking that has gone into this, and the overview is really usable. My concerns above a side, we could definitely pursue this. Can you shed more light on your general concept, do you want these filters to be collapsed by default, does the mass operation fieldset make sense? Where do we allow searching of this list to appear on this page?

@Everett Basically all the select lists are aligned horizontally, and each select list for example "Publishing state" has below it the selected option, for example Published. In a way (visually) are the select lists (Publshing states, Sticky states, Content types, Language) the table headers, and are the selected option(s) shown below in a row. Let me know if that makes sense.

Gábor Hojtsy’s picture

@Bojhan: is it acceptable for you if it does not downgrade if JS is not there? Because we basically need a three-state checkbox here for many things. For publication status lets say, there is "I don't care, given me all", there is "Give me unpublished only" or "Give me published only". That is either a three item radio group / dropdown or a three-state checkbox (the later which is not a native browser control and would need JS). So if we want to have it a checkbox, we need a custom control for this and fall back on the select boxes I guess.

Bojhan’s picture

Title: Improve query filter UI on admin/content and admin/people » Improve query filter UI on admin/content
Issue tags: -Needs usability review

Focusing the issue some more.

@Gabor isn't that the case for any faceted filter?

Gábor Hojtsy’s picture

@Bojhan: Yes. Do we have any of those in core though that use checkboxes? No. So therefore the question of how to do it. New stuff, need to figure out, right? :)

Everett Zufelt’s picture

I am pretty opposed to requiring JS for functionality, but using a select or set of radios, progressively enhanced to a tri-state checkbox might be workable.

We'd need to do some testing with mixed-state checkboxs to see how far back AT support goes. WAI-ARIA provides an checked state, but I don't know how well it is supported.

See http://www.paciellogroup.com/blog/misc/ARIA/tristatecheck.html

Gábor Hojtsy’s picture

I'm not sure people understand tri-state checkboxes even. This is one of my favorite interview questions: please code a tri-state checkbox widget. Most people are stumbling on even finding out what it is. Do people understand them?

jhodgdon’s picture

A title keyword filter (for nodes) would also be desirable. See #497804: [meta] Search entities (nodes, terms, etc.) within the administrative interface for discussion.

Gábor Hojtsy’s picture

@jhodgdon: yes, this issue is about cleaning up the UI as in now so it can accommodate that filter and a user author filter better. :)

David Lesieur’s picture

Here's another proposal that:

  • Certainly looks similar to the current interface, but without the refine/undo/reset button confusion.
  • Allows easy removal of individual filters.
  • Sticks to combining filters with AND operators. I'm afraid that switching to OR would cause some to cry, and my impression is that AND will be more useful than OR for filtering by roles or permissions in admin/people.

The filter removal links in this screenshot are ugly, but would be overridden by the administration theme to use nice icons.
The patch is very rough and breaks admin/people. I'll refine it if we want to go forward with this interface.

jhodgdon’s picture

I like this mockup, but why are Type, Status, and Language still available after already being specified? Does that allow you to change them from their current values? I was obviously confused by this... just one usability data point...

David Lesieur’s picture

@jhodgdon: I had this described in @todo comments in the patch but forgot to mention it in #31. My idea was to remove options that do not make sense. If a language or type option is already active, no language or type selector would be offered. If a status option is selected (e.g. "sticky"), that option and any mutually exclusive option would be removed from the status selector (e.g. "sticky" and "not sticky").

One thing I'm not sure about is whether to leave the status selector alone, or to split it into "Publishing state is...", "Sticky state is..." and "Promoted state is..." (as in #18 and #21). Splitting might make things easier to understand by users, because then all selectors would behave the same way with respect to active filters.

Gábor Hojtsy’s picture

I think making them separate is easiest on users.

Gábor Hojtsy’s picture

@David: are you working on this? That would be fabulous!

David Lesieur’s picture

Sorry for the delay. I'll resume work soon!

naught101’s picture

Anyone have any good evidence/links/reasoning for not using multi-select boxes with something like that done in #21? I think the assumption in the current discussion is that they don't work well with screen readers/keyboard navigation, but after a quick web search, I didn't find much, which is surprising, considering that they're a pretty widely used device. That kind of indicates to me that they're at least somewhat useable to keyboard users. I'm not claiming that's true, nor that it's not, I'm just suggesting that we get some evidence in before making a decision. Especially as that decision potentially involves introducing relatively new, and less well understood (and tested) interface devices.

David Lesieur’s picture

@naught101: What I intend to work further is more like #31 rather than #21. Instead of introducing a new UI device, it simplifies the current one.

Gábor Hojtsy’s picture

Assigned: Unassigned » Bojhan

Assigning to Bojhan for updated UX feedback. @Bojhan: we are looking to see your opinion on #31 and #21 and which one would work best, or you have better ideas for a third approach :) You've been advocating checkboxes above. I'm not sure a mixed set of checkboxes and select boxes would look good / clear. Would it?

@David Lesieur: Bojhan's feedback above basically is that we split the dropdowns per functionality (which I'd agree would simplify the filter UI).

@Bojhan: what about splitting this to distinct dropdowns for now and explore replacing three item dropdowns (don't care, yes, no) to tri-state checkboxes later once/if core has tri-state checkbox UI solutions? (We don't have that now that I know).

Bojhan’s picture

Assigned: Bojhan » Unassigned

I am very concerned, the approaches proposed are still far from thoroughly researched approaches (not very usable). I would love if we can review some of the existing solutions for this(in and outside Drupal), rather than straight of the bat inventing our own ones. Say, 10 different tools that provide this kind of filtering.

#21 Is the best one so far, because it isn't a direct boolean interface. I don't care so much for having or not having tri-state checkboxes. I am not really keen on designing a third solution, before we have done some research.

David Lesieur’s picture

If we want the ideal interface, then we should probably look into integrating a faceted search pattern in core (Bojhan has mentioned this in #23; I like!). But I'm afraid we'd only get there in a far future.

Or we could pick a lower hanging fruit by going the easy way of an incremental improvement to the current UI, as hinted by #31... ;-)

Gábor Hojtsy’s picture

@Bojhan: is there a larger scale plan to work on this? I'm interested in this to be able to serve as a translation dashboard too, and incremental improvements would be great for that too. If there is no overall work being done, is our current system better than the ones proposed above?

Bojhan’s picture

@Gabor No big plans, but in general I want us to think big rather than small in this brainstorm phase.

Gábor Hojtsy’s picture

Issue tags: +language-content

Tagging for the content handling leg of D8MI.

yoroy’s picture

klonos’s picture

drupalvino’s picture

Hi,

Im using drupal 7. In my case, I need to filter the contents by content type fields in admin>content.

Any idea about this. Is there any contributed module for this.
Plz guide me. Its very urgent.

yoroy’s picture

drupalvino: this is not a support channel, your urgency is not our urgency and certainly do not cross-post the same question across multiple threads.

yoroy’s picture

Drupalvino, I apologize for being too harsh there. Klonos did better in his reply in the related issue.

drupalvino’s picture

Yoroy, Its ok. Its my mistake too. I am new in drupal and drupal.org. So I dont know how to ask my doubts. Thats why I asked here. Here after I'll post in forum. Sorry for disturbance. Thank you.

Noyz’s picture

Seems there's some cross over in the mockups I just posted regarding the find content UI: http://groups.drupal.org/node/219099

Gábor Hojtsy’s picture

Issue tags: -D8MI, -language-content

D8MI is not going to resolve this.

tkoleary’s picture

I have a new prototype for this which is based on work done by myself and dawhener at Bad Camp but with updated styles from Seven style guide.

The prototype is here: http://invis.io/R8F4K2BC

It's also posted in this issue: #1475204: [META] Provide a generic search/filter UI interface pattern for listing pages

tkoleary’s picture

Issue summary: View changes

Unfollowing this issue seems to be broken since I am the original author, changing the author to Abandoned Projects, please feel free to change it to someone more appropriate for this issue.

xjm’s picture

Component: node.module » node system
Issue summary: View changes

(Merging "node system" and "node.module" components for 8.x; disregard.)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
quietone’s picture

Status: Needs work » Closed (outdated)

Thanks everyone for working on improving admin/content.

This is no longer relevant since the page is a view in Drupal 8.0. Closing as outdated.