Reintroduce spotlight feature ("important traits")

[Manishearth]

I recently noticed that the "Important traits" feature (called "spotlight") was removed in #69514

The stated justification was a twitter poll, however from going through the responses there it seemed like people hadn't noticed it, not that people didn't find it useful. I don't think removing a feature is the right call if people aren't noticing it, that's a UX concern. It's also not that much code.

Can we reintroduce this UI as a little bubble on the return type? Putting it in the sidebar as a tiny circle was guaranteed to make it disappear. I found this feature quite useful, especially for iterators. In particular, my experience resonates with @Mark-Simulacrum's: #69514 (comment) you need to click, scroll to the iterator impl, and then compare pages and substitute return types, whereas here it's all in one place.

I think we have a good indication that we should experiment with the UI and find something that works.

Ultimately, even if a feature is useful for some and not most, we shouldn't be removing it unless it's a net negative impact on the "most", which is definitely not clear here.

(I kinda wish that removing this feature had been FCPd)

cc @GuillaumeGomez @kinnison @rust-lang/rustdoc

[Manishearth]

As far as the concern about the name "important traits" being confusing, we can perhaps call it "notable traits" or something

[hawkw]

For what it's worth, I think removing a potentially useful feature based on an informal Twitter poll where the posed question was not about removing it was a mistake. The questions "do you use $FEATURE?" and "should $FEATURE be removed?" are pretty disjunct: I would probably click "no" on a "do you use..." question for a solid 2/3rds of std, but I imagine some people probably use file I/O and would be pretty upset if it was removed.

This is especially harmful for features that might improve accessibility for new users — who are almost certainly the primary audience for "important traits".

An alternative interpretation of the Twitter poll cited as motivation for #69514 suggests that perhaps the spotlight icon should have been made more prominent:

[kinnison]

As I said on the PR, it ought to be moderately easy to revert if that's the consensus. Guillaume was annoyed at the code needed to support it, combined with people not understanding it, so I think that if we decide to revert (or reinstate in some other way) the feature, it needs to be better presented/documented, I simply don't know how to do that.

[Manishearth]

Honestly it doesn't seem like a lot of code to me.

We can easily better document it imo. That's a super minor barrier.

We should open a revert PR.

[Manishearth]

I feel like as a first step for better presentation, we can stick the little info bubble next to the return type

[Manishearth]

Made a PR reintroducing it: #74111

I still don't see where it's a lot of code.

[GuillaumeGomez]

The JS was a lot of code mostly. The feature as is is unclear and noisy.

[Mark-Simulacrum]

Taking the discussion here (from #74111 (comment)).

I see your point that it was somewhat hard to discover. I don't know why that's not a reason to explore the feature, though -- it seems like an argument against a particular implementation, I guess, but not the feature itself. I for one wouldn't mind exposing the details w/o a modal, e.g., on the next line after the feature. Manish already moved the info button to the return type which IMO makes it at least a good bit more discoverable.

I also don't really see the JS code as being all that sizeable? Manish's PR adds ~30 lines of JS code. That code looks like it wouldn't be needed if we were to always expose the information rather than sticking it in a modal, as well.

Anyway, like I said, the rustdoc team opted it.

I continue to find this concerning, as I do not see any decision about this from the rustdoc team -- the PR removing this feature clearly had support from you, but I don't personally think that can be said for the other members of the rustdoc team. Regardless, IMO, we should try to make such decisions through FCP to give community members time to respond to the team's consensus. It feels like this should be particularly true when their is some contention around the decision, which, in this case there is -- both Manish and I at least have noted that we find the feature very useful.

[Manishearth]

I do think moving forward removing a feature should have a visible FCP.