Universal coupler no longer "links" when text is selected

Bug Reports
1

Description of the bug
In 3.0.X versions of Supernotes (and perhaps before) selecting a piece of text and then activating the universal coupler (with /) would automatically enter the “link creation” panel. In 3.1.0 doing the same action now dumps you at the top-level of the coupler menu.

App & Version
macOS App v3.1.0

Steps to reproduce
Select a piece of text and type /.

Screenshots / Screen Recording
Not required.

2

This was actually deliberate alongside the introduction of the Move Coupler and wikilink syntax, as now there are realistically two different couplers you might want to access while selecting text.

And in fact we actually considered taking you directly into the Move Coupler instead, as the previous functionality can be had by selecting some text and then typing [[, which will bring up the inline card link coupler, which is an even faster flow for that use case.

3

I’d be fine with being taken directly to the Move Coupler (when there’s text selected), IFF the Inline Link Coupler created editable links (like the Universal Link Coupler does).

What’s the thinking behind creating non-editable links with the Inline Coupler? Why give the user two different outcomes for the same action (i.e. create a link)? Why create the mental and feature overhead of supporting two different types of links?

Perhaps I could understand it, if the new links were an improvement over the old ones. Then having both could be a temporary situation before you migrate all the old link types to the new one. But non-editable text doesn’t feel like an improvement—it feels like a massive step backwards. That’s why I don’t use the Inline Link Coupler, and have reverted to using the Universal Coupler.

4

The current behaviour with selected text and the Universal Coupler feels broken:

  1. The text doesn’t stay selected, so the user is dumped into the Universal Coupler without the context of what’s different (i.e. it’s difficult to understand why Move has appeared in the list)
  2. If the user gets confused by the menu and hits escape, the text they selected is now replaced with the / they typed
  3. If the user does choose Link, then the selected text isn’t copied to the search field in the Link Coupler, again leaving the user without context, and missing an opportunity to teach them how that field works
5

The non-editable card links are discussed a bit here, but to expand on that: we have had many people tell us in the past that they don’t really care about the aliasing ability of card links and care more about card link names being automatically updated when the linked-to card’s name is updated. So this was a bit of an A/B test to see what people actually think when that is the only option. So far the feedback (including yours here) has been “I still want aliasing”, so as @tobias said in the other thread we will be improving and homogenizing this in the near future.

And yep, those are reasonable points about the current behavior of the UC in light of these changes. We will improve that as well.

1 Like
6

Now that I think about it some more, I’m starting to understand why Supernotes supporting both aliased and non-aliased links could make sense.

If I’m linking within the body text of a notecard it’s not unusual that I rephrase the link title, so it makes sense within the context. Then I need the link to be an alias, which doesn’t automatically update. For example, I might link to a notecard titled Self-reflection using “if you don’t spend time self-reflecting.”

However, if I’m creating a bullet list of related links, then I’d usually want each one to exactly match the notecard titles, and to update when the linked title updates.

I’d guess that I’d use non-aliased links ~80-90% of the time and aliased links ~10-20% of the time.

1 Like
7

Same here.