This is sort of what I was thinking about for the "Search Description" / "Usage Hint" (descriptions / projects are random examples):

(You could write some similar rules if you want to try something in that vein, although it's a pretty big pain to fork JS/CSS right now.)

I should make a Herald rule to auto-resign.

Okay well @chad resigned from D16893 as soon as he saw animation in a CSS file so I don't think that one's going anywhere.

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

Ah, thanks! I've asked downstream if anyone still runs into any issues, but so far I also believe this is now resolved.

Alright, I'm going to try this:

The most-likely-to-work secret magic for "Not in: Wikidata" is not(wikidata):

phabricator.wikimedia.org is running a version including these changes plus D16886 on top. So far it looks like a great improvement!

+1 to what 20after4 wrote. The approach is definitely helpful, and to make this look less cluttered and inconsistent ("are projects with longer descriptions which take up more vertical space somehow more important?"), cutting off project descriptions seems like a good compromise.

I caught another case of this: here, "Phacility" should be first, but is not.

In T11034#199653, @epriestley wrote:

---

Now that this has been deployed for a while, I'm curious if there's any feedback about it? Specifically:

• Does this approach generally seem like it's a reasonable solution to the problem (if not in its current form, in some similar form which handles these issues more gracefully)? Or are we not really in the right ballpark?

I suppose an alternate path is to enable Dashboards on Project homepages, and you can embed your project wiki or text panel for a really cool long description and information.

Would you fill out at least, like, 5 of them?

Hovercards, Search, Browse, etc. It could get used.

We could call it "Search Description" so it feels clear that it only displays in some UIs.

Yeah, I think it's pretty reasonable if people would actually fill it out. We could surface it in a few other places too (e.g., /projects/) without fallback. It just seems like there's a decent chance no one will ever fill it out and it will sort of just be cluttering up the UI. But the cost on our side is pretty small, so if some people claim that they'd probably want to fill it out I'm happy to move forward with it.

Provide an alternate, text-only field for "Project summary in typehaead results." which users only enter text into, so we don't have to worry about remarkup.

For reference, here's the current state of "discovery" downstream:

This would be nice to have but is somewhat involved:

In T11034#186209, @epriestley wrote:

The dialog can be resized by dragging the lower right corner.

What about show only active projects in "Browse projects" window?

Hello! What about show only active projects in "Browse projects" window?

Can you file a new bug with reproduction instructions? That isn't expected.

Somewhat related to type-ahead:

Is there a task open that will move archived projects to the end of the type-ahead list?

Yeah; I have a few times implemented a type-ahead system in the past where the already-present options are shown at the bottom to allow better accessibility for moving tags around in the list (e.g. for people that can't drag things), so that might be a better solution anyway.

You can test with "Discovery" at https://phabricator.wikimedia.org/

Almanac Blueprints aren't mentioned downstream but I think are also a fairly good fit for this:

Yeah, I don't think this helps at all if there are 50 results, but I don't think we can do anything about that. Better solution is to fix the workflow somehow (nuance, subprojects, etc).

The original use case on the downstream task (https://phabricator.wikimedia.org/T234) was this:

I can remember trying to file a bug against Safari when I worked at Apple, seems like a simple task. But typing "Safari" came back with 50-100 tags... I had no clue as a first time filer what to fill out. A short description might have helped, perhaps. But overall I guess I'd like to understand what users are ending up at the browse dialog to begin with. In the Safari case, having something like Nuance is better for the novice user than asking them to wade through 50 results and guess the correct one. I want to basically make sure we understand which user we're helping here.

I think users are probably mostly only using this UI to browse things anyway, so it's likely OK to "slow it down" a bit visually, since that could make it easier to navigate if we save users from needing to go look up information in a new window.

I worry overall that this will compound the issue when installs have too many projects. That is, if they already have hundreds/thousands of projects, doubling the information makes the UI twice as large and difficult to navigate through. Maybe one idea would be to only show additional information optionally (via a checkbox) or only after results start to get filtered?

Please unassign me from this task (why can't I do it myself?). My patch was rejected.

In T10163#154382, @epriestley wrote:

• D15039: Two effects:
  • If you finish typing a word (e.g., type a space) and there are no results, deactivate since nothing else you could type could possibly cause matches and you're probably not fishing around since you just hit space.

Yeah, it feels a bit like the "baby's first typeahead" button to me (since it didn't exist for so long, and is usually useless if you know what you're going to select) and it usually takes me a minute to remember it's there.

FWIW I don't think I had clicked on since first testing out typeahead and had come to associate it with "this is a magic typeahead box" not "click for more options".

Here's a workaround:

I think I can fix that. The current assumption is that the wrap is the result of multiple words:

Feel free to say no... but if you start an @ at the edge of the remarkup box, the text will move to the newline but the box won't.

I'm not planning to touch all the cases like ` #x, {nav #x, ``` #x, %%% #x, etc. We don't have a client-side Remarkup parser and I'm not planning to build one for this. See T3725#39466 for some earlier discussion.

This currently triggers autocomplete, but probably shouldn't: ` #f.

The only issue that I've noticed so far is that @{article: triggers the autocomplete, whereas it probably should not.

The most recent ruleset seems to be working pretty well for me. It hasn't been spazzing out and popping up all over the place, but has been there the couple of times I actually wanted it.

haha no idea, this arose from a product discussion about how project tags will render when there are 16 levels.

wait how do I get @epriestley points

are you kidding me, I spent all my @epriestley points on this as is.

Is there any intention to add support for auto-complete when typing like "T1234" or "D1234"? That would help immensely with instances that have a large number of tasks or diffs. I know there's been a few times on this instance where I've wanted to refer to diffs in task comments, but I can't remember the number perfectly so I have to open a Maniphest search to try and guess what number it was. Having it in the typeahead with the task / revision title would mean I don't need to spend time doing that.

From D15029:

ǝɯ ɹoɟ sʞɹoʍ ʎǝlʇsǝᴉɹdǝ@

In T10163#154399, @joshuaspence wrote:

Is it expected that this doesn't work on mobile?

In T10163#154399, @joshuaspence wrote:

Is it expected that this doesn't work on mobile?

Is it expected that this doesn't work on mobile?

In the case of 1 match, we now hide if there's one match and it's exactly what you typed.

I think that's what I intended to describe - hadn't considered if there was a single match but wasn't exactly what was typed. Thanks.

In T10163#154334, @cspeckmim wrote:

I like that idea. Should it also hide if there are 0-1 matches? When mentioning users with short usernames or project names it's often faster to just type, @chad, @cspeck, #enad, etc.

Okay, all that stuff is live now too.

Yeah I'm finding implementation mixed at various sites.

I didn't do that because I don't think a space is universal -- I've seen ":" and ",", particularly.

I sort of expect it to also place a space for me after selecting the correct object.

That word stuff still has some weird/buggy results, I'll see if I can improve the behavior.

Alright, all that stuff is hopefully fixed/improved now: