Docs/UI improvement: List Filter Input - why is there an object argument?

[niels_bom]

Problem description

 

It took me little while to figure out why List Filter Inputs (LFIs) can be configured to have arguments.

 

To be clear: I'm not talking about the `arg` of the items in the list.

I am talking about the "Argument Required"/"Argument Optional"/"No Argument" setting of a List Filter Input.

 

 

As I understand it:

- When a List Filter Input has no argument: all items in the list are displayed and the user can not filter the displayed items. They can only select an item.

- When a List Filter Input has an optional argument: all items in the list are displayed initially, the user can type text after the keyword of the LFI so it will only show items matching the typed in text.

- When a List Filter Input has a required argument: no items from the list are displayed, matching items will appear when they type text after the keyword of the LFI.

 

However: when a Hotkey Trigger is used to trigger an LFI that has the option set to "No Argument" it somehow is possible to type-to-filter items in the list.

 

In Hotkey Triggers and Keyword Inputs an argument is something that's passed to the next workflow object. Which is entirely not the case for the argument in LFIs.

In a Script Filter Input this setting is similar, but there the argument is used as an argument to the Script.

 

To summarize:

1. I think calling this option "argument" for LFIs is confusing because the value is not used as an argument, it's only used for filtering the items in the list.

2. The option to have a required argument is strange: why would somebody want to build a workflow which is not forthcoming with the available options? (if there's a lot of them it should be a Script Filter Input). I don't see a valid usecase for this.

 

 

Suggested improvements

As a quick fix I think the documentation should state something like:

Quote

The argument option can be set to "Argument Optional" if you want the user to be able to filter the list of items by typing. If you want to disallow text-filtering set it to "No Argument". The setting "Argument Required" will be removed in a future update, we advise against using it.

 

The value of the argument the user types in is not saved or passed on to the next object in the workflow.

I think the UI can be simplified by removing this option altogether and having the LFI always do filter-by-typing. I don't see any valid use cases for the other settings.

If you're an Alfred developer and want to talk about this, feel free to contact me for a call.

[niels_bom]

Ah just discoverd another weird thing:

 

When I have a List Filter Input and it's triggered by another object that passes an argument (an Arg and Vars Utility for example) strange things tend to happen.

 

The argument from the previous object is passed in even though the LFI disallows it.

 

[Andrew]

The keyword option only relates to the use of the List Filter in Alfred's default results. In this respect, the keyword's argument options relate to the typed argument after the keyword, which ultimately filters the list items.

 

I have a number of my own workflows which use the "Argument Required" option, and we have seen countless perfect uses of all 3 unique options to create the associated desired behaviour. As such, we won't be recommending people not to use this option, or indeed, removing this option in the future.

 

The behaviour when opening the list filter from an upstream connection (e.g a hotkey, or chaining objects) will always be a search field dedicated to the list filter. If this is the only way you're using the List Filter, you can leave the keyword blank and ignore the keyword's options.

 

Having said all that, you make a fair point that the documentation for this could be improved.

 

Cheers,

Andrew