Jump to content

Better support for native app x-callbacks/deeplinks?


Recommended Posts

With Catalyst apps and the rising popularity of native app deeplinking on the Mac, it seems like Alfred could better support routing x-callbacks or deeplinks directly to the corresponding native apps, rather than going through a browser first.

 

Specifically, in Open URL workflow objects — rather than assuming that a browser is necessary — routing to a browser could be offered as an option that is enabled.

 

The current still works, but it seems like Alfred should anticipate this change and get in front of it...

 

image.thumb.png.c521e1bd067100c581a2b8437a2c7251.png

 

Link to comment
Share on other sites

6 hours ago, Chris Messina said:

Specifically, in Open URL workflow objects — rather than assuming that a browser is necessary — routing to a browser could be offered as an option that is enabled.

 

You misunderstand: "Default Browser" means "default application for the given URL scheme". Alfred just passes the URL to macOS to open. The URL is only sent to a specific application if you choose a specific application.

 

It’s functionally equivalent to calling /usr/bin/open "scheme://blah" vs /usr/bin/open "scheme://blah" -a SomeApplication and already works the way you describe.

Edited by deanishe
Link to comment
Share on other sites

10 hours ago, deanishe said:

Alfred just passes the URL to macOS to open. The URL is only sent to a specific application if you choose a specific application.

 

I see, you're right!

 

Perhaps it's a matter of improving the UI? Because it looks like it'll open in a browser by default, rather than letting macOS route the request to the corresponding app directly.

 

Maybe this should be called "Default browser opener override" (or something more elegant) since the default behavior is actually NOT to open in the default browser set in System Preference's General pane (unless it's a web address), but to instead open it with the app that supports the designated scheme (e.g. craftdocs://).

 512877630_CleanShot2021-02-03at12_40.37@2x.thumb.png.b8c15b06f22dc7b2ab77bb616042674d.png

Link to comment
Share on other sites

In case anyone wants to really get nuts with fine-tuned URL scheme management, I suggest checking out Finicky. It's up on GitHub:
https://github.com/johnste/finicky
 

It lets you route URLs to different apps using rule-based logic. So you could make URLs containing *.google.com open in Chrome, and still keep Firefox as your default browser (example).

Link to comment
Share on other sites

On 2/3/2021 at 9:43 PM, Chris Messina said:

Because it looks like it'll open in a browser by default, rather than letting macOS route the request to the corresponding app directly.

 

It does, but I think this is probably for the best. You're right that the description isn't particularly accurate, but it is easy to understand. I'm not sure if changing the description to talk about URI schemes and handlers wouldn't confuse more people than it enlightened.

 

AFAIK, nobody has ever actually had an issue with this. Your post is based on having read the docs, but not actually used the feature, which is the opposite of how most people go about these things.

Link to comment
Share on other sites

9 hours ago, deanishe said:

Your post is based on having read the docs, but not actually used the feature, which is the opposite of how most people go about these things.

 

I don't understand this statement.

 

I was literally trying to use the feature when I encountered this limitation... I wanted to use craftdocs:// as the URL scheme and set the "opener" to Craft (i.e. not a browser). 

 

I assumed (since this has been the case in the past) that the browser would first attempt to open the URL, but then detecting an unfamiliar URL scheme, would hand off to the OS. I just wanted to skip the browser being in the middle of the request to speed things up.

 

 

Link to comment
Share on other sites

No, the OS handles it (via LaunchServices), and sends it to the registered app for the URL type.  You can test this by typing craftdocs:// into Alfred and then into Safari - when you call it directly from Alfred the app opens straight away, when you call it from Safari, you need to confirm that you want to allow a web page to open the app.

 

More details here: https://kaihao.dev/posts/Make-your-own-custom-URI-scheme-resolver

 

Link to comment
Share on other sites

8 hours ago, Chris Messina said:

Exactly — which is why I was pointing out that the Alfred UI isn't entirely accurate. 


Seems to me that what you’re pointing out is that Apple’s UI isn’t accurate. That “Default web browser” is the same thing.

 

Alfred can follow macOS’ example or deviate from it. Considering this is the first time I recall this being an issue on these forums, it seems that not deviating has worked out fine, and changing that to another option not used anywhere else is opening the door to confusion.

 

You should consider mentioning it to Apple via Feedback Assistant. If they change it, I’d see a bigger argument for Alfred to follow.

 

But I don’t think they will, and that you’re thinking too narrowly. As a fellow designer, you seem to me to be stuck in a bubble of theoretical design and repeatedly missing the necessary practical decisions of software. UI is the least of the world’s software design problems.

 

In math class, one is taught negative numbers don’t exist, or that fractional numbers don’t exist, or that the square root of a negative number doesn’t exist—until they reveal those to be lies. But those lies are told so you don’t get confused; they limit your view of what’s possible to your understanding of the world and avoid you getting overwhelmed.

 

”Default web browser” is the same kind of lie. It’s clear for the overwhelming majority of cases, and if you’re the type of person who needs to know the exceptions (what it really does), a one-line sentence clarifies it for life.

 

In sum, you’re arguing for a change that is no longer relevant to you and that can make Alfred more confusing to everyone who’ll never need to know what you now do (most people). That’s impractical, and bad software design.

Edited by vitor
Link to comment
Share on other sites

5 hours ago, vitor said:

As a fellow designer, you seem to me to be stuck in a bubble of theoretical design and repeatedly missing the necessary practical decisions of software. UI is the least of the world’s software design problems

 

On behalf of the thousands of UI designers upon whom the world depends, I take umbrage with characterizing UI design as the least of the world's software design problems.

 

But I will otherwise ignore it because it is irrelevant to my original point, which was about the "truth" in the interface, which you seem willing to accept as a "lie" for "practical" reasons, which is your wont to do.

 

I prefer to stay stuck in my theoretical bubble if it allows me to pursue increasing honest or accuracy with the users of software that I design or contribute to.

 

 

5 hours ago, vitor said:

In sum, you’re arguing for a change that is no longer relevant to you and that can make Alfred more confusing to everyone who’ll never need to know what you now do (most people). That’s impractical, and bad software design.

 

On the contrary, I am interested in expanding the use cases and generative outcomes that users of Alfred perceive based on the accuracy of its interface.

 

That Apple hasn't made this shift in the General preference pane doesn't mean that Alfred wouldn't benefit its users by indicating that routing via URL schemes is an increasingly common pattern, and that URL schemes may be handled by native apps and not just "web browsers".

 

A more compelling argument (that would take into consideration your metaphorical "negative numbers") would be that all apps should now and forever forth be considered "browsers" because any app can register one or more URL schemes into LaunchServices and thus can be refined according to the previous paradigm without disrupting it. This is more akin to expanding the set of "counting numbers" to the set of all "real numbers", which is more inclusive and still as accurate.

 

--

 

Regardless, if you didn't like my proposal, you could have just plainly said so without disparaging me as a "fellow designer".

Link to comment
Share on other sites

1 hour ago, Chris Messina said:

Regardless, if you didn't like my proposal, you could have just plainly said so without disparaging me as a "fellow designer".

 

I thought we had interacted enough that you’d understand I’m not speaking in bad faith, nor do I have any interest in insulting you. In my view you have positive intentions and are well-meaning, but often lack context. My goal was to bridge the gap between what you’re saying and what has already been said to you. Alas, you took offence with points I find innocuous, so I won’t try to discuss this issue further and risk making it worse. I take no pleasure in annoying people.

 

I will make two points on design, as an individual and a designer, which are my views and don’t necessarily mirror the views of anyone on Alfred’s community or Alfred’s team.

 

  1. You misunderstood my point. I didn’t say UI design isn’t important for software. Rather, everything else is in worse shape and needs more attention.
  2. The world doesn’t “depend” on UI designers, because it doesn’t depend on Facebook or most of the companies where UI designers work. Where UI design could make the biggest dent in the world (like hospital software or heavy machinery) is where it’s valued less by the people with decision power. The best paid design minds are trying to sell us toothpaste, not changing the world. I expect you disagree (and I don’t include you in the toothpaste sellers; designing for open-source is important), but it should make clear where our views on design differ.

 

Either way, I do apologise for having irked you.

Link to comment
Share on other sites

On 2/6/2021 at 1:55 AM, Chris Messina said:

I don't understand this statement.

 

This is what I mean:

 

On 2/6/2021 at 1:55 AM, Chris Messina said:

I was literally trying to use the feature when I encountered this limitation... I wanted to use craftdocs:// as the URL scheme and set the "opener" to Craft (i.e. not a browser). 

 

I assumed (since this has been the case in the past) that the browser would first attempt to open the URL, but then detecting an unfamiliar URL scheme, would hand off to the OS. I just wanted to skip the browser being in the middle of the request to speed things up.

 

There is no limitation. craftdocs:// would have Just Worked if you'd left it set to "Default Browser". You considered the UI, formed an incorrect mental model about the way it works, and then came to post a feature request for the way it already works.

 

That's not unusual, but it is the first time it's happened for this feature. People have been putting non-HTTP URIs in that box for a decade without apparent confusion, which suggests to me that—even if it is technically incorrect—the dialog fits most people's mental model of "opening URLs on macOS" very, very well.

 

Link to comment
Share on other sites

31 minutes ago, vitor said:

Either way, I do apologise for having irked you.

 

I do have positive intentions and am well-meaning, but have a different perspective than what seems to be the dominant perspective on this board.

 

My priorities or sensitivities aren't the same as everyone else's here, and so I give voice to them because I think Alfred (and similar software) can be a net-good for helping people use technology more effectively, and in a personalized way. But by holding minority viewpoints, I find that many of my well-meaning suggestions are more quickly shot down rather than being met with curiosity, credulity, or interest.

 

Rather than amplifying the merits of my contributions, it feels like I am often criticized (if not directly, somewhat obliquely) as being ignorant of some deeper held awareness that only the longest serving mods on this board have.

 

Like, I'm trying to imagine saying to you, in response to an idea that you just shared, that "you seem to me to be stuck in a bubble of theoretical design and repeatedly missing the necessary practical decisions of software".

 

I'm willing to believe that you intended this constructively, but instead it sounds like a clergyman chiding a choir boy, especially in the context of the many other rebuttals I've received — the definition of patronizing.

 

Had I made that statement towards you, would you have received it differently?

 

Now, it's perfectly possible that I have bad ideas, or that my ideas are irrelevant to the denizens of this board. But as I believe I have stated previously, one of my desires is to expand the use of Alfred by other people — people who are likely not well represented on this forum — because I believe Alfred is a fantastic piece of software, which can also be made better. But I've also had enough experience in my years in the open source world and elsewhere to recognize when my contributions are likely misplaced and it's I should find or create a more receptive environment for my advocacy.

 

For example, I remember back in 2005 I advocated that Drupal use a new technology called "AJAX" to make its interface more responsive and thus easier to use. But the core maintainers rejected my proposals. Years later, and after Drupal finally realized it needed to modernize in order to keep up, the maintainer who had most strenuously fought against my position acknowledged that he had been myopic and unwilling to listen to me and that, ultimately, he had been wrong. I had long since moved on, but it's possible that had the Drupal community been more open to divergent input (not specifically from me, but from less dogmatic/ideological users), it may have lead to a faster adoption of Drupal, and thus a greater impact on the world.

 

And so there's no confusion: I'm not comparing your comments with that Drupal maintainer's. I'm not suggesting that this slight suggestion about "browsers" is similar to Drupal resisting JavaScript. Instead, I'm observing that my most productive engagements are the ones in which there's a collaborative spirit of leaning towards new ideas and suggestions, even if they need adjustment, or even if they might not make the cut. I don't mind facing the headwinds of criticism and doubt, but when my suggestions seem to be belittled, or when my capacity as a designer, again, is seemingly questioned or diminished, it makes me wonder if the underlying, true, message is that my contributions are actually not welcome and should be taken elsewhere.

 

Link to comment
Share on other sites

23 minutes ago, Chris Messina said:

it makes me wonder if the underlying, true, message is that my contributions are actually not welcome and should be taken elsewhere.

 

I certainly wouldn't say that, and it's certainly not my goal to drive you off. This all seems to have got a bit out of hand.

Link to comment
Share on other sites

1 hour ago, Chris Messina said:

Had I made that statement towards you, would you have received it differently?

 

I have a rule for internet communication (honed over a decade of maintaining a popular open-source project): assume good intentions. Unless someone is unambiguously rude, I act as if they were nice. Similarly, I avoid writing when I’m not calm.

 

I know I didn’t intend to be rude—quite the contrary, I was trying to convey “approach these differently”—but rereading I understand it can be taken that way.

Link to comment
Share on other sites

1 hour ago, deanishe said:

it's certainly not my goal to drive you off. This all seems to have got a bit out of hand.

 

Generally I believe that none of you want to drive me off, and so I'm just not sure if there's a lack of awareness about tone/emphasis or if I just feel like my suggestions are met with more friction here than I receive elsewhere. 

 

In service of uncovering the best ideas and most inclusive implementations of those ideas, I welcome and solicit good faith criticism, debate, and skepticism (preferably curiosity).

 

I'm just left feeling that several topics that I've kicked off as rather banal/trivial/straightforward suggestions to improve Alfred are met with a wall criticism about why my interpretation or experience with the problem, which I'm offering a solution to solve, is at base, flawed. 

 

From my view, a superior outcome to this current conversation, for example, would be to say, "ah yes Chris, that's an interesting observation you've made. Yes, I can see why you'd want to be able to select a native non-browser app that can handle URL schemes in this interface, but for the sake of historical consistency — and given that the behavior you're pursuing is actually already how this works at the OS level — while your proposal would make this interface more accurate, the net-net of it is that's probably not worth prioritizing for now."

 

In this formulation, my good intention is acknowledged, expressed to me in a way that I feel understood and heard, feel like due consideration is given to what I've proposed, and given a satisfying response that while this idea is reasonable, it's unlikely to be prioritized.

 

I can live with that. I can move on and not feel belittled. And I'll have confidence to come back and share other ideas — any of which that might actually be worthy to pursue imminently.

 

Do you see the difference between the response I received and what I would have been satisfied by?

Link to comment
Share on other sites

3 hours ago, Chris Messina said:

and so I'm just not sure if there's a lack of awareness about tone/emphasis or if I just feel like my suggestions are met with more friction here than I receive elsewhere. 

 

I’d say the issue might be the amount of back and forth. There are three Alfred veterans trying to help on this thread (and in your others, there were multiple as well). In general, one of us is enough and the others move on to help someone else or only make a small comment for completeness. But since you continue to argue back (not a criticism), the others will try to further clarify the points already made and fill any gaps, which makes it so you have more people to respond to (while we still only have one each—you).

 

3 hours ago, Chris Messina said:

Do you see the difference between the response I received and what I would have been satisfied by?

 

Yes, but to be honest the example answer you gave is to me the one which feels patronising. It’s essentially what’s already been said but with a “good job, here’s a cookie” in there. I wouldn’t enjoy receiving it, and I wouldn’t feel genuine giving it unless I were truly impressed by the idea (admittedly a high bar). It may have made sense to make such a comment at the start of the conversation, but I entered late into it—when specifics are what matter.

 

Frankly, I need to be direct to be efficient because I assist a crap ton of people daily, both here and on Homebrew Cask plus other projects. The vast majority of people I interact with in this manner find it perfectly fine, so I know it works for me.

 

Everyone has their style, so perhaps ours clash. I’ll pay attention on the next chance we have to interact, and perhaps deliberately pass on it. Again, I understand how you may have found my comment insulting (and I apologise for that) but I expected the previous rapport to have made it less probable to have been interpreted as such, not more.

 

Surely none of us imagined we’d spend so much of a Sunday discussing this. I understand and accept your side of it. I expect you accept mine. Have a great week!

Link to comment
Share on other sites

I love this discussion minus the part where @Chris Messina felt unwelcome. From my limited interactions with @deanishe and @vitor I feel damn confident that no one on this thread means to attack / argue in bad faith with anyone.

 

MacOS settings:

I don't agree with the thesis that Apple's "Default Web Browser" setting is misleading or incomplete. "Web" implies http(s), no? I don't see any ambiguity there. Apple is saying "choose an app to open http(s) urls". It is just that for all other URL schemes, Apple hasn't provided a UI. But whatever UI is present, it is precise, and complete. It claims to be about "web" and it is.

 

Alfred:

Reading the text for the "Open URL" object, image.thumb.png.d3456f87ea15329de802eeadc98e8b53.pngpresence of terms like "website's search URL" and example of twitter, I feel like there's a possibility that the original design intent behind the "Open URL" object was exclusively for http(s) URLs. The copy certainly reads like that. Another reason for me to believe so is the fact that it is grouped together with "Default *Web* Search".

image.png.0ce9a4c0d4802e003b9add4b595522b3.png

To my eyes, being able to open other URL schemes with this workflow object seems like a case of "it is possible due to particular implementation details".

 

As @vitor has correctly pointed out, terms "Browser" or "Default Browser" are a bit of a lie.
Imagine the user (workflow user who has opened the object out of curiosity) experience:

- User sees that the URL is "craft://..."
- Browser is "[firefox icon] Default Browser"

- User rightly concludes that it'll open a firefox tab/window and the address bar will have "craft://..."

- User concluded wrong

- When workflow runs, craft app is opened

 

As a user, I don't like such surprises. This is where @vitor's another observation comes in.

- What fraction of users will feel "lied to"? (guess: teeny tiny)
- How easy is it for the above users to update their mental model? That is, them realizing that "when alfred says *default browser*, it means, under the hood, it is like calling 'open' without an app argument" (guess: very easy for most users)

 

My interpretation of @vitor's view is that because it is only a teeny tiny fraction of users who will ever get confused (cuz most users won't know/bother about non-http(s) schemes), and those users (not all, but most) will quickly figure what is going on, it is not worth changing the UI as it would mean complicating the UI for the other users. This is the part where I disagree. What if the said change didn't complicate stuff?

 

Here's a mock:

mockup.thumb.png.2d167f3e940cf86ea25093b9e1134614.png

- instead of "Browser:" it says "Open With:"

- instead of "[Firefox Icon] Default Browser" it says "[Generic Mac Icon] MacOS Default"

 

To my eyes, this change won't add or cause any confusion for the majority of users (who are concerned only with *web*).
At the same time, it eliminates the confusion for the minority too (who would enter "craft://..." and get confused as to why the dropdown has only web browsers)

 

TL;DR: Presently, the following are simultaneously true

  1. As @Chris Messina pointed out, the UI is wrong in some cases. (It shows "[firefor icon] Default Browser, but opens in Craft, which is not a browser)
  2. As @deanishe pointed out, most users learn that even though the UI is wrong, the actual behavior is correct. Not all users, because Chris just gave us a data point.
  3. As @vitor pointed out, changing UI is a bad idea if it improves experience of a tiny minority while making it worse for the majority.

@vitor what do you think about my proposed changes? Do you think it'll degrade the "most users'" experience?
@Chris Messina what about you? Do you think these changes that I suggested would go a long way in addressing your complaint (which is my complaint too, by the way)?

 

@Andrew it would be awesome if you chimed in. You're the OG and solo designer, and looking at Alfred, an outstanding one!

- Do you see this as an issue or non-issue?

- What do you think of the proposed changes?

Link to comment
Share on other sites

On 2/2/2021 at 7:49 PM, Chris Messina said:

Alfred could better support routing x-callbacks or deeplinks directly to the corresponding native apps, rather than going through a browser first.

This thread started out with a complaint about an issue which does not actually exist.  Yes, the UI is old and probably predates the widespread use of URL schemes on MacOS, and hence might be confusing if you haven’t tried calling a URL scheme from Alfred.  But why not try it and see what happens before posting criticism?  I suspect that’s what put people off.

Link to comment
Share on other sites

@Chris Messina this is indeed a UI issue, however minor, as the underlying feature works as expected (all URLs are routed via macOS).

 

Alfred should really dynamically be showing the correct default handler if possible.

 

Taking suggestions from this thread (thanks for the relevant input), I've updated Alfred to show "Open With" instead of "Browser", and the default handler will automatically update as you type, for example:

 

browser1.png

browser2.png

browser3.png

 

This should be in the 4.3.2 pre-release in the next few days.

 

Cheers,

Andrew

Link to comment
Share on other sites

  • Andrew changed the title to Better support for native app x-callbacks/deeplinks?
13 hours ago, Mr Pennyworth said:

To my eyes, being able to open other URL schemes with this workflow object seems like a case of "it is possible due to particular implementation details".

 

Those are standard macOS "open stuff" semantics. You choose "Open" (or just click) for the default app, and "Open With" to select a specific app. That's how opening external files/links works in any well-behaved Mac app.

Link to comment
Share on other sites

1 hour ago, deanishe said:

"Optionally select the browser you would like this web search to open in."

 

Would "application" and "URL" be better wrt the new behaviour?

 

If you update to the pre-release, the text is actually different to the screenshot :) The dropdown only contains browsers, not other apps. 

 

If you want to do even more advanced URL handling, then a Run Script object is what you should be using. 

 

Cheers,
Vero

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...