Jump to content

Recommended Posts

[I originally posted this on Reddit, but I'm posting again here to make sure that it's seen.]

 

The tool itself is fine. Good improvements, but mostly invisible. My kids don't even know how to use the computer when they use a Mac without Alfred. Incredible software!

I've been a user since 1.0 and a PowerPack user for just as long. Before that I used the Google task launcher thing, and before that, QuickSilver.

What I'm interested in is a thriving workflow community. If you want to find workflows, you need to search too many places. Packal and Pacmax seem abandoned. You have the forums, Reddit, and random guesses in GitHub search. Consider the following to be feedback for improving the next generation of Alfred:

Make it easier for users to get started:

  1. Enable them to click a link for a workflow, and have Alfred be the default handler instead of forcing me to download, find it, double-click it.
  2. Enable developers to define a setup flow, with some kind of standard UI. For example, I use a workflow for searching Atlassian Confluence wiki software (for work). Instead of having to type `confluence username` and `confluence password`, provide an up-front UI where a developer can ask these questions, and the user can answer them. This UI should be triggered the first time the user attempts to use the workflow (e.g., I type confluence, and the default option in an un-setup state is to start the setup). There should also be a way to validate these values before completing the setup (e.g., authentication to remote service was successful).
  3. One of the options in this UI would be to choose which keyword should be used to trigger it. The developer can provide a default, and the user can always go into preferences and change it, but being able to override the default keyword early would be a nice touch. For example, when installing the `pwgen` workflow, I always change the keyword to `pwd` because I can type it faster.
  4. Enable me to create different instances of the same workflow with slightly different configurations and map them to different keywords. For a concrete example, I want to have one instance of the Confluence workflow that searches ALL content (e.g., mapped to `conf {query}`), and another instance that can target a specific team's Confluence space (e.g., mapped to `team {query}`). Same workflow; slightly different configuration (in this case, search scope).
  5. If I search for something, but there are no results (or an error, or whatever), don't automatically fall-back to the catch-all options. If you recognize the keyword, have the top result say that there was a problem, and enable some way to view the logs and/or open the project in Finder. Perhaps this would be hidden behind an "I am a developer" checkbox in the preferences or something.
  6. Some kind of (better?) indicator in the UI when a workflow is waiting on the network.

