Leaderboard

You're right about that. We do have something in the works that should make this easier. It's not going to be an all-singing, all-dancing curated directory, though. It's not that they don't want to. It's rather that there are only two of them, and they already work full-time on Alfred. As you've probably noticed, Andrew already has his hands full getting Alfred ready for Catalina. Understood, but it would nevertheless behoove you to think your suggestions through to something rather more concrete if you want a concrete response. Announcing that GitHub has labels and that they could be useful isn't really news to anyone. Well, let's focus on the "us" in that statement. The Alfred team simply does not have the time to implement what you're suggesting. All your examples have a team of people dedicated to managing their directories. In Alfred Land, the team is us. And this sounds a lot like "screw the user, imma use my favourite tools". Which is precisely why any developer who cares about their users shouldn't consider using a version of whatever that isn't shipped with macOS. In most cases, it's nothing but short-sighted prioritisation of developer convenience over user convenience. And I say "short-sighted" because the developer inevitably has to deal with all the problems their choice causes users. And it sounds a lot like you're trying to say that Alfred should somehow solve these problems you've caused yourself and your users for you. (And again without a concrete suggestion of how this should happen.) I can understand that, but as I already said, this suggestion runs counter to Alfred's fundamental philosophy. It won't be implemented not because it can't be implemented; it won't be implemented for the same reason that Pages won't be adding support for WhatsApp messages. That's not streaming. That's pagination. They are not the same thing, and as I already said, Alfred has decent support for pagination. I assume that you're actually talking about pagination again. So this is already possible, you just haven't figured out or asked how to do it. It means "there are legal ramifications, but I've hired a lawyer". That's right. So your paragraph about how things work in the US isn't really relevant, is it? What is constant, however, is that legal issues are a big headache, very time consuming, and potentially extremely expensive. Which "value-add components" exactly? So Alfred should move to a pricing model that is widely despised? Seeing as the major "value-add" of Alfred's Powerpack is the ability to use workflows, and that almost all of those are open-source and provided free of charge by their authors, exactly how well do you think a subscription for access to them would go down with the people who write them? Do we all get a cut, too? Do I get a bigger cut because hundreds of workflows are based on my libraries? Does Alfred start to spy on users in order to determine who gets how much? No problem feels unsolvable if you haven't given it any serious thought…

