Sounds good. Some screenshots/mocks would be nice when/if we can start developing this.

What about a button line instead of a text line?
For example: "Assigned: vboctor X", "Category: localization X"
The filter condition gets removed when clicking the button.

This simplifies some use cases as you don't have to enter the filter edit page.

I'm thinking there are two categories of work here:

1. Completely re-think the filters interface using jQuery - I would approach this by ability to + to add fields and x to remove them. Maybe there are 3 or 4 main ones that are visible by default but set to all.

2. Smaller change to move the current interface out of the way.

Would love to get 1, but 2 can get us to a better state from where we are at today.

I've attached a screenshot of an early prototype.

The final version will:

• Have all field name localized.
• Will only display fields that are different than the default filter.
• Will include the ability to switch to other saved filters.
• Will include the reset filter option.

I would like to get your thoughts before I go further.

A future version will:

• Completely re-think the filters interface using jQuery - I would approach this by ability to + to add fields and x to remove them. Maybe there are 3 or 4 main ones that are visible by default but set to all.

Thoughts before I go further?

I've asked 3 users of Mantis (that aren't technical to look at the screenshot) and they were confused.

Personally, I'm not that sure the text version is any clear in it's current form, and from what I can tell it adds an additional click to change the filters.

Whilst I agree that the current approach for filtering is broken. I'm not sure this is the solution.

I think we should do some research around what other bug / issue trackers and similar systems do and consider a planned approach. for example, Github makes use of a sidebar on their site (e.g. https://github.com/ether/pad/issues?page=1&state=closed) to provide filtering functionality.

Trac makes use of a dropdown/collapsible menu approach to build a query: http://trac.edgewall.org/query for example.

Not sure how that one managed to escape my attention back in January... Anyway, I think redesigning the way we do filtering/search is a good idea.

I am not sure that a static display of the criteria is a good solution though. For anything but simple filters, it would quickly become too verbose and not very useful/user-friendly.

If the main concern is to gain vertical space, a "quick win" considering that today the search criteria are in a collapsible section, we could have it collapsed by default.

In any case We should at least always provide a selection list with the saved filters.

The 'x' button approach to remove filter elements would be good to have too; ideally users should be able to add criteria and edit them easily, which leads us to the more complex design.

For a full-featured edit filter page, I like the bugzilla approach [1]. For a more dynamic, "in-page" approach, I think Jira's style [2] is the best; alternatively the Trac style mentioned by grangeway would work as well.

Of course, the big caveat is that if we touch the filter's front-end there's a pretty good chance that the API will need some rework too... any volunteers for that ? :-P

[1] https://bugzilla.mozilla.org/query.cgi?query_format=advanced
[2] https://jira.cyanogenmod.org/issues/?filter=10102

Now i'm home from work and have more time to focus on thinking about this properly:

I'd really like to get an idea of our 'end goal' - I mean, we know that Mantis is 'dated' in terms of it's UI. (I think everyone's actually agreed on that for a change)

So improvements to the UI are needed, but equally, I'd rather spend the time to make sure that the UI improvements meet an end goal and are well planned out, rather then hacking something together that we need to change.

For example (and without knowing what code changes), we(well, victor) states: "add a filter edit page" and "re-think the filters interface using jquery"

Does that mean we plan move the filter management out of view_issues.php to add a seperate filters management page and then remove the seperate filters management page and move it back into view_issues.php with a jquery interface?

Until this gets addressed I added the following CSS, which is certainly not very convenient if you use filters regularly, but at least hides the box leaving the functionality intact on small or new projects where filters are seldom used:

#filter_open {
height: 13px;
width: 30px;
overflow: hidden;
}

#filter_open::before {
color: #0000ff;
content: "Filter";
cursor: pointer;
text-decoration: underline;
}

#filter_open:hover {
height: auto;
width: auto;
}