Show “no results found” on Alfred Filters Results

[vitor]

Here’s an example from a Workflow whose “Alfred filters results” is checked in the Script Filter, and no results are found:

And here’s the result from a Workflow whose “Alfred filters results” is unchecked in the Script Filter, and no results are found:

In the second case I’ve added a conditional that, when no results are found, produces a single invalid (can’t be actioned) result, informing the user. To me, this is an important feature because it:

• Informs the user their command ran successfully.
• Informs the user what was the query that ran. This is particularly useful when queries are slow to run (contacting a server) and you’re not sure if it’s failing for the previous query (so you should wait), or the latest one.
  

In contrast, the first example is indistinguishable from a Workflow error. Sometimes when I get that result I purposefully type something else or check the debugger on my own Workflows to make sure nothing is broken.

So my feature request: when “Alfred filters results” is checked in a Script Filter and it produces no results, output a message informing the user. Something generic like ““{{whatever query}}” produced no results” would suffice.

[deanishe]

Bump.

 

On 9/14/2017 at 10:24 PM, vitor said:

In contrast, the first example is indistinguishable from a Workflow error.

 

This is the real problem, imo. I'd sooner see Alfred include a result saying that workflow XYZ has failed (which opens the debugger for that workflow when actioned). Silently ignoring errors is confusing and leads to "it doesn't work"-style bug reports because the user has absolutely no idea what's going on.

 

I see this error/no-results ambiguity as a fairly serious usability issue. There are sound reasons for Alfred to not report that no results were found, but the ambiguity encourages workflow authors to negate them by adding logic to show a "no results found" item because it's fundamentally more reliable than trying to show a "workflow error" one.

 

A user might not be able to fix a workflow that's throwing errors, but they should be informed of it so that they can report the issue or disable/uninstall the workflow and stop Alfred wasting cycles running broken code.

[Andrew]

I actually missed the original feature request, I think this is a pretty reasonable addition to Alfred. There could be 2 options along the lines of "show x result for no results" with no action, and "show workflow error as result" which opens the workflow editor.

 

I'd be happy to hear any further input on this!  

[deanishe]

For my part, I'd be happy with a global "show workflow errors in results" option.

 

I generally consider returning a "no results found" item to be bad behaviour because I'm breaking Alfred's fallbacks for the user when I do it. But I do it anyway because I consider it better than the no-results/error ambiguity that you otherwise have.

 

My libraries contain code to catch and display errors in Alfred's results, and AFAIK most people use that facility, but it can't catch all errors, especially in Python.

 

I think this is a relatively common thing for workflows to do.

[vitor]

4 hours ago, Andrew said:

show x result for no results

 

The suggestion here seems to be that we’d be able to configure the message for when no results are returned. While I’d welcome that, I’ll also point out I don’t find it a dealbreaker—a generic No results found for “{query}” would suffice. I do think showing the {query} in the message is a must, so the user is certain what they typed has finished running.

 

3 hours ago, deanishe said:

For my part, I'd be happy with a global "show workflow errors in results" option.

 

I’m of the reverse opinion. Showing a message when the Workflow was successful but returned no matches is clear: do something else. Showing nothing can always be interpreted as an error, even if you know there’s error handling.

 

I’m not saying I think the option to show a result on error isn’t useful—it is. My point is that if we could only have one, I wouldn’t pick that.

 

3 hours ago, deanishe said:

I generally consider returning a "no results found" item to be bad behaviour because I'm breaking Alfred's fallbacks for the user when I do it.

 

That’s a good point that I hadn’t considered (I don’t use fallback searches). That said, I wouldn’t change my method anyway because like you I consider the clarity of “there were no results” to be worth the tradeoff. Adding the show x result for no results option could fix that, because if Alfred knows there are no results, it can show both “No results found” and the fallback searches.

 

If it does show both cases or only one—at the Workflow developer’s discretion by ticking that box—I have no strong opinion.

[deanishe]

1 hour ago, vitor said:

if Alfred knows there are no results, it can show both “No results found” and the fallback searches.

 

That's a good point. That's the best way then, I guess. Clarity with no breakage.

[Andrew]

Talking out loud here for my future reference back to this thread:

 

Unless the user has specifically selected the workflow, the fallbacks are always (uhh mostly) shown at the bottom of the results regardless when the default "intelligently show fallbacks" option is selected. If a user is choosing a workflow directly (e.g. via hotkey, or selecting the keyword in the default results), then the behaviour is more specific, i.e. it only shows fallbacks when there are no results. I'm possibly happy for that latter behaviour to change, as it has led to potentially confusing behaviour.

[deanishe]

Are these globally-defined behaviours, or can they be selected on a workflow-by-workflow basis?

 

I can think of several situations where they kinda break the workflow or don't make sense. For example, I think showing fallbacks would rarely make sense in a workflow that searches a user's own data.

[Andrew]

@deanishe It is globally defined at the moment, but this could change.

 

There are a few places where it doesn't make sense to see fallbacks, but you still see them. Providing a "No Results" option would fix this while not breaking the default results (where multiple matching workflows could be returning results anyway, including the fallbacks).

[deanishe]

5 hours ago, Andrew said:

There are a few places where it doesn't make sense to see fallbacks, but you still see them

 

Not with my workflows because I always return a "no results" item to make clear that there wasn't an error. I'm just trying to figure out where I can stop doing that.

 

On ‎1‎/‎20‎/‎2020 at 11:06 AM, Andrew said:

Unless the user has specifically selected the workflow, the fallbacks are always (uhh mostly) shown at the bottom of the results regardless when the default "intelligently show fallbacks" option is selected

 

I'm not sure I've understood this correctly. The fallbacks will be shown also when results are returned? If so, there are definitely a couple of workflows where I'd want to disable that behaviour.

 

I don't know about anyone else, but it's extremely rare that I actively select a workflow (Script Filter) when typing in Alfred's query box.