When I develop workflows, here's what would make it easier/better:

  1. Optimize some integrations with GitHub (first), then BitBucket or GitLab (after).
  2. Leverage things like topics (GitHub) and pull those in. Standardize on things like `alfred-v4` or `alfred-v3`, and `alfred-lang-php` or `alfred-lang-go`.
  3. Have a simple, built-in way to lookup and download any updates to workflows. First-party hooks, please. The solutions coming from the community don't last, and I'm tired of the churn.
  4. Make it easy to save credentials/secrets to the (encrypted) system keychain instead of making me write them (unencrypted) to disk. First-party hooks, please. Something like I say that this field is a secret and it should have a particular name. Alfred accepts the secret and stores it without me being able to see it.
  5. Integrate sanely with the macOS system logging, so that I can easily read errors in the Console.app.
  6. Make it easy for people to discover how to find the project and/or development code. Maybe something like `{keyword}?` (e.g., `conf?`) for easily discovering metadata about a workflow?
  7. Make it easy for people to report bugs/issues and send the developer some kind of debug/diagnostic data.
  8. Define strong standards/conventions that I can follow when creating workflows, so that you can read them and present them to users, without me having to duplicate my effort. One example is to leverage GitHub topics (mentioned above) and just pull them in to a centralized database of workflows. Why submit manually to another website when you can search the API and auto-populate data for a workflow to show to users?
  9. Right now, the results are always a single set of options (analogous to the HTML <select> field). I would love to be able to set up the equivalent of an HTML <optgroup> in the results — a way to group them. For example, "here are the exact matches, then here are the fuzzy matches). HTML <optgroup> is an exact grouping (i.e., one group, then the next group). The group could have a label defined which provides instructions. Something like "Choose a language…". (Provide a link in the docs which point to Apple's HIG so that people know how the ellipsis character should be used in menus and buttons.)
  10. Having a way to add an icon to the left/right-edge that is vertically/horizontally centered and not inline with the other text would be a good way to flag certain results as standing out. For example, here are the search results from hub.docker.com. These are from the community, but these (with a star/checkbox/smiley-face on the left-edge) are official.
  11. I haven't looked at the multi-level query stuff yet, and you may have already done this, but supporting/auto-completing enums after the keyword would be awesome. Also wrapping enums in the previous suggestion as a group with a label, to allow developers to provide more context, would be awesome.
  12. Different versions of macOS include different versions of language runtimes (and Apple's documentation says that language runtimes will stop shipping by default in upcoming versions of macOS). There should be a way for the developer to specify binaries (detected by /usr/bin/env is preferable over hard-coding a path, like many hash-bangs) and versions that are required to run. This should be validated at install time, not at run-and-fail-time. If the current system does not meet the requirements, then the developer should be able to provide instructions and/or a setup script that can be run by Alfred (with user confirmation + sudo password, if necessary) to install any prerequisites. So, an install-time script to detect, and a setup script which can install missing dependencies. All would happen during this hypothetical "Setup" wizard.
  13. Some kind of package signing. Public/private key? GPG? User-facing warnings about installing unsigned workflows. Don't need to go full-scale notarization (yet), but let's see what the ecosystem does as a result.
  14. Streaming results. We define the format of the individual results, and as data comes back (e.g., fetching API results across pagination), we can append/prepend/overwrite results. `fzf` is an example of a CLI tool that can update results as new data streams in. Being able to filter those streaming results in real-time with fuzzy-matching would be mind-blowing.
  15. Some kind of background/async support.
    1. Example of background support: I install a workflow which lets me keep an eye on stock prices. This workflow has the ability to watch a particular stock, and can send a notification when it crosses a threshold or moves so many percentage points up/down. To me, background == polling/scheduled/cron-ish, but maybe I'm not thinking big enough.
    2. Example of async support: I want to use Alfred's file selection support to find a directory containing FLAC audio files, then pass that directory (or files) to a workflow which calls out to FFMPEG and converts them all to MP3 @ 96kbps (muah-hah-hah!). When the task is complete, I would get a notification. When clicked, Alfred would open with a new selection of MP3 files that I can take the next action on (open in iTunes/Apple Music/QuickTime Player).

A single, canonical place to find reasonably-curated workflows. Preferably owned and maintained first-party. Yes, it means running some servers and doing some work to curate. Not sure how practical that is for a small team, but it's necessary. When I look for workflows, here is what I want to know:

  1. What are the user ratings? (this means finding an easy way to enable users to rate the workflows they use and collect that anonymized data)
  2. What language(s) is this written in? (Can I contribute or hack at it if I want? What language do I need to know? Do I have that runtime installed?)
  3. What version of Alfred is this optimized for? (The first results on Packal are ≥ 5 years old)
  4. How many workflows of the exact same thing already exist? (Should I re-think writing my own and just use or contribute to an existing one?)
  5. Is this maintained?
  6. Is this maintained by a trusted developer? Or just some dude on the Internet somewhere?
  7. What new (or newly-updated) workflows are available which support (a) the latest version of Alfred, (b) whatever cool new feature of Alfred, (c) some other notable thing? Apple's App Store does this and it's a great way to find the signal amidst the noise.

Share this post


Link to post
Share on other sites

I agree that some of the pain points you identify are definitely problems (I'd particularly like to see a better setup/configuration UI than the workflow variables table), but I think a lot of it doesn't fit with Alfred's platform- and language-agnostic execution model at a fairly fundamental level.

 

9 hours ago, skyzyx said:

Optimize some integrations with GitHub (first), then BitBucket or GitLab (after).

 

9 hours ago, skyzyx said:

Leverage things like topics (GitHub) and pull those in. Standardize on things like `alfred-v4` or `alfred-v3`, and `alfred-lang-php` or `alfred-lang-go`.

 

"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.

 

9 hours ago, skyzyx said:

The solutions coming from the community don't last, and I'm tired of the churn.

 

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.

 

9 hours ago, skyzyx said:

Make it easy to save credentials/secrets to the (encrypted) system keychain instead of making me write them (unencrypted) to disk

 

Don't do that. Use /usr/bin/security to put them in the Keychain.

 

9 hours ago, skyzyx said:

Make it easy for people to report bugs/issues and send the developer some kind of debug/diagnostic data.

 

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.

 

9 hours ago, skyzyx said:

There should be a way for the developer to specify binaries (detected by /usr/bin/env is preferable over hard-coding a path, like many hash-bangs) and versions that are required to run.

 

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.

 

10 hours ago, skyzyx said:

This should be validated at install time, not at run-and-fail-time.

 

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.

 

9 hours ago, skyzyx said:

Streaming results.

 

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.)

 

9 hours ago, skyzyx said:

Example of background support

 

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.

 

11 hours ago, skyzyx said:

Example of async support

 

That's not really async, that's just clickable notifications (which would be very nice).

 

10 hours ago, skyzyx said:

Yes, it means running some servers and doing some work to curate. Not sure how practical that is for a small team

 

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.

 

Share this post


Link to post
Share on other sites

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.

 

11 hours ago, deanishe said:
22 hours ago, skyzyx said:

Optimize some integrations with GitHub (first), then BitBucket or GitLab (after).

 

22 hours ago, skyzyx said:

Leverage things like topics (GitHub) and pull those in. Standardize on things like `alfred-v4` or `alfred-v3`, and `alfred-lang-php` or `alfred-lang-go`.

 

"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.

  1. 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.
  2. Developers build workflows and apply these topics to their repos.
  3. 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.
  4. 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.
11 hours ago, deanishe said:

 

23 hours ago, skyzyx said:

The solutions coming from the community don't last, and I'm tired of the churn.

 

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.

 

11 hours ago, deanishe said:
23 hours ago, skyzyx said:

Make it easy to save credentials/secrets to the (encrypted) system keychain instead of making me write them (unencrypted) to disk

 

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

 

11 hours ago, deanishe said:

 

23 hours ago, skyzyx said:

Make it easy for people to report bugs/issues and send the developer some kind of debug/diagnostic data.

 

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.

11 hours ago, deanishe said:
23 hours ago, skyzyx said:

There should be a way for the developer to specify binaries (detected by /usr/bin/env is preferable over hard-coding a path, like many hash-bangs) and versions that are required to run.

 

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.

  1. The workflow developer includes a file inside his workflow (call it `requirements.sh` for example).
  2. 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.)
  3. The workflow developer includes a second file inside his workflow (call it `install.sh` for example).
  4. 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.)
  5. 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.

 

12 hours ago, deanishe said:
23 hours ago, skyzyx said:

This should be validated at install time, not at run-and-fail-time.

 

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.

 

12 hours ago, deanishe said:
23 hours ago, skyzyx said:

Streaming results.

 

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.)

 

12 hours ago, deanishe said:
23 hours ago, skyzyx said:

Example of background support

 

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.

 

12 hours ago, deanishe said:
23 hours ago, skyzyx said:

Yes, it means running some servers and doing some work to curate. Not sure how practical that is for a small team

 

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.

 

Share this post


Link to post
Share on other sites
2 hours ago, skyzyx said:

The process of discovering new workflows is harder for non-developer users than it should be.

 

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.

 

2 hours ago, skyzyx said:

If the core team doesn't want to do this, then MUCH of my feedback falls on deaf ears.

 

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.

 

2 hours ago, skyzyx said:

They are vague. I'm brainstorming here, not solutioning.

 

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.

 

2 hours ago, skyzyx said:

There's too much friction. Packagist, npmjs, and even Golang have solved this better already. Let's copy their best ideas.

 

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.

 

2 hours ago, skyzyx said:

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.

 

And this sounds a lot like "screw the user, imma use my favourite tools".

 

2 hours ago, skyzyx said:

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?"

 

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.)

 

2 hours ago, skyzyx said:

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 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.

 

2 hours ago, skyzyx said:

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".

 

That's not streaming. That's pagination. They are not the same thing, and as I already said, Alfred has decent support for pagination.

 

2 hours ago, skyzyx said:

(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.)

 

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.

 

2 hours ago, skyzyx said:

"Understanding the legal position" means the same thing, and is more neutral.

 

It means "there are legal ramifications, but I've hired a lawyer".

 

2 hours ago, skyzyx said:

IIRC, the Alfred developer(s) are in the UK

 

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.

 

2 hours ago, skyzyx said:

Perhaps we look at charging 99¢/month (USD) for users of this service, background tasks, and other strong value-add components.

 

Which "value-add components" exactly?

 

2 hours ago, skyzyx said:

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.

 

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?

 

2 hours ago, skyzyx said:

These don't feel like unsolvable problems.

 

No problem feels unsolvable if you haven't given it any serious thought…

 

Edited by deanishe

Share this post


Link to post
Share on other sites
Posted (edited)

I'm a real user, who is a very experienced developer, who provided some ideas for how to make the product better in my opinion. It's fine if you don't share that opinion — I'm an adult, and I recognize that not everyone is going to agree with me or share my ideas, and that's OK. But I'm making these suggestions because I am invested in this community and this software, and I want to see it be better tomorrow than it is today.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

The process of discovering new workflows is harder for non-developer users than it should be.

 

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.

 

Better is good, and I'm happy to hear it's coming. But the "all-singing, all-dancing" bit of sarcasm was unnecessary.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

If the core team doesn't want to do this, then MUCH of my feedback falls on deaf ears.

 

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. That's not work that I'm discounting or taking lightly. I believe that it is also true that the community has reached a point where it needs more than what 2 people can deliver. I haven't come up with a solution (yet), but you can't fix a problem that you don't know about — which is why I'm bringing it up.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

They are vague. I'm brainstorming here, not solutioning.

 

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.

 

I explained how I envisioned they could be used for the benefit of those who contribute to the community. That felt pretty concrete to me. If it wasn't, I'd be happy to discuss the idea further, but I need you to ask questions about the things you don't quite understand. I'm doing my best to articulate the idea clearly.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

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.

 

And this sounds a lot like "screw the user, imma use my favourite tools".

 

I am recognizing that neither you, nor I, nor anyone else can make anyone do anything they don't want to do, and I'm trying to provide a pragmatic suggestion for how to deal with the reality.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

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?"

 

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.)

 

This is called a strawman argument, wherein a strawman version of the issue is attacked instead of addressing the real issue. So let's start over.

 

Real developers — right or wrong — use features of languages. For the record, I agree with you that developers should shoulder more development cost so that the end-user has less friction. But more than once, I've faced issues where either I didn't have the right runtime installed for a workflow I wanted to use. Also, with multiple computers, one was new enough to have the runtime, while the other was older and did not have the runtime.

 

With regard to your passive-aggressive comment, "And again without a concrete suggestion of how this should happen.", I felt I was extremely clear in providing a suggestion that was just shy of writing the code for it for how it could work. Please re-read. Instead of simply complaining about things, I'm genuinely interested in driving towards solutions for this real-world problem, and I'm trying to bring ideas to support that.

 

Also, I've mentioned this multiple times now, and your responses seem to continually ignore it: https://tidbits.com/2019/06/25/apple-to-deprecate-scripting-languages-in-future-versions-of-macos/

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

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 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.

 

I disagree with your assessment about how far apart they are, but it's not a cross I feel like dying on.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

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".

 

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 know the difference between the two, and I'm definitely talking about streaming. Live updates to the dataset is streaming. It's pull, but it's still a streaming dataset. It may leverage AWS’ pagination support inside the scripting backend of the Workflow  (if it's S3, and if the API supports pagination), but the data being sent to Alfred by the Workflow would be live-updated as more results are fetched in parallel.

 

