View Issue Details

IDProjectCategoryView StatusLast Update
0016854mantisbtfilterspublic2017-07-03 20:33
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.2.15 
Target VersionFixed in Version 
Summary0016854: Simplify the filter box at the top of the View Issues page
Description

The current approach for viewing the filter has the following issues:

  1. It consumes a lot of vertical space.
  2. It is not immediately obvious what is the applied filter - has to scan all fields.
  3. It is hard to make the filter box look right as features / custom fields are added / enabled / disabled / etc.

I'm suggesting the following:

  • Replace the filter box with a text line that explains the active filter criteria. For example: "Filter: all", "Assigned: vboctor, Hide Status: closed, etc." The exact text formatting can be refined.

  • Add filter edit page that has a filter criteria per line. Hence, adding / removing filtering criteria at runtime is super simple. Once the user applies the filter, they go back to the View Issues page with the filter applied.

  • The View Issues page that continue to have switching between saved filters, or saving current filter.

With this approach I think the implementation will be much simpler, use space efficiency, and will allow users to figure out the active filter at a glance.

TagsNo tags attached.

Relationships

related to 0021031 closedcproensa Rewrite the filter box form 
has duplicate 0017343 closedvboctor Change filter box to show active filter in compact form with Edit button 
has duplicate 0009065 closedvboctor Ability to configure Filterbox to show only configured fields 
related to 0020883 new Request: remove filter view type 
related to 0021833 new Highlight or emphasize the set filters in the filter form for easier visual recognition of what's being filtered 

Activities

rombert

rombert

2014-01-20 06:16

reporter   ~0039105

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

atrol

atrol

2014-01-20 07:35

developer   ~0039106

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.

vboctor

vboctor

2014-01-21 10:04

manager   ~0039114

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.

vboctor

vboctor

2014-05-16 03:26

manager  

vboctor

vboctor

2014-05-16 03:27

manager   ~0040295

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?

grangeway

grangeway

2014-05-16 04:05

reporter   ~0040296

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.

dregad

dregad

2014-05-16 05:56

developer   ~0040298

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

grangeway

grangeway

2014-05-16 14:23

reporter   ~0040306

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?

Erik Krause

Erik Krause

2015-12-13 08:36

reporter   ~0052118

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;
}

Issue History

Date Modified Username Field Change
2014-01-19 19:48 vboctor New Issue
2014-01-20 06:16 rombert Note Added: 0039105
2014-01-20 07:35 atrol Note Added: 0039106
2014-01-21 10:04 vboctor Note Added: 0039114
2014-01-25 09:29 atrol Relationship added related to 0009065
2014-05-16 03:26 vboctor Relationship added has duplicate 0017343
2014-05-16 03:26 vboctor File Added: Screen Shot 2014-05-16 at 12.13.43 AM.png
2014-05-16 03:27 vboctor Note Added: 0040295
2014-05-16 04:05 grangeway Note Added: 0040296
2014-05-16 05:56 dregad Note Added: 0040298
2014-05-16 14:23 grangeway Note Added: 0040306
2014-11-25 11:22 vboctor Relationship deleted related to 0009065
2014-11-25 11:23 vboctor Relationship added has duplicate 0009065
2015-12-13 08:36 Erik Krause Note Added: 0052118
2016-05-07 09:12 atrol Relationship added related to 0020883
2016-06-10 06:47 dregad Relationship added related to 0021031
2017-03-30 04:27 dregad Relationship added related to 0021833