Where to place list filter controls?

Question

Suppose the user -- from a CMS backend WYSIWYG editor -- opens an Insert link-dialog. When having a list of possible link destination pages,

• where would be an appropriate place to put filter controls if the UI should cater for inexperienced as well as experienced users?

Suppose the controls are placed above the list, like (1):

This might be an advantage to more experienced users, since they have fast access to the filtering tools. However, for more novice users, the filtering tools might appear to be required -- due to the implied flow --- rather than optional, assistive tools (as intended from a design perspective).

Another approach would be to place the filtering tools next to the list, like (2):

This way the filtering tools are less in-your-face.

A third approach would be to initially hide the filtering controls, like (3A & 3B):

The advantage here is the reduction of the number of UI elements on the first encounter. The downside is the extra click to open the filter options. However, a cookie might be used to store hidden/visible state of the filter controls.

Perhaps a more toolbar-like styling of the filter options is the way to go, but then again, this would be yet another UI element.

Any thoughts on this?

Answer 1

IMHO, you should not toggle the visibility of the filter buttons. Keep it simple and show the user which interactions the UI supports.

When it comes to the choice of top/right position, the answer will probably be obvious during a test. You already have some mockups, so it's not a big job to ask a few people to "complete some tasks".

I really don't think it matters whether the buttons are on top or on the right, but the position will be "more fixed" at the top. If you put the buttons on the right, you can end up with a bit of a distance between the list and the buttons. Eg. if the user resizes the screen or the width of the list.

I would consider the buttons on the top as related to the grid, whereas the buttons on the right are more general buttons (like a action panel).

Update

Placement of the buttons when resizing the window:

Visual work-flow:

Answer 2

To respond to my own question, inspired by Luke Wroblewski's idea to focus on mobile first (e.g. http://www.lukew.com/ff/entry.asp?933) and Apple's eagerness to flatten information hierarchies, the UI might look something like this:

Here the search field would respond to both page names, ancestor names (written in gray below the page names) and page ID's.

Unfortunately, a UI like this is beyond the scope our redesign project.

Answer 3

I like 3a/3b. Most users won't need the filter, and a user can easily select a page without using it (if they don't notice it or if they don't know what it means).

This seems like a rather complicated UI just for inserting a link. How does the user manipulate the hyperlink text? The internal site browser you have may be helpful for users who are not web savvy, but it may be more of a hassle for users who are. Who is your target audience? Is this a general purpose CMS or is it geared toward a specific industry?

You might consider a more traditional dialog with two fields: [URL] and [link text]

Answer 4

I would say the 'filters' can be more powerful and intuitive to first time users then the hierarchical folder list.

What if you would use the filters as a powerful search and let the hierarchical folder list be optional?

Search results would show up on the right and change as the search/filters change. The "show all pages" would open up the hierarchical folder list, also on the right (which can be filtered in the same way from then on).

(I do make the assumption that there are quite a lot of pages. Otherwise just displaying a folder list is quicker and filters are not needed at all.)

Maybe this is more than what you can change about the application. In that case, make the filters more apparent and let them get more attention (visually and/or in wordings) than the folder list.

In the future you can even think about merging the internal and external tabs in one input/search. As most users don't know the difference between the two, this can help a lot. The interface reacts differently if what you type in might be an external url (starting with http, www, etc) and/or if the text is found as an internal page.

Update

I've changed the mockup a bit. Putting more emphasis on the first search field and changing the dropdowns into search fields as well. You can also view the previous mockup if wanted.

Of the first mockups you gave, I especially don't prefer the 3A/B one. It adds one more click and only triggers more questions and distraction for first time users. If you would want to show less of the filters I think it is best to use faded/grayed fields, icons and buttons.

Answer 5

Considering that you'd like to cater for both inexperienced and experienced users, my first guess would be to go for your option 3: hide those filter controls. Maybe you could also make the visibility state persistent - if the user leaves the page with the control expanded, it will still be expanded on their next visit.

If you build in a reasonable focusing behavior, one click or key press will open the filter control and instantly give keyboard focus to the field that is most likely being used, so the user can just start typing away.