Reworking the filters of admin/content/node

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
mikey_p's picture

I've been doing some work on the node administer form at admin/content/node, to move the filter storage from a session to $_GET params in the URL. This could have several benefits:

  1. The filtered pages are then bookmark-able and shareable
  2. The filters will be reset every time a user navigates away for an extended period of time, or through multiple pages

There are also disadvantages:

  1. The undo option won't work any longer as we aren't storing the filter in an stack/order they were applied
  2. The filters will not be persistent until reset

A little more explanation on the persistence of the filters. Right now they are stored in the users session until they either log out, or they click the reset button on the form. At least for me, sometime I forget that these filters are in place and spend time looking for content that I previously filtered out (in a previous day using the site, for example). With using $_GET params, they are stored as long as the user stays on that page and uses the pager at the bottom, and they are persistent when clicking a link to edit a node, and submitting, returning to the node admin page.

About the inability to have an undo feature: Since the items are not stored in an array/stack anymore it isn't possible to determine what the last filter applied was. One obvious workaround for this, at least to me, is to add a button/link next to the display of each currently applied filter, to remove that filter. I would consider this a usability improvement over the current undo/reset method, as filters could be removed individually, without multiple undo or reset/reapply actions. (Also note I have observed users unsure of the difference between "Undo" and "Reset" as well, as either verb could apply to the whole set, or the last filter only)

So my question to the usability team are this:

  1. Overall, would this be considered a usability improvement, to be non-session persistent, and bookmark-able/shareable?
  2. Would individually removable filters be an improvement over the current system?
  3. What are the considerations for the UI for individually removable filters? Would someone like to work on a mockup?
AttachmentSize
node-admin-filters.png20.96 KB

Comments

There's already a discussion

skilip's picture

There's already a discussion going on about node administration over here: http://drupal.org/node/301902. Maybe you can share your ideas with them?

I don't think it'd be best

mikey_p's picture

I don't think it'd be best to chime in on that issue yet, as

a) This is will eventually be a rather large patch, that is unrelated to the patch there
b) I'm not sure what the best interface for this is
c) I have a feeling that this grand of a change needs to be run through the usability team anyway (that's why there isn't a d.o issue yet)

Talked about this in IRC

mikey_p's picture

Talked about this in IRC today and yoroy mentioned http://img.skitch.com/20090108-xxyhje7srxfhnhpckj37g8212y.jpg as an ideal interface. This makes sense to me, with a few exceptions.

In iTunes this dialog is brought up to start a new playlist, presumably on admin/content/node it will be sitting there until someone applies a filter, so I need to have some idea what the default values would be.

Also in iTunes this is in a dialog box that is then saved/dismissed to view the results. What would be the ideal process in this case, to tell Drupal to apply the filters and reload the page?

Mind you, I never said it

yoroy's picture

Mind you, I never said it would be the ideal interface, just that I was reminded of the smart playlist builder in iTunes! :)

Though in this case the "filter stack" is not hierarchical, another concept that might work here is something like the Hierarchical Select module UI.

I'llave to think about this some more…

Well maybe to me it came

mikey_p's picture

Well maybe to me it came across as an ideal interface. ;)

Provided we solve the initial values and submitting the filters issues, with a healthy dose of AHAH, this could be *REALLY* nice.

I can also see adding more filters if we can get the query builder to support them, such as author, title, date, and so on as well as operators (contains, or before, after, and so on).

I really like the

catch's picture

I really like the hierarchical select interface, and think it could work well here. Having said that, even just separating the filters out in the way views exposed filters look like would make it a lot easier to deal with.

So here are my initial

mikey_p's picture

So here are my initial ideas. (Please be patient as there are rough mockups in graffle, so the fieldset is probably sized wrong and layout may be off.)

Picture 1, the default state of the form.

Only local images are allowed.

Picture 2, the user has clicked "Add filter". This caused the "Apply filters" button to appear and the message to appear regarding clicking the apply button.

Only local images are allowed.

Filter types, operators, and allowed values

Status (is, is not) (dropdown of published, sticky, promoted)
Type (is, is not) (dropdown of all content types)
Taxonomy (is, is not(!!not sure how this would work, but would like to try!!)) (term browser as we have now)
Title (is, is not, contains, does not contain, starts with, ends with) (textfield (is and is not should be an autocomplete))
Author (is, is not, contains, does not contain, starts with, ends with) (textfield (is and is not should be an autocomplete))
Date (is, is before, is after, is between) (textfield maybe with a date picker widget (between would actually be 2 textfields))
Language (is, is not) (dropdown of all languages)

Questions

These are the questions that I have as of now. Obviously everything is open to change, but this is the general idea.

  1. Title of fieldset?
  2. Empty text?
  3. Name of "Add filter" button?
  4. Name of "Apply filters" button?
  5. Location of "Apply filter" button?
  6. When to display "Apply filters" button?
  7. Once there is a filter (subsequent page views), should the "Apply filters" button always appear, or only when there is a change to the filters?

