Ranking by recency/context in the Command Prompts

One thread that links together several of my posts (see 1, 2 and 3) and requests is a worry about cluttering the various Parent/Link/Command Prompt (and also Tag) lists.

To put the thought out there, ‘better’ search and/or relevancy/recency ranking could help mitigate this concern substantially. ‘Sufficiently intelligent search’ certainly isn’t a panacea and can sometimes be an anti-pattern (I would much prefer explicit unindex to just trying to ‘magic it away with search’), That said, it can make a huge difference prior to manual optimization by a user.

Right now the reason why I’m interested in a keyboard shortcut for home and up/down is because the search doesn’t prioritize Home when I type ‘Cmd+K → H’ and doesn’t put the parents and children of the current note high up in the Command Prompt. If the typeaheads and search were ‘smarter’ and did that, I might just use those all the time instead.

Algolia is probably not a fit here, but it’s historically had support for ranking based on recent, context, user behaviour, demographic, etc…

There’s no need to go that far, recency (like fasd) and context (parent/child) might be enough to make a huge dent here and make it far less concerning to have cards like ‘Tasks 07/2020’, ‘Tasks 08/2020’, where currently you have no idea whether the current or past versions will be prioritized in search.

I appreciate that I’m proposing what could be a fair amount of work — and I’m sure that you had something around ranking in mind on your roadmap already — but hopefully this is some useful material and food for thought at least. :slight_smile:

Great suggestion @tekacs. We will be improving the Command Prompt in a future update, whereby commands will generally always be the first results, even in the case of an exact match. So if you had a card called “Go Home” it would rank below the command called “Go Home”.

As another consideration (I should actually make a poll for this somewhere) – we have wanted to make keyboard shortcuts for everything on the platform for a while now, where for example you can just press [h] to go home.

However, we really like the “type to create a new card” functionality, which obviously conflicts with the above.

We are still trying to figure out how the UX can suit the most people and their needs without being clunky / confusing.

1 Like

Related use-case here: Hiding archived and junked cards from search + command prompt

The command prompt has been overhauled to be the Universal Search in 2.4.0. Universal search contains a recency ranker and more improvements to make the search more relevant and reliable. Marking this as implemented :tada:

I’d definitely love modal keyboard shortcuts.One complaint theme that constantly surfaces around this forum is the clunkiness/friction/too many clicks required to activate any action (ie adding parent, removing parents, tagging, etc). Those would all have their unique bindings.

My own complaints about the multi-select feature, that

  1. It is impossible to select non contiguous notes with keyboard

  2. That it takes too many submenus to do anything in multi edit

Could be greatly improved with dedicated bindings for each type of action (ie with cards activated in navigation mode, X selects a it. Then one could navigate, say two cards bellow, and select it. Then press T to tag them both, then press P to add/remove parents, etc. this would need a separate active vs selected state for cards, but it is pretty common. See gmail

Another thread I’ve seen in the feature requests is the desire for a more seamless editing/reading experience. The founders have themselves discussed the issue and wondered whether to keep the dual mode nature of SN.

One advantage of having a modal app with distinct edit/read modes is precisely having different bindings/commands for each mode. This advantage is squandered right now, as all keys just create a new card. I mean, how hard would it be to bind N to create a new card and instantly free numerous new possibilities?

Right now supernotes feels like it has the worst of both worlds: the disconnect between the modes, with the increased cognitive overhead and complication but without the benefit of more plentiful and more adapted commands/bindings to each mode, all so that we can have more than 60 bindings to a single command(create a new note that uses all keys plus all keys with the shift modifier)