I'm going to start backwards here. The process of discovering new workflows is harder for non-developer users than it should be. I understand that wanting to cross the threshold from just building a Mac app → running web infrastructure is a leap that the developers may not want to do. As a developer, I understand the reasons. But at this point, I think that not having a first-party workflow directory is reaching a point where it makes quality workflows that much more difficult to find, trust, etc. If the core team doesn't want to do this, then MUCH of my feedback falls on deaf ears. But I think the community has reached a point where we need something more reliable and trusted to help make sense of the chaos. It's something that I believe would make the PowerPack (and workflows, specifically) that much more valuable to the community. This is a pretty foundational idea behind much of my feedback. "Integrations" and "leverage" are awfully vague words. What do you mean exactly? Tying Alfred to specific services is a very big ask (strategically-speaking). I think you'd need some pretty compelling arguments to do so. They are vague. I'm brainstorming here, not solutioning. IF we assert that there would be a first-party site for discovering workflows (as mentioned at the top as being a foundational idea), we could do something like what npmjs.org does for tools like Yeoman — any npm package that starts with the work `yeoman-` is auto-discoverable by the Yeoman CLI tool. The Alfred team documents and/or tells people that adding certain named-topics to your GitHub repo for a workflow will enable it to be auto-indexed by the first-party workflow discovery site. Developers build workflows and apply these topics to their repos. There could be a process (cron, whatever) that polls the GitHub API for any repository with a topic of `alfred` (or `alfred-v3` or `alfred-v4` — however it is decided) and injests that data into the backend of the first-party workflow discovery site. GitHub is a major, major service which is owned by Microsoft. This feels like a reasonably safe bet, so let's do this first. Atlassian (makers of JIRA and Confluence for enterprises) build BitBucket. That one also feels reasonably safe. And GitLab is a third which is gaining in popularity. That feels a little less safe, so let's talk about doing that one last. I'm recommending that solution based on these experiences: This forum's software is not great at the job it's been given for workflows. Packal appears to be abandoned. PacMax is… I'm not sure. But I see a TON of duplicates that you can't find until you click through and do some digging. And for all of these, you can write a README, but then you'd need to copy-paste it into the forum software or duplicate some levels of effort to get them listed on the workflow site, du jour. There's too much friction. Packagist, npmjs, and even Golang have solved this better already. Let's copy their best ideas. Which solutions and churn? The Node community's updater is broken, but Vítor's and mine are well-maintained and have been working since the day they were introduced. Alleyoop, Monkey Patch, etc. Don't do that. Use /usr/bin/security to put them in the Keychain. Sounds awesome. Glad to know about it now. https://www.google.com/search?q="%2Fusr%2Fbin%2Fsecurity"+site%3Aalfredapp.com How? It seems to me that anything markedly easier than pasting debugger output into a forum thread or GitHub issue would require dedicated infrastructure. If you submit a bug against one of my workflows, how am I going to get back to you? The Alfred team can't just give me your email address. The author can provide a URL to the place where they want to collect the feedback. Maybe it's a GitHub Issues tracker or something. Alfred provides that URL as a clickable link in it's UI when you're looking at the debugging data. Now that's I'm hunting around for it, I see the debugger "bug" icon. For non-developers, how do we instruct them (in the Alfred UI) how to send the workflow developer the required information. I think we can simplify that first step — kinda like a 0-RTT in HTTP/2. There already is. You use /usr/bin/env in your shebang… But it's generally better to hard-code a path because the versions of languages that users install vary a lot more than the versions installed by Apple do. If I use /usr/bin/python, I have a much better idea what I'm going to get than if I use /usr/bin/env python, which might point to some stripped-down Anaconda version of Python that's missing a bunch of features or even a fundamentally-incompatible version of Python 3. It sounds like I wasn't very clear and you've missed the point I was trying to make. The workflow developer includes a file inside his workflow (call it `requirements.sh` for example). Alfred runs that script on install, and expects a specific output format from the script, which would tell Alfred if something is missing. (Alfred itself just runs the script and returns the results in a user-friendly way — it doesn't know/care about the runtime.) The workflow developer includes a second file inside his workflow (call it `install.sh` for example). When the end-user (non-developer) clicks "Proceed" (or whatever), Alfred runs that script, passing along the results from the installation script so that that installer knows what to install. (Alfred itself just runs the script and returns the results in a user-friendly way — it doesn't know/care about the runtime.) This is an example of the tension between trust/security and convenience. This would enable non-developers to make sure their systems have the runtimes needed. Alfred makes no effort to pay attention to the runtimes — it would only facilitate the "conversation" between developer and end-user. Also, macOS is going to stop shipping things like Python, Ruby, and PHP with their systems by default. Any workflows which rely on language runtimes are going to have a bad time if we have to ask the end-users to "Install Node" or "Install Python, but not 2.x, because you need 3.x". I'm just looking for an approach which can simplify this exchange for (non-developer) end-users like my kids and wife. Disagree totally with this one. macOS comes with plenty of very capable languages. If a workflow developer wants to use something else instead, then I think it's up to them to deal with the problems that causes. It also wouldn't work particularly well in practice because some of the worst offenders (the Node guys) bypass Alfred's own install mechanism completely anyway. Presumably, Alfred will have to gain some knowledge of runtimes for future versions of macOS, but they'll necessarily be limited in number (it isn't going to download and install any old thing you point it at for obvious security reasons), and some developers will doubtless insist on requiring other ones. This sounds a lot like "just upgrade your browser" back in the day. It doesn't matter how right you are if no one wants to work with you. I definitely think we need to push this forward instead of giving-up. Validating issues at install-time is the right time to perform the validation from a user-experience perspective. Trying to run a workflow which relies on features of Python 3.5 (or whatever newer-than-what-macOS-ships-with) by a non-developer results in looks that say "why the hell are you installing this piece of junk on my computer?" Look across the community of workflows (wherever they may be — different problem), identify most popular languages, and start with developer guides for those languages to start. I think that the very-hands-off approach of the Alfred core team has led to a sprawling mess. Now that we (collectively) have a better sense of the pain points for developers, we can work with the development team to step-up efforts. That might mean having strong opinions that not everybody agrees with… and that's OK. How do you propose that should work? fzf works with line-based input, which is effectively a stream. Alfred uses JSON, which isn't structured that way. And as with fzf, it would only work if the filtering were left to Alfred, so you wouldn't be able to implement any smarter, context-aware filtering in your workflow if it were based on a streaming model because Alfred would have no way to inform your workflow that the user's query has changed. The rerun feature already allows you to "stream" paginated results in a way that's compatible with JSON and implement your own filtering. (Granted, it's a bit of a pain to do, though.) Not sure. It's more brainstorm than solutioning. But if you think of other services with streaming results, I'm going to use Amazon S3 as an example. S3 has no idea how many buckets you have, nor how many files you have, at the API level. It simply says "here are 1,000 results, and this endpoint will tell you how to find the next results". So, you might have 15,000 results. But all you can do is fetch 1,000 at a time. You start to filter against the list of results, and the source set of results changes while filtering. And Alfred uses JSON (and XML) now. Is there something that says we can't have an alternate format that is optimized for streaming? Something with buffers that get dumped as new results become available? (Yes, I admit that this may be a bit of an edge-case, but there are some cool things I've wanted to do with AWS that only works when the result sets are small and not enterprise-y.) A very fundamental design goal of Alfred is that it does as little as possible when it's not actively being used. This is rather contrary to that goal, and also currently pretty easy to do using the very robust APIs macOS already has for this purpose. Is it a design goal? I mean, cool if it is. But what if you want to say "do this thing for me, and keep working on it until you're done, whether the UI is still up or not". Being able to jump back into flow by clicking a Notification would be cool. Also, non-developers don't know about the "very robust APIs macOS already has" (which I agree with). I would just love to see support for them exposed via Alfred. I'm not suggesting to re-invent any wheels. But having my wife be able to ask Alfred who her Pinterest customers were (for a given timeframe? Ever?), filter by typing a name, and press return to launch an email client with the customers email address pre-filled seems like a really cool non-developer use-case that Alfred MAY be suited for. Possibly. But damn, that would be mind-blowing. It means doing quite a lot of work, and it's not very practical. Especially not at the level of curation you're talking about. Aside from the technical and time issues, there are legal ramifications. The last time I saw the stats, the most popular workflows by far on Packal were for illegally downloading copyrighted content. Back to my first point, yes I acknowledge that it's some amount of work. I strongly believe that it's something the community needs, which is independent of whether or not the Alfred core team wants to make such an investment. (That's why so many 3rd party versions come and go!) "Legal ramifications" sounds very negative. "Understanding the legal position" means the same thing, and is more neutral. IIRC, the Alfred developer(s) are in the UK, and would fall under UK law. In the US, we have the DMCA which protects websites which collect "User-Generated Content" with a DMCA takedown process. But that's just for copyright violations. BitTorrent, Inc hasn't faced the same kind of legal trouble as the torrent sites because it's simply a tool with legitimate non-illegal (there is no such thing as being "legal"; only that it's "not illegal") uses. IANAL, but Alfred seems to be a tool with many (most?) legitimate, non-illegal uses. The "first-party workflow discovery site" could make a strongly-opinionated statement and say that they will not allow certain kinds of workflows (like Apple does with the App Store), and any that are found in violation will be blacklisted by the discovery site. How to pay for it? Ideally, it would be volume-of-PowerPacks. The better workflow ecosystem drives more sales of the PowerPack, and a portion of the funds from the PowerPack goes back into infrastructure costs. With things like AWS or GCP, and a background in highly-scalable whilst cost-effective web engineering, you can start cheap, and grow as the PowerPack users grow. Small instances with lots of caching, Lambdas with API Gateway, and you can build it (but this is also my wheelhouse, so… it sounds easy and cheap to me). Perhaps we look at charging 99¢/month (USD) for users of this service, background tasks, and other strong value-add components. The free-loaders would automatically be filtered-out, and the people who would actually be using it are contributing to keeping it running. It's how businesses have operated for thousands of years. But the value-add would need to be strong. The more useful cloud features, the more users feel like their money is well-spent, and the cost-per-user ratio swings lower at higher volumes of users. I don't even think it would be that tough of a sell. For $2.99/mo, you get a "professional" account and a nice badge on your profile. And some other features. Letterboxd and Trakt.tv do a good job of this. But that's just a brainstorm… These don't feel like unsolvable problems.