I'm thinking in terms of dumping buffers in a defined format, or HTML's Server-Sent Events, or even JSON Patch (RFC 6902) if you really want to stick to JSON for everything. The backend approach is less interesting to me than being able to push updates to the Alfred's Dropdown UI, live.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

IIRC, the Alfred developer(s) are in the UK

 

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.

 

It's relevant in that it adds context to the discussion which you may not have already had. There's no need to respond so negatively.

 

But you're right that legal issues are a big hassle. I don't think anyone would disagree with that. But you seem to be making an assessment that providing an "all-singing, all-dancing curated directory" infers there will be legal issues. Your logical fallacy is: slippery slope.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

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.

 

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?

 

Strawman, personal incredulity, loaded question, burden of proof, anecdotal, and a smidge of black-or-white — all in one response! Yahtzee!

 

Firstly, you have provided zero evidence to support your claim that the pricing model I've proposed is widely despised. It's literally the same model that powers Netflix, Spotify, and Xbox Live Gold. While it is true that those success stories are all big companies, even small companies like Smile Software (TextExpander) have healthy businesses operating with that model.

 

Secondly — and I thought this was clear, but forgive me if it was not — I'm not suggesting charging for the workflows. I'm suggesting charging for the curation. Just like Google is not a search company — it's an advertising company. Just like Facebook isn't a social network — it's an advertising company. Just like McDonald's isn't a fast-food restaurant — it's a real estate company. It's where these companies make the majority of their revenue.

 

Developers are free to publish their workflows anywhere. Users would (per my hypothesis) be willing to pay a small/reasonable amount on a regular basis for the curated, easy-to-use storefront. Perhaps Alfred could have some opt-in integration with this storefront, while not excluding outside sources in any way. It would enable the experiment to occur and see if we could achieve success. If, in the future, there were support for paid Workflows, they could be sold through the storefront with some kind of revenue split. Something like the App Store does. Some people will never pay for anything, and that's OK. We like them too. But this has the potential to open up new revenue streams for the company behind Alfred — which would be good for their business.

 

So based on that, no, there are no "cuts" because the team behind Alfred would be charging for something you're not providing — or, only provide because Alfred exists in the first place. It's a symbiotic relationship. Even then you made the choice to open-source your libraries under the quite liberal, and commercial-ready MIT license.

 

And no spying, of course. I want Alfred to be a better product, not a worse one.

 

On 9/28/2019 at 5:12 PM, deanishe said:
On 9/28/2019 at 2:58 PM, skyzyx said:

These don't feel like unsolvable problems.

 

No problem feels unsolvable if you haven't given it any serious thought…

 

Don't be a dick.

 

I recognize the massive contributions you've made to this community, and I am very appreciative of them. Your merit in this community brings a lot of weight to your words. I know that you disagree with some of the things I've suggested, and that's fine. I'm an adult, and people are free to respectfully disagree with each other. I care about this community and this product a lot as well, and that's why I took the time to speak up and offer ideas and suggestions for how I think it could be made even better.

 

I don't know what formal relationship you may have with the team behind Alfred, but I spent quite a lot of time thinking about how to make Alfred even better, and I think that at least some of the ideas I've presented warrant a bit more consideration than I feel you've given them. I'm providing suggestions in good faith that they will at least be considered. If ideas you don't personally like aren't even given the proper consideration, then what reason do users have to continue to make suggestions?

 

…that question was rhetorical — in case it wasn't clear.

Edited by skyzyx

Share this post


Link to post
Share on other sites
Posted (edited)

 

5 hours ago, skyzyx said:

I'm a real user, who is a very experienced developer, who provided some ideas for how to make the product better in my opinion.

 

I understand that. And as a very experienced workflow developer, I'm providing my feedback on those ideas.

 

5 hours ago, skyzyx said:

Better is good, and I'm happy to hear it's coming. But the "all-singing, all-dancing" bit of sarcasm was unnecessary.

 

