As soon as you select the text field, a dropdown comes up to show you the types of filters you can use. You can select one of the options by clicking or hitting Enter. You can navigate the list with the arrow keys in your keyboard or by typing in the type of filter you want. If you type in a word that's not part of the list, a normal text search will be performed.
Using a filter
When you select the type of filter you want to use, the first half of the token appears and the next dropdown shows up. You can either scroll through the whole list or start typing to narrow it down.
Narrow down results
As you start typing, the closest match gets selected. You can click it or hit enter to select.
Filter was added
Once you select the user, the token gets added to the field.
Selecting a token
When you click on a token or hit backspace when the cursor is next to it, the token gets selected, which is represented by it becoming darker.
Editing a filter
If you double click a token or press enter when it's selected, you can edit the value for the filter.
Assignee dropdown
Weight dropdown
Label dropdown
Default / Saved filters
The dropdown on the left houses a list of default filters to make it easier to perform common searches, as well as any filters the user has saved.
Scrolling
The dropdown at the bottom is fixed and the list scrolls underneath it.
Using a saved filter
The star turns orange to indicate that you're using a saved filter. If you edit this search the star turns grey again.
Several filters added
Mobile - Empty state
Mobile - Types of filters
When the user taps on the search bar, it takes control of the screen and the user immediately sees the list where they can select the type of filter they want.
Mobile - Filtering
Just like on desktop, when they select the type of filter they want, the next dropdown comes up. They can scroll through the list and avoid typing at all.
Mobile - Filter added
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
@regisF ha yes, maybe I'll clean it up later on ^^
this does add dramatic value
This currently concludes all CE issues related to this meta issue (got through 13 pages in CE and 2 pages in EE of issues searched on "filters")
It's scary how many times saved searches/filters comes up. My thinking here is to include most of these requests with the new design. Let's do this thorough ;)
One of the pain points for this issue to get done real good is being able to show your subscribed issues/mr/pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/12697 We have to get this in imo, else our filtering options never reach their full potential. @dzaporozhets@JobV@regisF > possibly a good feature for EE, although @DouweM has already conveyed it's quite a technical challenge.
I'll come back to this with designs, my main thinking here is a solution that makes the search bar reallllly powerful and interactive and has the drop downs as a backup rather than first class citizens.
Also this design should fit in multiple places as it does right now most of the time:
issues/mr/branches/pipelines/projects/builds?/commits/todos/milestones/snippets .... any others?
I've had an similar idea to this for some time. It doesn't take every aspect into consideration but I wanted to put it out there and get the cconversation going.
Empty state
I removed the current filters and replaced them with a single dropdown to choose the kind of filtering you want to do.
Choose your type of filter
Text search
Text search is the default type of filtering, so just start typing whatever you want to search for.
Text search added
When the user hits enter, the filter becomes a token in the "Smart filters" text field (or whatever we might call it).
Filtering by author
When you choose a filter type different from text, you get autocomplete help like we do now. The popup shows up as soon as the text field is selected.
Adding a smart field
You can start typing in the "Smart filters" text field directly, which will bring up a popup similar to the one we have for slash commands. It'll help you autocomplete and let you know what kinds of actions you can perform.
Multiple filters at the same time
Having the tokens in a text field allows you to manipulate them and use boolean logic on them.
This design is pretty out there, but I'd love to hear opinions and see how it can be made better.
Nice start, @cperessini. I wonder if the dropdown/input field on the left is necessary if it is just a duplication of the dropdown that appears when clicking the smart field?
I'd love to do this, as far as I can tell the issue filtering isn't really fixable without rebuilding it from scratch. If we do this we have to make sure it's tested like crazy to prevent all the problems we're seeing with the current search filters. I can gather all the relevant issues that exist with the current search if anyone is interested.
@cperessini you should check out the Sentry search filter UI, it's kind of a combination between our current design and this mockup. I'd include screenshots but I have no access to the GitLab Sentry at the moment.
Some things you missed (you did say this was just a quick concept, but I can't help myself ):
How it looks to add a boolean filter
How it looks to add the value for a given key (e.g. after typing "author:" what does the suggestion UI look like?
How this would work on Mobile
I'm also somewhat concerned that the two fields would confuse users, it's not immediately obvious that the first field would add parameters into the second one (I didn't understand it until halfway through writing this comment, and I guess neither did @tauriedavis). Either we'd have to remove that left field or prevent users from adding text to the right-field and only allow users to remove parameters. I kind of think a Sentry-esque search interface would be best.
Also maybe we should use icons instead of text to show the type of parameter (e.g. author, label, milestone, text)?
Yeah, I did see that the fields would be added to the smart search. I could see how people would be confused, though. It seems like duplication to have the left field, anyway. You can just add directly to the smart search instead.
As for mass updating, I think we need a new Edit issues button. I find the current implementation confusing. I made an issue awhile ago here https://gitlab.com/gitlab-org/gitlab-ce/issues/19712. Editing issues could switch from the smart search to the filter selection.
@tauriedavis you'll have to ask to be added on Slack, maybe they can add you to the staging project so you can mess around with it? Ask Stan or Robert Speicher. They don't seem to have a demo instance unfortunately.
I figured having two text fields could be confusing. The main motivation was that most first-time users are gonna need a graphical call to action. That's why I thought that including the dropdown was necessary, but I think that an icon could be enough.
Empty state
I removed the bar with the dropdown and included the Reset filters option inside the smart filter bar.
Adding your first filter
As soon as you select the text field, the pop up comes up to show you the types of filters you can use. I'm not sure that we need one for Issue text. Maybe writing a string without : in it can do a regular search.
I've updated the style of the slash commands to make it look more approachable both for clicking and tapping on mobile.
Using a filter
When you select the type of filter you want to use, the next pop up shows up. You can either scroll through the whole list or start typing to narrow it down.
Narrow down results
As you start typing, the closest match gets selected. You can click it or hit enter to select.
Filter was added
Once you select the user, the token gets added to the field.
Adding a boolean operator
I'm not quite sure how we should handle these, but maybe we can recognize that the user wants to add an operator when they type :
Mobile - types of filters
When the user taps on the search bar, it takes control of the screen and the user immediately sees is a list to select the type of filter they want.
Mobile - filtering
Just like on desktop, when they select the type of filter they get the next popup. They can scroll through the list and avoid typing at all.
Mass update issues
I don't think there's a problem with this. When the user enters issue editing mode the bar gets populated with the attributes that apply to all selected issues. After that they can add more attributes and hit save. Whatever is on the bar gets applied to all issues.
I'm not quite sure how we should handle these, but maybe we can recognize that the user wants to add an operator when they type :
How about just type space and then the dropdown of the :or: / :and:/ :not: will appear automatically? I think typing a space is the first step after people entered some words.
Apart from a search field that has the same behaviour as what @cperessini suggested, they also have a dropdown on the left that contains the most popular queries.
@regisF@connorshea We could combine that with the ability to save your frequent searches. The same dropdown could contain searches defined by GitLab as well as your favorites.
I'll upload some mockups for the features mentioned in the comments soon.
@cperessini This is awesome! Super excited for this work, and I love your clear, simple and smart approach.
Quick question: Are there concerns about the time it will take for the type ahead results to appear? Or a limitation to the type ahead results? For example, I know from #3148 (moved) that due to performance concerns, the current author and assignee dropdown only search members (maybe that is what most people expect?). Will labels be quick to query?
I'd very much prefer avoiding complicating this experience and want to keep it simple and clean. Just mainly curious if there are any concerns about perf that we should take into consideration with the design (or preemptively fix any perf concerns :) ).
@awhildy AFAIK, there shouldn't be any performance concerns, apart from the user queries, which we currently have restrictions for performance as you've pointed out.
The labels will be requested in the same way that the current label filters do, which work just fine for our current 103 labels.
We're soon to get a backend engineer assigned to this issue which will put any concerns to rest. :)
This looks awesome. I'm just not sure about the icons and avatars. Are they entirely needed? I feel like we could save a lot of space if we don't use any icons at all.
@alfredo1: Although I appreciate the question and push towards minimalism, I do actually like the avatars and icons (and don't feel like we are hard pressed for space)
I like keeping the avatars as they are an aid to help make sure you select the right person. We represent people with an avatar and name throughout the UI so that consistency feels good.
I like keeping the icons as they help differentiate these options from regular type ahead completions. Looking at the earlier comps without the icons, I find that the icons help me understand that these 'commands' do something slightly special. And the boolean operations icons might actually provide a little bit of explanation.
But this is just my 2 cents with my initial thoughts. @cperessini, what do you think?
@lbennett Unless @cperessini has more thoughts, I'd love to get this started. I know there may be some open questions about having GitLab defined searches, or allow you to save some frequent searches, but I believe those details could come after implementing the awesome base functionality of just being able to filter in this way first.
@awhildy I am with you on this of course. I would just add that this should look like the other user dropdowns right? For example it does not seem to look close to the assignee dropdown.
Or are we redesigning that one? I like @cperessini's better.
@awhildy@alfredo1 Those were my reasons to include the pictures and the icons. They help you identify the users and recognize the options in the dropdown as actionable.
@awhildy@lbennett The designs are pretty final but there are things that are missing, like the ability to save your favorite searches. I haven't posted an update here because I've been working on other issues, but I'll star working on this one again so we can move it to Frontend/Backend.
@jschatz1@dimitrieh Exactly, the old filters are going to disappear, so this is a good opportunity to come up a different style that works better for this feature.
This is super amazing, I am very excited to see your great work on this @cperessini. @jschatz1, @lbennett and me just made a discussion about rewriting dropdowns, this can be for real in very soon. Maybe not that fancy and, or, author, text stuff in first implementation but it's the direction we want to go. Very exciting, thanks for everyone who contribute this
Thanks @jschatz1 for bringing up the dropdowns. I'm still getting up to speed on everything, and it is always helpful to point out those sort of things.
@cperessini Totally on board with updating the design of the dropdowns. Your sizing, padding, and type all feels better and more balanced to me. However, we need to consider the impact of this across the board. I'm not sure all the places the dropdown currently shows up, but one example is for 'Assignee' on the side pane when you are looking at an issue.
Two concerns we may come up against:
In your designs above, you are hanging the dropdown off of a large text box, so the dropdown itself doesn't need a search field in it. However, in other instances, such as the side pane, there is currently no text box directly on the side pane.
In some cases (maybe all 'Assignee' people picker cases) 'Unassigned' needs to be an option in the dropdown. This is important for 'Assignee' even in your flow above.
I think these concerns are definitely solvable, and I'm excited about this work. @cperessini, thoughts? Thanks!
@awhildy Regarding your first bulletpoint, we will be aiming to create a completely new set of dropdowns for this feature, we've been struggling a lot recently with taming our current dropdowns so will use this as an opportunity to rewrite them. This means for a short while we may have 2 different styles of dropdowns across the site, but, hopefully right after we're done with this feature, @cperessini can hand us some adapted dropdowns to work in the areas you highlighted, like the right sidebar, and we can work them in ASAP for consistency. Plus... They're epic.
@lbennett: Makes sense. It will be a little concerning to be in a state where we will have different, inconsistent drop downs. The plan makes sense, though, and I understand that we have to chunk up the work. I'm just hoping we won't be in that state for too long
@cperessini The checkbox on the left is pretty important, it's responsible for bulk updates, this opens a new area of functionality that needs to be designed for.
Have a go on your local instance, check that box and then select some more labels and click the Update issues button.
Looking at your current designs, the checkbox can probably be kept where it is, but there is a couple different filter dropdowns, status and subscription and also the dropdowns should have a slight change of state, the label dropdown for example...
The dash marks labels that are applied to some issues in the selection and the tick marks labels that are applied to all issues in the selection.
Also, on the issue boards page, we have a Create new list button on the filter bar, this should be moved or accommodated for in your designs, again, just like the checkbox, it can probably stay there and we just change the width of the filter input, but I'd like your confirmation. :)
Also, a second look at this, it replaces the sort dropdown so should be okay to keep there.
Its maybe smart to divide this up in subissues ;) for each view, discuss main design here plus make a list of features it absolutely has to account for, then check of each ?
I removed the x to clear the search as there is no search (thanks @dimitrieh)
Types of filters
I removed the lines separating each row and I tweaked the sizes and padding for every dropdown. I also added a little padding at the top and bottom of each table. It looks nicer when no elements are selected, but adding that padding means a white stripe appears between the edge of the table and the highlight for the first element. Thoughts on this?
Simpler search
I thought about changing the way that search works so the a keyword is not needed. Maybe the first element can prompt the user to keep typing and when they press enter it'll search for whatever they wrote.
Filter type selected
When you select the type of filter you want, the first half of the token appears, instead of the old author:. I included an option for Any author. Using that value should be the same as not including that token at all, but some people might want to use it for boolean logic.
Autocomplete
The white stripes are even more noticeable here.
Author filter was added
No changes here. Just showing it for consistency's sake.
Selecting a token
When you click on a token or hit backspace when the cursor is next to it, the token gets selected, which is represented by it becoming darker.
Editing a filter
If you double click a token or press enter when it's selected, you can edit the value for the filter
Assignee dropdown
You can select Any assignee or Unassigned here.
Weight dropdown
There's an Everything option on the current dropdown, which I wasn't sure if I should include.
Label dropdown
Again, Any label or No label. The two options at the bottom are fixed and the list scrolls underneath them.
Creating a new label
Just the way it does now, when select Create new label the dropdown changes and you get to this one.
Default / Saved filters
The dropdown on the left houses a list of default filters to make it easier to perform common searches, as well as any filters the user has saved.
Scrolling
The dropdown at the bottom is fixed and the list scrolls underneath it.
Using a saved filter
The star turns orange to indicate that you're using a saved filter. If you edit this search the star turns grey again.
Missing stuff
A mockup for a complex query
A mockup for the Mobile version when the bar is not selected
Search inside the dropdown
Mass editing
Create new list for Issue Board (but the approach you mentioned is correct @lbennett)
Has any thought been given to how these filters will work if they overflow the text box?
Would something like this work? Not sure how that would interact with the cursor if you attempted to type more in there... Perhaps the breakpoint at which it collapses filters into this "ellipsis" would leave some minimum amount of space at the end so you can still input more?
@alfredo1 You're completely right, it slipped my mind.
@mikegreiling The idea is that it works like a normal text field. You can move the text cursor around the tokens as if they were text, so they should behave like text and overflow to the right. Does that make sense to you?
@lbennett I added the Sketch file to my folder in the design repo. I have to do a lot of cleanup regarding naming and grouping
Just an idea: if the search bar becomes really crowded, what about minifying the search filters to their bare elements via small animations, which will expand again when you click/hover on/over them or reach them with the cursor?
Like [author][avatar][Chris Peressini] becomes [avatar] and [label with color and name] becomes a really small [label with color]?
@cperessini I noticed a difference in the top and bottom dividers.
Is this intentional?
If so, I believe this means that the header items 'Any label' and 'No label' will be within the scroll container of the regular dropdown items? So scrolling downwards would make them disappear? But the footer item with the wider divider will not scroll and be fixed in that place?
@dimitrieh I talked about what should happen in that situation with @awhildy and we think it's best to keep things simple for now and treat the tokens as regular text in an input. That means there will be hidden items if you add enough of them, but you can access them with by moving the text cursor or scrolling horizontally inside the field.
@lbennett Yes, it's intentional. The footer stays in place and Any label and No label are part of the scrolling content.
@blackst0ne Great idea. All the necessary information is probably already being loaded or in cookies so I imagine it should be possible.
@cperessini@lbennett why Create a new label to make a search? We shouldn't be able to. Otherwise this search will always return 0, because this label is brand new.
@regisF Good point! We haven't really discussed this yet and it hasn't been accommodated for in the design, but there is a 'bulk issue update' feature, if you select multiple issues in the list with the checkboxes on the left and open the label dropdown, you can update multiple issues with a new label. Check out the screenshot here. This would make the 'Create new label' option acceptable, but maybe it should only appear if multiple issues are selected.
@regisF That makes total sense, it completely slipped my mind. We should remove it from the search feature, but as @lbennett mentioned it will be useful when doing a bulk issue update.
@cperessini These improvements for search are awesome! I would love to see this same look-n-feel applied at the Group level. And it would be amazing if the Group level had a flat list of results like the Project level. Something like what @dzaporozhets approved in gitlab-org/gitlab-ce#15627. That way both search and sort are clean, compact, and powerful.
Will you provide the filtering widget as a Javascript library? It looks really, really, really cool and could be extremely useful in many other web applications.
@cperessini Can we put the search field in the line above, between the tabs and the buttons? Does it really need a whole line? We're using up too much vertical space, so replacing all those filter buttons with a smaller filter field gives us an opportunity to save some space.
@markpundsack I believe in the next iteration of this there will be spoken of the fact if the tabs will still be necessary as they can be put in the search field as an operator. Example of an issue that comes close to this: https://gitlab.com/gitlab-org/gitlab-ce/issues/23540
@markpundsack@dimitrieh Saving some vertical space would be good, especially for the Issue Board. I think that the bar becomes overcrowded if we put the tabs, the search field and the other buttons in the same row, especially in smaller screens.
Once people get used to the new filters we could remove the tabs and include a default token for Open status. Editing the token would give easy access to the Closed filter and removing it would be the same as displaying All
@cperessini I vote for the second option ;) although the first option can of course have the position of the search bar change responsively in smaller screens to be under the tabs instead of next to
@cperessini I agree about the vertical space. As long as the filter bar is large enough for most common uses, this seems like a good idea.
On GitHub there exists a filter bar, but the Open and Closed options are still just 1 click away. I think that it might be poor design for commonly used filters to be hidden under a menu next to the more obscure ones.
Will the filter menu disappear each time an item is clicked? If so, would it be better to implement it as a new section that temporarily expands from under the filter bar when the user clicks the filter button or moves the mouse over an area? It could remain on screen until the user hits enter or clicks the filter button again. This would turn a potentially crammed 1 dimensional list into something much easier to visually organize. Related filters could be grouped and common filters could be promoted. The big disadvantage would be more screen realestate being temporarily used, so perhaps this is actually a step backwards.
Also, rather than removing the tabs completely, would it be useful to allow users to "sticky" certain saved/default filters as a tab? By default Open and Closed tabs could be provided, but the user could remove these and add new ones to better suit their workflow. I'm not necessarily advocating for this, but just throwing it out there as an option.
Great feedback! I am definitely on board with moving towards using less vertical space, and I want to make sure we don't forget about the ideas here.
However, in an effort to focus and scope this first iteration, let's keep it as currently designed on it's own row for now. There are a lot of details and micro-interactions that I want to ensure we get right. I'd rather make sure that we nail how the filter bar works first, and then refine the context it is in. If the work on the filter bar goes fast, and we are feeling really good about it, then we can move onto the work of reducing vertical real estate and rationalizing it with the controls around it. Thanks so much!
As chatted about earlier, maybe we return to the filter dropdowns once you have entered bulk edit by selecting an item? I also explored a few other changes to bulk edit to make the state more clear (the button clearly identifying how many issues you would change when you click it, and unselected issues being visually pushed back). Thoughts? @tauriedavis
I like how you included the number of issues in the update button! Pushing back unselected issues looks nice, so long as the contrast is enough to still read the info and be able to select them (I think the mockup needs more contrast). Maybe the New issue button should turn disabled when in edit mode? The two primary buttons right next to each other is a little strange.
I don't like greying out the unselected issues. How do I find next issue when its title is so hard to read? I like green background of selected issues, but please keep the unselected black.
Currently, the green background indicates today's issues, right? We use 'blue' to highlight comments in the issue thread. What if the moment you enter 'bulk edit' mode, highlighting today's issues are less important, and it is more useful to highlight selected issues with blue?
@tauriedavis: Thanks! Would it make sense to hide the new issue button when you are in the mode, or is that overkill?
That is much easier to read, nice @awhildy :)
As for the new issue button, I think it could go either way. I don't think it would be too overkill to just remove it while in bulk edit.
Thanks, @tauriedavis. Let's just remove the new issue button once you are in bulk edit mode. Removing the UX label now, but feel free to add it back if more questions come up. Really looking forward to this!
@ClemMakesApps: These are some tricky micro-interactions. I suspect things won't feel good if they move as I type, or any other point in mid-flow of completing a 'token'. My gut says that the moment you select the assignee and complete the 'token' is the time to clean up the ordering. I think it is the first case you suggest above (the dropdown opens below the assignee, with the test text before it), and once you complete with the dropdown, assignee shifts left. Does that seem alright?
Take a look at Github. It uses simple syntax without any interactive GUI. Just write the query and that's it.
Gitlab should use the same metaphore. Users are going to write a text to that text input. So the search box must behave like a text input in the first place. Text don't change as you write.
Any code-completetion popup must open exactly at the cursor. Just like any code-completion in any IDE.
When a word is replaced with graphical representation, it must stay exactly where user wrote it. The graphical representation of a word still must behave like the word. Moving stuff around will break backspace key (because the stuff to delete will run away) and it would be confusing. Another thing is that the query may have some structure not-understood by Gitlab, for example "milestone:v1.2 some keyword author:me" and then user adds and removes some details at the end of the query. If Gitlab mixes up the query string, user will have to search for the details when changing the query instead of having them at the end of the query (where he wrote them).
Therefore, if user writes "author:Jacob test assignee:Clement typing", then he must get the following search box and it must stay that way all the time until he changes it to something else.
Good points. I also agree with the concerns regarding the backspace key, @tauriedavis. Another argument in favor of this approach is that once we get to boolean operations, order matters (assuming these search keywords can be included in boolean operations). I am convinced that we should keep things in the order as entered, and not move them around.
In some ways, I'm now thinking that each element is a token, including these search keywords. But these search keywords don't have a recognized 'type' so they don't light up with the special UI and grey background that the other tokens do. But other than that, they all behave in the same way. cc @cperessini
@ClemMakesApps: I'm sorry about the bit of back and forth. This is a sort of feature where the subtle details really matter to get it right.
Instead of moving the tokens to the left, we've decided to leave them in the order they are written. There are some potential side-effects of this (user will not be able to highlight and select all the tokens + words properly, at least not in the first iteration) but we will review and address them in a future iteration.
Search will be invoked after the user hits the enter key. If a dropdown is opened, enter will select the highlighted row instead of invoking the search
This issue should be closed when the existing functionality developed so far is merged into master for 8.15. Future issues will be used to track subsequent iterations.
Per the Discussion meeting on Dec 30, @awhildy will work with @ClemMakesApps on finalizing scope for what to ship in 8.16 whilst in Mexico. @jschatz1 and @victorwu can dial in.
@awhildy@ClemMakesApps@victorwu why wait until Mexico to discuss this? Might as well do this remotely asap. After mexico the merge window is almost closed already.
However, last milestone, the conversation happened a little late as to what needed to happen for the feature to be shippable. Therefore, we just want to make sure to, as a team, reassess where we are in a weeks time towards our goals called out in that comment, and make a decision of what portion of this work will ship in 8.16. It just so happens that at the time we want to reassess, we will be in Mexico. We aren't really waiting for Mexico. At least, that is my understanding of where we are. @ClemMakesApps@victorwu - feel free to correct me
@jschatz1 said that @ClemMakesApps will be continuing to work on this once he returns from holiday vacations (which should be today according to the calendar).
@ClemMakesApps can you please provide a status on the work so we can work together to figure out next steps as soon as possible.
Thanks @ClemMakesApps . What is the proposed scope to ship for 8.16? Is it the cursor / autocomplete, as well as something for mobile? @cperessini : Do you have anything specific for mobile you would want for 8.16?
@victorwu given that the time frame is quite tight with mexico, my understanding is that we still needed the following 2 features for this to be ready for first iteration release:
Place the cursor and retrigger the autocomplete dropdown from different places in the search string
Filter using multiple words
The timeline is still pretty tight so I'm still not very confident we will be able to deliver this release.
Okay thanks @ClemMakesApps . Is there anything we can cut to get something released for 8.16 that you would be comfortable with? @awhildy / @cperessini : Are those 2 features necessary for shipping from your perspective?
I believe those two features we decided on so that we maintain the same level of functionality of what we have today. While I totally get that perspective, I'm also eager to get this out there so we can start getting feedback and iterate on it. 2. Filter using multiple words feels slightly more important to me than the other one, as without being able to filter using multiple words, there are some searches you can't complete (right?). The other feature means that if you want to change an earlier filter in your query, you have to delete some of your query to do so. This would be annoying, but not prohibitive. We would definitely get feedback about this, but if we were able to fix it shortly after (following release?), I'm ok with it.
Just to put a crazy idea out there, is there any sense in shipping this as the default experience, but with a fallback to toggle the old dropdown experience if you need to? That way we can get it out there, but have the fallback of the current experience. Could be a bit messy, and not worth it if that is a lot of work, but figured I'd put that idea out there in case it would help ship this.
Thanks @ClemMakesApps for all the work on this monster of a feature!!!
I fixed Filter using multiple words yesterday, so if that's okay scope wise, we should be able to merge it in for %8.16. That would make me feel the most comfortable as that gives me a little more time to write additional tests while we are in summit. I'm pretty sure we won't be able to make it in the release if we have to also do Place the cursor and retrigger the autocomplete dropdown from different places in the search string as it is actually quite complicated.
We currently have scores of milestones, but there is no filter on the Milestones page that allows to type in a partial name and filter out the milestones list in real time (similar to what we can do with project names). Is this already covered by this meta issue or do I need to create a new one? Seems like this filter should be a standard approach where you show a list that may have more just a few items.
Thanks @demisxbar! I totally agree with the suggestion. From a search perspective, though, I wonder if it is helpful for us to distinguish between searches of simple items vs. complex items. Issues and MRs are complex, with multiple things you can filter on (labels, author, assignee, milestone). Today you can filter Projects by name. It isn't a complex search, but it does a lot of what needs to be done. For Milestones (and I'd also add the Labels page), I think a simple ability to filter by name would get us the most bang for the buck.
I just installed GitLab 8.16 and stumbled across this issue and the new help (which looks great) but I'm missing the boolean-feature.
E.g. I want to search for issues without a specific label. It seems that there's some kind of not, :not:, - to trigger this but I can't get it working.
How can I "invert" search-parameters (without / not). Is it implemented yet?
@awhildy I agree. The search can be broken down into a simple and an advanced like you are describing. Both, will share a search field, but the advanced one would show a faceted filter to further refine the search results. Similar to Amazon.com, eBay.com and others. That would be my ideal way of searching.
@ClemMakesApps If you guys could please reuse the commonly known keywords for such operations that would be great. Ideally, copy them from Google/GitHub, so there is no new set for us to learn. For example, use - for exclusion instead of not, :not: and so forth.
@hardysim : The boolean operators are coming for the search, but not yet implemented. We are working hard on getting other more basic, higher priority features in at the moment. You can follow along here: https://gitlab.com/gitlab-org/gitlab-ce/issues/25913.
@winh@victorwu Issue #25913 (closed) has been closed in favor of this one however as Victor mentioned this issue here didn't seem to implement it. Thus it's really unclear what is the status of "boolean logic for the filter bar".
Could you clarify that? This is a really important feature i.m.o.