I'm already thinking the

mikey_p's picture

I'm already thinking the "Add filter" button should be called "Add new filter" or just "New filter" to prevent confusion with the apply button.

I'm already thinking the

mikey_p's picture

I'm already thinking the "Add filter" button should be called "Add new filter" or just "New filter" to prevent confusion with the apply button.

Counter-screenshots. :D

webchick's picture

(Note: I ignored everything else in this thread and just reviewed the screen shots so that I'm "untainted." Apologies if I am re-hashing things that have already been said.)

Only local images are allowed.
Only local images are allowed.

Let's contrast this with Finder, which I think is what you're trying to emulate here:

Only local images are allowed.
Only local images are allowed.

I'm not sure what to propose as a "alternative" screenshot though. It's a tricky problem. Here's a rough idea which I am in no way married to:

Only local images are allowed.
Only local images are allowed.
Only local images are allowed.

Not sure. What do you think? A big challenge is making this degradable for people without JS. No idea what this would look like then... Hrm.

I much more like your

mikey_p's picture

I much more like your screenshots. I didn't break mine up that much, although I am describing similar functionality. Two questions:

  1. Does the next empty dropdown appear as soon as the first filter is selected? Use case: I want to configure 3 filters, then click apply without waiting for page loads in between all of them. This should be doable, but then do you have 3 Apply buttons next to each filterset? Which one do I click?

  2. What happens when I get the filters wrong and change them? Do we then show an apply button next to each filter that I change?

This is why I think a global "Apply" button might make more sense. The best approach may be to just hide the apply button until a change is made to the filters.

Also, re the width of the dropdowns: They are intentionally wide because if we add some new filter types the operators could potentially become quite long. Compare "is" to "is not" or "contains" and maybe even (if I can figure out a way to write the query(shouldn't be to hard)) "does not contain". This would allow all the columns to line up. See the sample below:

Only local images are allowed.

I was thinking AJAX page refresh

webchick's picture

So the table effect would be "instantaneous," rendering both of those concerns moot ("in theory" ;)).

Personally, I don't like the idea of building a big list of filters and not knowing what I'm getting until I click "OK." I like progressive reinforcement of what I'm doing. In your iTunes screenshot, if I didn't have any > 180 BPM tracks, for instance, I would want to know that immediately, before I enter another filter criteria. Otherwise, when I end up with no tracks in my filtered list, I'm not sure which of the three criteria was the reason, and I have to start over from scratch.

The width thing makes sense. I forgot to mention that one of my very favourite things about using select lists instead of the current ugly radios for this is the potential for other modules to add their own stuff here. Some very powerful things possible. So kudos for that!

Screenshots

smokingtrucks's picture

Those are sweet looking. What application did you use to mark them up??

Cheers,

Neal

cool

naught101-gdo's picture

http://drupal.org/node/265941

Some great proposals here. I especially like webchick's proposal.

Something that's always been missing from the page is a simple text search (over text+body+fields). The "Project" module does this well (ie. the issue tracker on drupal.org - ie. http://drupal.org/project/issues/search/drupal )

Emulating the iTunes smart playlist would be awesome - the "X items per page" option would be very good to include.

One of the problems with the current setup is that it's possible to filter for mutually exclusive properties - ie. you can add a filter for "published" AND a filter for "Not published", and you get no content. This wouldn't be a huge problem if there was a remove button, I guess.

It might also be worth having an "AND/OR" selection - this would make it possible to search for content in multiple categories at once.

there's also this:

naught101-gdo's picture

there's also this: http://www.d7ux.org/content/comment-page-1/
nice "find content" interface

Cross referencing

naught101-gdo's picture

The issue for this discussion is here: http://drupal.org/node/355820

Screenshots

smokingtrucks's picture

Wrong comment thread, sorry

subscribing

fei's picture

subscribing

Filter contents by content type fields

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.

andrewmacpherson's picture

Hi Drupalvino,

I recommend using Views for this. You can build a custom content listing, showing any fields you choose as table columns. Exposed filters will allow you to narrow your list by field value.

If you need any help setting up Views, check out the NodeOne learning video series, especially the episode about exposed filters.

Views Bulk Operations might also interest you. It adds customizable "bulk operation" tools to your view. Configuration can be tricky, because VBO is a powerful module and there are lots of ways to use it. It's a lot of fun though :-)

VBO includes a ready-made specimen view (content2) to get you started. it's similar to the the D7 content listing, but you can customize this view to meet your needs. Keep in mind that not all content types have the same fields. It might be a good idea to make a separate view to administer a particular content type.

(Subscribing)

kazar's picture

(Subscribing)

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: