Standard Workflow Object + Alfred-UI for obtaining API tokens

[Chris Messina]

I've been exploring Raycast and one of its benefits is its deeper integration with SAAS like GitHub, Jira, Zoom, G Suite, Asana, and others. 

 

Given that all of these providers require authentication, I think it could be incredibly powerful if Alfred made it easier for Workflow developers to get API tokens from the most popular providers using a standard Workflow Object (either an Action (i.e. Sign the User In) or Utility (i.e. Get Access Token)).

 

I realize this would require that Workflow developers would need to get API keys and do some extra leg work, but what I would like to see are Alfred-provided UIs like these:

 

Once the authentication/authorization flow is complete, the Workflow Object would create an Environment Variable for the retrieved API token.

 

 

 

[vitor]

There’s nothing about this that can’t be done with a Workflow or external tool (including adding the API key to the Workflow Environment Variables). Yet, making the feature itself and keeping it up to date with all the obtuse and changing processes of third-parties sounds like a crapton of work. Alfred doesn’t even have official integrated bookmark support for every major browser, and this would be way more work than that.

 

In addition, making an official Alfred GUI to ask for private tokens that any random Workflow can use seems like a potential liability.

 

This would be better served as an external open-source tool, where people could contribute new providers.

[Chris Messina]

Uhm. Well, ok.

 

I guess I can just use Raycast. ¯\_(ツ)_/¯

[deanishe]

3 hours ago, chris said:

I guess I can just use Raycast. ¯\_(ツ)_/¯

 

I'm guessing you don't realise that what Raycast is doing is about 10% of what you're actually requesting.

 

OAuth is very complex to implement. Dealing with your own application's various keys and secrets and scopes is one thing. Building something that can handle arbitrary application IDs and scopes is a whole different ballgame.

Edited December 2, 2020 by deanishe

[vitor]

7 hours ago, deanishe said:

OAuth is very complex to implement.

 

I think I gave up the few times I tried to do it. It’s so much bloody work. Pinboard has the right idea: have a page with a copiable token and a way to reset it; or allow to retrieve it via username and password.

I wondered if he tried OAuth at one point, considering the line at the top of the API documentation:

 

Quote

Last updated October 15, 2014 (removed language about oauth, added ban policy for third-party sites that store passwords).

 

But apparently he hasn’t and agrees on its awfulness:

 

 

Edited December 2, 2020 by vitor

[deanishe]

51 minutes ago, vitor said:

It’s so much bloody work.

 

Aye. It really sucks to implement. The idea is good (make developers jump through a few more hoops to make things dead simple for users), but it was designed for server-to-server authorisation and sucks for client–server. It's actively terrible for open-source and self-hosted software.

[Chris Messina]

3 hours ago, deanishe said:

It really sucks to implement. The idea is good (make developers jump through a few more hoops to make things dead simple for users), but it was designed for server-to-server authorisation and sucks for client–server. It's actively terrible for open-source and self-hosted software.

 

This is true. Which is why it seems like Alfred could make it easier to interact with web services for Workflow builders. 

 

I suppose if @vitor could convince every web service provider that has an API to make it easier to get a token, then my suggestion would be moot. But until that happens, I figured creating standard plumbing to handle these flows might reduce some complexity. 

 

And FWIW, I'm quite familiar with OAuth. I was part of the original set of people that brought it together — and worked on OAuth 1.0 before we released OAuth 2.0. I am aware how annoying it is to implement/adopt — but it was also intended to make computing more secure so that users weren't passing their passwords around across the web.

 

[vitor]

34 minutes ago, chris said:

I suppose if @vitor could convince every web service provider that has an API to make it easier to get a token, then my suggestion would be moot.

 

A more logical solution seems to be to make OAuth less complicated. I’ve never seen anyone say they like it or found it easy to add.

 

I’m not trying to disparage your work. I don’t question you did what best you could under the circumstances, but if even the official website recommends—on the homepage—an external service to take away the pain of implementing it, it seems something else could improve in the standard itself.

 

34 minutes ago, chris said:

And FWIW, I'm quite familiar with OAuth. I was part of the original set of people that brought it together — and worked on OAuth 1.0 before we released OAuth 2.0.

 

Then you seem uniquely positioned for the idea above. Why not work on the generic open-source tool which would make this easier for everyone, at the same time saving whatever limited time Alfred’s sole developer has? Your request is a niche feature (in the grand scheme of Workflows) that takes a lot of (by your own admission) annoying work.

 

This is a genuine question. Is there something stopping you from working on such a tool, seeing as you have the domain knowledge and the desire to see it applied in this particular case?

With a generic tool, everyone would benefit. There’s nothing to be gained by this being implemented directly in Alfred, in the sense that an external tool would work just as well (but would have several outside advantages). Heck, if you do it I’ll even write the code and documentation on how to add the resulting token to Alfred Workflow Environment Variables. And I’ll make examples in AppleScript, JXA, and by directly editing the plist.

Edited December 2, 2020 by vitor

[deanishe]

57 minutes ago, vitor said:

This is a genuine question. Is there something stopping you from working on such a tool, seeing as you have the domain knowledge and the desire to see it applied in this particular case?

 

Same.

[Chris Messina]

10 hours ago, vitor said:

This is a genuine question. Is there something stopping you from working on such a tool, seeing as you have the domain knowledge and the desire to see it applied in this particular case?

 

It's a fair question. Thank you. The hurdle in my way is that I'm not a developer, so my contributions are limited to not-engineering-level tasks.

 

I can provide design, flows, user testing, advocacy, wireframes, project management...  Lots of the stuff I did in the OAuth days! 

 

But I also don't want to put a lot of effort into something that other people wouldn't find valuable. I don't need @Andrew to devote his time to this specifically, but I did want to gauge interest — both specifically his (i.e. "is this a feature that would be relevant to Alfred's roadmap?") and then more generally (i.e. "would people who build Alfred Workflows that interact with web-based APIs find such a built-in flow useful?").

 

@vitor what I think I hear you suggesting is that this kind of thing could be developed outside of Alfred core, similar to OneUpdater, which many people could choose to use if they want, but it wouldn't necessarily be or become part of Alfred Core. I'm good with that.

 

Perhaps the first thing to do would be to somehow assess which tokenized APIs are the most popular among the Alfred userbase and then focus on how to extract API tokens from them, and then provide documentation/workflow config/boilerplate to make it easy to get an off-the-shelf/copy-paste Workflow Object that could handle the authz portion of interacting with an API? A kind of Okta for Alfred?

[deanishe]

5 hours ago, chris said:

but I did want to gauge interest

 

In what exactly? I mean, nobody cares in the least about OAuth itself. So what's the payoff to users that would make implementing it worthwhile? There are already workflows for all the services you listed.

[Chris Messina]

Just dropping more evidence of a pattern I'm seeing in cloud-connected software... this time in Linear.app.

 

[vitor]

1 hour ago, chris said:

in cloud-connected software

 

Which Alfred isn’t. There’s a huge difference between adding OAuth integration to your app, and adding OAuth integration to other apps from yours.

And the differences don’t stop there. Linear is by a company who just raised millions in venture capital and will sell itself (and its users) to the highest bidder they can get (because that’s the goal of raising that money). Alfred is by an independent company with a single developer who has to choose wisely which features to spend time on, and a high work low usage feature isn’t a wise investment.

These aren’t comparable. Linear just got a bunch of money (and thus resources) to throw away on rapid expansion and buzzworthy features. They can afford to hire developers who will spend their time implementing OAuth while burning out questioning their life choices and wondering why they didn’t get into carpentry instead.

These aren’t comparable. “App adds OAuth” doesn’t prove in any way that it’s a good idea for everyone. If tech trends were to be followed blindly, Alfred would be an Electron app with integrated chat and its own emojis.

[Chris Messina]

2 hours ago, vitor said:

Which Alfred isn’t.

 

Huh, I hadn't thought about that. I didn't realize that people use Alfred disconnected from the internet.

[deanishe]

7 hours ago, vitor said:

Alfred is by an independent company with a single developer who has to choose wisely which features to spend time on

 

This. I mean, the mini player overhaul you suggested would be awesome, but implementing it and maintaining the integrations is more or less a full-time job in itself.

 

4 hours ago, Chris Messina said:

I didn't realize that people use Alfred disconnected from the internet.

 

There isn't a single built-in function (barring the updater) that requires an Internet connection, is there?

[Chris Messina]

9 hours ago, deanishe said:

This. I mean, the mini player overhaul you suggested would be awesome, but implementing it and maintaining the integrations is more or less a full-time job in itself.

 

I think this conversation could devolve if we're not careful, but let me acknowledge both your and @vitor's point that Alfred is a one-man show when it comes to maintaining the core — and that I imagine the codebase is pretty sprawling — so my comments/feedback/suggestions are in no way to knock on @Andrew's efforts (to the contrary)! 

 

That said, I want Alfred to be even more amazing — but you have to be pretty savvy to get the benefits. And so I wonder if certain parts of Alfred should now be spun out into open source components or refactored as UI APIs that Workflow devs could also contribute to (i.e. through open source contributions)? The music mini-player is one clear example of a component that could use some love from the community and enable the community to serve itself better.

 

If @Andrew doesn't want to hire more help and there's an anti-VC sentiment here, there is still a question about how to grow the community of participants (presuming there's an appetite for that — I certainly want to make it easier for people to benefit from and participate in the Alfred community!) and make it easier for Alfred to tackle a wider set of use cases without overburdening @Andrew.

 

There are arguments to be made against offering more avenues for open source contributions (i.e. healthy open source projects don't happen for free and without a lot of overhead) and one could argue that the Workflow system is sufficient as it is... but I'm just looking at shareable UI components (for authorization, for playing media) and wondering if the community could contribute more to Alfred Core in a productive way?

 

 

9 hours ago, deanishe said:

There isn't a single built-in function (barring the updater) that requires an Internet connection, is there?

 

Well, besides the fact that (AFAIK) you can't order Alfred on a CD and need the internet to buy the Powerpack... no, Alfred Core doesn't connect to the internet that much... but it also integrates Web Searches, Web Bookmarks, the Dictionary integration looks up information on Wikipedia... Anyway, my perception is that Alfred is software that helps me use my computer more efficiently and for me, 95% of that work is online and through web services these days.

 

I know looking at the competition isn't what should drive one's roadmap, but the competition for Alfred's role on the desktop is heating up and 1) there are a bunch of good/interesting ideas in some of that competition and 2) given my above thoughts about growing the community of contributors (which is ultimately self-serving, since the better Alfred gets for everyone, the better Alfred gets for me), I'm mildly worried that more newcomers will bypass Alfred and join those newer projects instead, which is fine — but not so fine if we want to attract the best and most interesting contributors...

[vitor]

1 minute ago, Chris Messina said:

but you have to be pretty savvy to get the benefits.

 

I disagree. You can already do a bunch of things without programming knowledge, and for the steps where you do need it, successfully fostering a helpful community is a step to bridge the gap. Yes, a programmer’s mindset helps, but that’s true of all tools that help you make your custom actions.

Furthermore, this particular case would be a bad example to support that notion. OAuth is already difficult to implement in specific cases by knowledgeable people and everything it allows you to do already requires programming knowledge, so the benefits of integrating that functionality in Alfred (if they even outweight the cons, which I argue they don’t) are minute.

 

9 minutes ago, Chris Messina said:

And so I wonder if certain parts of Alfred should now be spun out into open source components or refactored as UI APIs that Workflow devs could also contribute to

 

As a maintainer of open-source projects, including popular ones, I’ll point out that while “getting contributions from the community” sounds like a panacea, in practice it’s a full time (unpaid) job of its own. It takes a lot of time to review contributions, manage those communities as well, and work on the project. I once saw someone compare open-source contributions to giving out puppies: after you’re gone, I’m the one who has to take care of it.

 

But you seem to be familiar with that notion, from your comments further down.

 

14 minutes ago, Chris Messina said:

and there's an anti-VC sentiment here

 

My opinions are my own and in no way reflect the opinions of Alfred’s team or its community.

 

16 minutes ago, Chris Messina said:

there is still a question about how to grow the community of participants (presuming there's an appetite for that — I certainly want to make it easier for people to benefit from and participate in the Alfred community!) and make it easier for Alfred to tackle a wider set of use cases

 

You seem to be operating from the assumption there’s an appetite for customising every little aspect of Alfred, and that allowing for that customisation will grow the community. Have you considered the option that Alfred is plenty customisable already, and that increasing what it can do may be a more effective way to grow the community?

Instead of spending time adding support for external services which can change their APIs or terms on a whim (thus either taking more time to continue to support or angering a section of the community when support needs to be abandoned), I’d argue it’s way more productive to give us the tools to build the tools. Not only can we already support those services via Workflows, we can support them in custom ways which fit our exact usage patterns.

 

25 minutes ago, Chris Messina said:

and one could argue that the Workflow system is sufficient as it is

 

I don’t think anyone is arguing that. Quite the contrary, we want more things in Workflows, but we want things that will have an impact and allow us to do new things, not niche features which take a lot of development time and can already replicated.

 

29 minutes ago, Chris Messina said:

Well, besides the fact that (AFAIK) you can't order Alfred on a CD and need the internet to buy the Powerpack

 

Downloading and buying aren’t built-in functions.

 

30 minutes ago, Chris Messina said:

I know looking at the competition isn't what should drive one's roadmap, but the competition for Alfred's role on the desktop is heating up (…)

 

Which is a great argument to not waste time on niche hard features which require a lot of effort, like integrated OAuth integration with other services.

We all want what’s best for Alfred to flourish. That’s why we choose to spend our time on this forum helping users, building Workflows for ourselves and them, even when we’ll never use them ourselves. And it is exactly because we care for Alfred’s future—and have for years—that we want it to have the best shot and continuing to be relevant (and be even more) by investing development time on features that will make a real difference, with prolific Workflow developers bridging the gap on what isn’t native.

Disagreeing with your ideas doesn’t mean we don’t care for Alfred, it just means we disagree with your solutions to achieve the common goal we have.

[Andrew]

This has been an interesting conversation to read, Vero and I have been following it this week.

 

2 hours ago, Chris Messina said:

and that I imagine the codebase is pretty sprawling

 

This couldn't be further from the truth - As you've probably noticed, the entire Alfred download dmg (non-universal) including all resources, full interactive preferences, 4 separate app binaries and a framework is 3MB. This kind of small size is absolutely unheard of this day and age, what with overly bloaty, non engineered, stackoverflow driven code. Every design and engineering decision is carefully considered, and no unnecessary code exists in Alfred's highly refined core framework.

 

Vero and I have always taken huge pride in what we do and how we drive Alfred, which is why, more than 10 years on from inception, we still run the product we love for the users we love.

 

2 hours ago, Chris Messina said:

there's an anti-VC sentiment here

 

There is no anti-VC sentiment, many product wouldn't exist without it. Having said that, unfortunately, many products which are driven by VC come and go at the drop of the hat, and once the product is being driven by making money for somebody who doesn't care for the product, it can easily get derailed.

 

The focus of Alfred has always been to make a product that we personally want to use every day, and as a profitable, organically developed business, we don't have to sacrifice that for the benefit of an investor looking for a quick return.

 

2 hours ago, Chris Messina said:

Alfred's role on the desktop is heating up

 

And that's always going to be a good thing, as things do change and evolve.

 

We have an extremely solid plan for Alfred's future, as we have done throughout Alfred's history. It's much better for the product to focus on the things that benefit the majority of our audience rather than niche features which look good in a board meeting.

 

All I can do is ask you to trust us that Alfred will continue to get more awesome  

 

Cheers,

Andrew

[Chris Messina]

6 hours ago, Andrew said:

We have an extremely solid plan for Alfred's future, as we have done throughout Alfred's history. It's much better for the product to focus on the things that benefit the majority of our audience rather than niche features which look good in a board meeting.

 

All I can do is ask you to trust us that Alfred will continue to get more awesome

 

I'm not entirely sure how my comments/contributions are being received, such is the limitations of this medium. I'll presume some warriness on y'all's parts owing to prior experience, as well as an opening for me to prove my worthiness over time, like any healthy ecosystem.  

 

Given that — I'll presume that we're all interested in 1) Alfred persisting indefinitely 2) growing in utility/accessibility for all comers 3) focusing on investing in the most important/core components that enable #2.

 

The way in which those goals might be achieved are where we each have our own unique perspective, likely biased towards our own ability to contribute. As someone who is code-aware but not code-literate, I imagine there are more people out there like me than there are like @vitor who know Alfred inside and out. So, my bias is for giving people with my level of skills more capacity to wield Alfred's powers. I'm open to learning more, but in recognizing my ignorance, am trying to advocate for tactics and strategies that will decrease the slope of difficulty for using and customizing Alfred.

 

I'm also able/willing to back off from my advocacy if I have a deeper intuitive sense for where Alfred is going and have a general understanding of why it's going where it's going. To wit, there is no Alfred roadmap that I'm aware of — and while I do respect the wisdom that @Andrew and @Vero bring to this process, and absolutely believe that they know their audience best, I hope that my curiosity and probing isn't offensive as it derives from a place of wanting to be helpful and to contribute.

 

But if I don't know who the audience is, and I don't know what the roadmap is, then I'm left to suggest/propose directions that are most relevant to my immediate needs/interests.

 

I do trust that Alfred will continue to get more awesome — and I'd love to understand how to shape my contributions to support that end!

[Vero]

13 hours ago, Chris Messina said:

But if I don't know who the audience is, and I don't know what the roadmap is, then I'm left to suggest/propose directions that are most relevant to my immediate needs/interests.

 

