View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0016854 | mantisbt | filters | public | 2014-01-19 19:48 | 2019-12-05 07:20 |
Reporter | vboctor | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.2.15 | ||||
Summary | 0016854: Simplify the filter box at the top of the View Issues page | ||||
Description | The current approach for viewing the filter has the following issues:
I'm suggesting the following:
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. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
related to | 0021031 | closed | cproensa | Rewrite the filter box form |
has duplicate | 0017343 | closed | vboctor | Change filter box to show active filter in compact form with Edit button |
has duplicate | 0009065 | closed | vboctor | 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 |
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? 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:
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:
I would like to get your thoughts before I go further. A future version will:
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 |
|
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 { #filter_open::before { #filter_open:hover { |
|