hayden.moe
Currently, Tangled uses a setup where you have ?state=open or ?state=closed and then also a search string when filtering issues.
I'd like to suggest adding a series of tags (is:, author:, and label:) that would move those filters to the search string.
Examples:
tangled.org
is:open (all open issues)is:closed (all closed issues)is:open author:hayden.moe proposalis:closed knotserverI think it'd make filtering issues a fair bit easier.
Thank you for very detailed research, I like the overall approach!
We can start from raw, uncolored search query input box and then ship optional syntax highlighting and drop-down with JS. Adding more fields to IssueSearchOptions and implementing our own query parser would be a good place to start.
Provide an old-school "advanced search" page for no-JS users to select all the key/value parameters they want using traditional HTML form elements
I'm curious how would it work.
octet-stream.net
boltless.me
state:open but state="closed" from form.and other nits:
author: already represents the user, we can omit the @ sign. It is used for rendering/markdown anyways.author:did:plc:.....? would that even make sense? I wonder how you think about this.Re: advanced search - I'm not sure if I have a good example since they've gone out of fashion, but I'm thinking of a full separate page whose entire purpose is to construct a query. All the key-value pairs get their own combobox plus there's a textfield for normal keywords. When you click Search the server would then construct a query string from those form elements and redirect you back to the issues (or pulls) page with that query applied. The primary purpose here is to expose all the values that would normally be accessible via dropdown autocomplete to a user who isn't using JS. I suppose if the user also typed some key:value entries in the keywords box they could take precedence over the form elements but it's an edge case.
Re: author - agreed, let's drop the @. IMO as a user-facing element there is little value in supporting DIDs. There's nothing to stop us adding that later if it turned out to be useful.
Thanks for the feedback!
@octet-stream.net ah I got it. How about implementing both on same page then?
textfield + combobox, key:value syntax is still supported but won't provide syntax highlighting and preferred to use dedicated query params instead:
?q=keyword+keyword+keyword
&state=open
So basically same to how current search interface works.
combobox now doesn't work as form input field but JS-driven query builder. We can collapse or hide them in this case.
clicking label from combobox will append label:good-first-issue in search query. Dedicated query params like &state=open will still be supported, but not preferred:
?q=state:open+keyword+keyword+keyword
And from api, query params will always prioritized over key:value queries.
This way, appview can provide unified interface, and we don't need to maintain dedicated search page. We can share most elements and change their behavior based on JS.
I've done some research across several existing implementationsβGitHub, SourceGraph, GitLab, ForΔejoβand have a proposal for how we tackle this.
General notes
GitHub
Textfield with dropdown
Client-side validation
GitHub search uses a relatively normal text field where
key:valueitems are treated differently from regular search keywords. It provides obvious and explicit UI menus for adding common filters. Many others are only accessible by typing them explicitly. There is a JS-driven autocomplete drop-down when you focus the textfield that walks you through configuring all available filters. When it detects you're typing akey:value, keys are autocompleted by typing from the left; values are autocompleted by matching anywhere within the text.-key:valueis used for negation, which is recognisable from search engines and tidy. Unfortunately because any typed tag could be a negation, it is difficult to filter out the repeated use of a tag that is nonsensical, e.g., two issue authors. The autocomplete dropdown is sophisticated and intuitive and there is client-side validation if the current filter state doesn't make sense.Sourcegraph
Search textfield with blocks
Similar to GitHub except that the textfield is much more stylised and
key:valuepairs become represented as coloured rectangles that are single entity. This enables more efficient editing, e.g. press backspace once to clear a particularkey:valuefilter. They have a sophisticated drop-down, but also a bunch of examples on their search page and lists of values you can filter on. Their product is extremely code-search-centric so it makes sense that they spend a lot of UI complexity on making this as discoverable and efficient as possible.Gitlab
Textfield with dropdown
Value autocomplete
Gitlab presents a textfield-like search interface but it parses it locally into specific key-value pairs in its query string. Instead of plain text, your
key:valuesettings are represented visually as special blocks:key,=or!=,value. An autocomplete dropdown is again used to help guide your tag selection. I find editing the "rendered" values to be quite fiddly and unintuitive vs. a plain text field.ForΔejo
Issue search interface
Like Tangled, issues and pulls are separate. Unlike all the other products considered here, non-keyword filters (label, author, etc.) are kept out of the search bar. I don't like this much at allβwhen you're looking at a page of results there is essentially no feedback about what combination of filters are in effect. You have to click on drop-downs and go scrolling to see what's selected. They have implemented some fancy selection logic, e.g. author allows only one selection; meanwhile labels can be grouped such that certain subsets of labels can only have one selected, and this is enforced in the search filter. Oddly, typing multiple keywords seems to be an OR rather than an AND? Overall, not a fan.
Conclusions
A search box containing all filter context and keywords is a solid base to start from, with leading
-for negation.key:valuetags or regex etc. laterThese tags could be easily supported as a starting point:
state:openstate:closedstate:mergedauthor:@handlelabel:good-first-issueWhat could we do better than GitHub?
One of the things that is great about Tangled is how it tries to be uniquely better than existing code forges. So how could we innovate here?
Proposed execution