Don't worry about it This community is full of people from different backgrounds, different areas of interest, more or less technical skills, and that's what makes it so brilliant.

 

The Features Suggestion section is perfectly suited for ideas and improvements, anything that would give community members a productivity boost. We're always happy to hear these ideas, I read every single thread, and it certainly does educate our future decisions. You sharing ideas that are most relevant to your immediate needs and interests is perfectly fine, and that's what the section is intended for.

 

As and when there's sufficient interest in a particular feature, and it fits in with Alfred, we do deeper analysis tow work out whether it's a sensible addition from a technical and user experience point of view (e.g. Does it use public APIs? Does it have a promise of longevity and stability or will it be a flash in the pan? Does it add benefit?) Improvements that make the cut then find their way into a release in the future

 

For the more niche features, the workflows give a lot of flexibility. I know you say you're not a coder, but quite a few can be created with little to no coding knowledge (I'm living proof, I've got dozens of my own). For those that require a bit more code, a friendly post on the forum with insight into what you've worked out so far can get lots of people on board.

 

In short, we listen to everyone's suggestions and even if we don't respond individually to all, we hear you. 

 

Cheers,
Vero

[gingerbeardman]

I'm a long time Alfred user (next month it will be a decade since my first powerpack puchase; I started with Alfred version 0.8.2).

 

Even as a workflow creator/power user I consider my use of Alfred quite limited in scope: clipboard history, web searches, a few workflows with keywords, a few workflows with only hotkeys, and of course app launching. 

 

Anyway, I found out about Raycast yesterday and given that I'm away from my computer right now all I can do is read about it and watch YouTube videos. This is the only thread on Alfred Forum about Raycast (surprising!) so I thought I'd add my thoughts here. I'm excited to see how it fits with my habits, it has the possibility of replacing multiple apps on my Mac. At a minimum the user interface and preferences window look extremely well considered. 

 

It seems Raycast have done a few things different which has given them traction:

• targeting developers ahead of normal users
• bundled workflows for popular services
• onboarding process that empowers users
• user interface is insanely great
• all features are free (for now, they say)
• big team and rapid iteration is apparent everywhere