I wasn't being sarcastic … that comment wasn't aimed at you in any way. My only intention was to express to anyone reading that Packal Plus isn't on the horizon.

 

5 hours ago, skyzyx said:

I haven't come up with a solution (yet), but you can't fix a problem that you don't know about — which is why I'm bringing it up.

 

The Alfred team, along with most active members of the community, are well aware of the state of things. The problem is—as you note—the lack of an obvious solution.

 

5 hours ago, skyzyx said:

This is called a strawman argument, wherein a strawman version of the issue is attacked instead of addressing the real issue. So let's start over.

 

It's not a strawman argument. It's actually aimed at the underlying cause of the whole "missing runtime" problem: workflow developers requiring non-standard runtimes.

 

And how I think tacitly encouraging it is a bad idea.

 

5 hours ago, skyzyx said:

I felt I was extremely clear in providing a suggestion that was just shy of writing the code for it for how it could work.

 

At a very high level, yes. But you didn't consider the details of how your hypothetical setup/install script would work, or the problems it would cause due to different workflows inevitably trying to install different (versions of) things in the same places.

 

I don't know how closely you follow the forum, but Andrew doesn't add features that he thinks will lead to a lot of support requests.

 

And if your workflow installs Python 3 via Homebrew and mine then overwrites it with an official Python installer, the Alfred team will get the support request because it will appear to the user that Alfred's setup wizard—not my install script—broke their favourite workflow. For better or worse, that's how it will go down.

 

Unless someone can come up with a basically bulletproof solution, or there's a sea change in the Alfred team's philosophy, a setup wizard that handles non-standard/unofficial dependencies seems extremely unlikely.

 

5 hours ago, skyzyx said:

Also, I've mentioned this multiple times now, and your responses seem to continually ignore it

 

No, I did address that point:

 

On 9/28/2019 at 11:13 AM, deanishe said:

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.

 

5 hours ago, skyzyx said:

I'm thinking in terms of dumping buffers in a defined format, or HTML's Server-Sent Events, or even JSON Patch (RFC 6902)

 

JSON lines would be a much more appropriate choice for STDOUT, which Alfred already uses and is already a stream.

 

5 hours ago, skyzyx said:

being able to push updates to the Alfred's Dropdown UI, live.

 

I appreciate the utility of the feature. I'm interested in how you think it can be implemented in a practical way. It has limitations, which I pointed out above, that using rerun doesn't. The main practical difference is that using rerun is a bit fiddly to do.

 

5 hours ago, skyzyx said:

While it is true that those success stories are all big companies

 

What they have in common is that they provide access to content/services on an ongoing basis. It's not a model that is directly applicable to locally-running software.

 

5 hours ago, skyzyx said:

Firstly, you have provided zero evidence to support your claim that the pricing model I've proposed is widely despised.

 

Heh. You can't seriously expect me to believe you didn't notice the massive outcry and exodus when TextExpander moved to a subscription model.

 

5 hours ago, skyzyx said:

Users would (per my hypothesis) be willing to pay a small/reasonable amount on a regular basis for the curated, easy-to-use storefront.

 

An interesting idea. Do you have any examples of comparable services?

 

5 hours ago, skyzyx said:

 

Fair comment. It was rude of me. Sorry.

 

5 hours ago, skyzyx said:

I think that at least some of the ideas I've presented warrant a bit more consideration than I feel you've given them.

 

Please don't think I haven't thought about them. In most cases, I think the ideas are sound in and of themselves. It's just that I don't think they're very compatible with the underlying philosophy of Alfred (which I have internalised over years of having my own feature suggestions rejected).

 

Anything that reduces Alfred's performance/efficiency (such as scheduled background jobs, or the oft-requested blacklisting) is more-or-less off the table. As is anything with the potential to cause a lot of support requests. I'm fairly certain that Andrew views external dependencies rather as something to be avoided, not leveraged.

 

I have absolutely no idea about the desirability or practicality of expanding the Alfred team. I can say, however, that the Alfred team have always been supportive towards community members building tools for the community.

Edited by deanishe

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...