Open Bug 1647901 Opened 1 year ago Updated 1 year ago

Evaluate supporting tab-to-complete for a partially-typed alias

Categories

(Firefox :: Address Bar, enhancement, P3)

enhancement
Points:
3

Tracking

()

People

(Reporter: harry, Unassigned)

References

Details

(Keywords: blocked-ux)

Attachments

(1 obsolete file)

This is so the user can use the muscle memory they will develop around tab-to-search with token aliases.

Severity: -- → S3
Priority: -- → P2
Blocks: 1647921
No longer blocks: urlbar-searchshortcuts
See Also: → 1657676

Lowering priority since this is more relevant for tab-to-search, which will be done later.

Priority: P2 → P3
Priority: P3 → P2

It sounds like this would be good for ebay, where we'd never provide tab to search due to the "rover" situation.

what is blocked-ux here?

Flags: needinfo?(htwyford)

Whether we want to show tab-to-show results for token aliases at all, and what that would look like. There are some edge cases here that might not look great visually. For example, if the token alias is being autofilled, do we show the autofill keywordoffer result as the heuristic and then a tab-to-search result for the same engine right underneath? Or should we just allow Tab/down arrow to complete token alias autofill?

Flags: needinfo?(htwyford)

I thought the purpose here was when the user types "e" to match on "@ebay", or "dd" on "@ddg" to provide the tab-to-search.
If the user is already typing an alias like "@e", it doesn't seem useful to provide a tab to search result, that's about discoverability and the user doesn't need it since they are already typing the alias.

Ah! That makes sense. Yeah, I think we could just go ahead with that without specification from UX.

Keywords: blocked-ux
Assignee: nobody → htwyford
Status: NEW → ASSIGNED
Iteration: --- → 83.2 - Oct 5 - Oct 18

I spoke with Verdi about this. He is concerned that we'd show tab-to-search much too frequently with this behaviour enabled. In en-US, we have six installed keywords by default: @google, @amazon, @bing, @ddg/@duckduckgo, @ebay, and @wikipedia. If we implement this behaviour, we would show an extra result and an extra animation every time a user starts a search with g, a, b, d, e, or w.

I made the case that we want to support muscle memory that will develop around tab-to-search. We agreed that we would de-prioritize this bug and come back to it after tab-to-search has been in wide use for a bit.

I'll post the rough WIP patch I was working on for this.

Assignee: htwyford → nobody
Status: ASSIGNED → NEW
Iteration: 83.2 - Oct 5 - Oct 18 → ---
Priority: P2 → P3
Attachment #9179311 - Attachment is obsolete: true

Returning on my comment 6, I missed a use case and today I added an item to the UX agenda to discuss this behavior.
It could make sense to fill @tokens with Tab in the end, since we are introducing Tab to search, and this would be a case where the intent is clearly to search but tab doesn't complete.

Depends on: 1669526

So, this bug tracks partially typed aliases, while Bug 1669526 tracks partially typed token aliases (the ones starting with @).
It's likely Bug 1669526 will be fixed sooner, this one is still blocked-ux because there's concerns of autofilling too often.

Keywords: blocked-ux
Summary: Evaluate supporting tab-to-complete for a partially-typed token alias → Evaluate supporting tab-to-complete for a partially-typed alias
Blocks: urlbar-update-2-follow-ups
No longer blocks: 1647921
See Also: → 1516110
You need to log in before you can comment on or make changes to this bug.