Reading yesterday on twitter a couple of thing caught my eye which I feel summarises the situation nicely:

 

 

There are many more along this line, with many developers stating that they are switching from Alfred to Raycast citing things that were already possible in Alfred. They were obviously unaware of these things. Example:

 

 

(of course I replied to say that this is indeed already possible using Alfred)

 

So I'm wondering how many Alfred users dive into workflows to customise the experience to suit themselves? Apparently not as many as I would have expected! And these users are all developers. Thinking about it, Alfred workflow discovery is actually very difficult for users. 

 

It might make sense for Alfred to rise to the occasion and surface more things during onboarding to make it known that the gap between Alfred and Raycast may not be as big as some users think. Apologies if it already does as it's been many years since I saw the Alfred onboarding process. 

 

 

Finally, I have to mention that this thread comes across as quite dismissive of good intentions in a host of ways. I found it really tough to read. This vibe pervades a lot of this forum in my experience. I'd like to see that improve. 

 

To get back on topic, if workflows are already managing API and tokens themselves in a whole variety of ways, it seems obvious to me that an official way to do that with a unified interface/experience could only be a good thing for users?

[vitor]

2 hours ago, gingerbeardman said:

It seems Raycast have done a few things different which has given them traction

 

You missed the biggest one: millions of dollars in VC funding. That’s quite difficult for Alfred to go up against with a two-person team for everything in the business. When you have money to burn, it’s easy to offer features for free despite a big team. That’s not to say you’re wrong on the other points—you’re not—but Alfred’s team has to (more) carefully choose where to invest their time.

 

3 hours ago, gingerbeardman said:

There are many more along this line, with many developers stating that they are switching from Alfred to Raycast citing things that were already possible in Alfred. They were obviously unaware of these things.

 

I agree that’s a hurdle, but it’s not immediately clear how to clear it. It doesn’t help that Raycast themselves misrepresent (or outright lie about; I can’t say) what Alfred can do. I’ve seen it in the wild once or twice.

Also note that their money buys them hype, and developers are inherently interested in new things. Their business model isn’t yet clear—will they be subscription-based, one-time purchase, will they sell your data before being bought by another company that will kill the app? And are they even targeting the same users as Alfred? From what I gather of their still closed API, their extensions will be exclusively built with code, which ignores a huge chunk of Alfred’s users (non-coders can and do make Workflows) and may not allow as much versatility (I don’t know). I could go on.

That doesn’t mean it isn’t worth looking into Raycast. All I’m saying is it’s too soon to imagine a doomsday scenario for Alfred because of it. Besides being new and loaded, are they that different from other alternatives, such as Launchbar (not rhetorical)?

 

3 hours ago, gingerbeardman said:

Alfred workflow discovery is actually very difficult for users. 

 

That’s another one where I agree with you. But it’s also another one without an immediate solution. There are quite a few websites for discovering Workflows, but (in my view) none of them are up to snuff after Packal. Partly because—in agreement with a comment on the YouTube link you posted—it can be hard to identify a dead Workflow. That said, I don’t think it’s fair to lunge that criticism at Alfred on a direct comparison to another tool which hasn’t existed for long enough for that to be an issue. I see no reason why they would be immune to that.

 

3 hours ago, gingerbeardman said:

To get back on topic, if workflows are already managing API and tokens themselves in a whole variety of ways, it seems obvious to me that an official way to do that with a unified interface/experience could only be a good thing for users?

 

It’s been discussed at length on this issue why that’s not necessarily true. It’s a feature the vast majority of Workflows would not benefit from, hard to tackle, and at the mercy of the whims of third-parties. And to do all that you need time, which will not be used for something else. Yes, if that feature were implemented and maintained without effort (or done by someone else in a third-party tool, as suggested above) it could be a good thing. But it has a major tradeoff as it stands. Is that tradeoff worth it at this time? I’d argue “no”, but that’s only an opinion.

 

Again, we all want Alfred to be better. And we all want Alfred to be as powerful as it can be as long as it doesn’t come at the expense of speed or stability. But every change you make has multiple costs; considering those before investing is wise.