Hide options after setup complete?

[mikejandreau]

I feel like I've seen other workflows do this, but I can't find one to copy from.

 

Here's what I'm after: the workflow I'm building offers a "setup", where it asks users questions that they answer, and then the info get stored in variables.

 

Each step of that setup is using a keyword (so if they want to jump right to a specific step, they can). What I'd like to do is after the first time setup is completed to hide those options if someone types in the keyword again.

 

The reason I want to do this is that I've set the keywords to similar words to other keywords I'm using in the workflow (ie; "away" triggers an Away message, but "awaysetup" is the keyword to set that message in the variable). So, ideally, after setup is complete, if I type "away", I wouldn't see the option for "awaysetup" in Alfred.

 

Here's my workflow (happy for any other input on anything I've done terribly!) for those who want to take a peek: https://www.dropbox.com/s/k2tk3vnu7tpdxfd/Change Slack Status %26 Play%3APause multimedia.alfredworkflow?dl=0

 

Its purpose: update Slack status to a specific status message, set away mode, and pause music/video & mute my computer when I leave my desk. 

Then "undo" it all when I'm back.

 

It's the "statussetup" section I'd love to hide from Alfred seeing it once it's been completed the first time. 

 

If that's possible, I'd love some guidance.

If what I said makes no sense, I'm happy to clarify!

[deanishe]

One way would be to use variables for your keywords (i.e. your Keyword/Script Filter's keyword is {var:keyword_step_1}), then use Alfred's API to clear the variables as the steps are completed. That way, the elements would be uncallable.

[vitor]

The issue with removing setup options is that users don’t have a clear path to change their setup later on.

The way I do it in my Workflows is to prefix those with :. That way they don’t appear during normal Alfred usage and all Workflow setups are bundled together.

[deanishe]

22 hours ago, vitor said:

users don’t have a clear path to change their setup later on

 

Yeah. The normal way to do this would be to have your workflow's entry point(s) check if setup is complete and show an option to start/continue setup if not, rather than editing themselves. The problem with the latter is that any changes the workflow has made to itself are overwritten on update (though variables are preserved, which is why I mentioned that as a possible method).

 

If you want a wizard-style setup that walks the user through the setup, I'd put that all in a single Script Filter that jumps to the specific step based on which variables are already set.

 

And in any case, you should probably have some way to go back to the setup—ideally a way that allows the user to change any of the settings without going through the whole thing (or at least without having to enter everything again)—provided that makes sense for your particular workflow.

 

That could be an item in the workflow's settings view (if it has one), a Script Filter/Keyword with an unusual prefix (as Vítor recommends), or a "magic" query hooked up to your setup view, e.g. if the user enters workflow:setup (for example) as a query, that triggers the setup view. My workflow libraries use this method to provide a bunch of utility functions for free (open the workflow's log file or data/cache directories, clear the cache etc.), and you can add your own hooks to call your own functions without having to add your own elements to the workflow.

[deanishe]

The workflow looks pretty good (though I can't run it because I don't use Slack). Cool that you've added Alfred Remote support.

 

But as with anything worth paying attention to, I have some feedback  The first point is important, the others much less so:

 

Don't use tell application "Alfred 4". Use tell application id "com.runningwithcrayons.Alfred" instead. The "Alfred X" was necessary for all earlier version of Alfred, and it meant every new version of Alfred broke your workflow (and it's a PITA to write a workflow that works with multiple versions of Alfred). From Alfred 4 onwards, workflow directories and so on should stay the same, so if you use id "com.runningwithcrayons.Alfred" instead, your workflow will keep working with Alfred 5 etc. without your having to change anything.

You have a lot of keywords in there. It would be a good idea to give them a common prefix (e.g. slack <keyword> or .sl <keyword>) or collect them (also) in a common Script/List filter. A lot of the keywords are rather generic (status, gone, dnd) with generic icons and generic descriptions "Do not Disturb". That's perfect for Alfred Remote, where they'll all be on a "Slack" sheet, but in Alfred, they're all in the global "namespace", which lacks that important context, so there's no obvious connection to Slack. Alfred's built-in help (keyword ?) isn't much use, either: searching for "slack" doesn't show any of your workflow's keywords (this is a problem with Alfred's search, not your workflow). As such, the workflow's functionality isn't very discoverable. Unless I'm using it constantly, I'm not going to remember the keywords, and I'm not going to be sure whether the item I'm looking at is part of your Slack workflow (there aren't even subtitles that say "Do XYZ in Slack").

You might want to consider putting your code in external files rather than in Alfred's Script boxes. Alfred isn't a very good code editor, and if you share your workflow on GitHub (or similar), it's hard to make sense of commits or pull requests when all the changes are to info.plist.

Finally, it's generally preferable to use with input as argv rather than with input as {query} where possible. It doesn't require Alfred to rewrite your script every time it runs it (faster), and {query} is rather error-prone, as the escaping options are very difficult to get right (yours are technically not correct, but shouldn't cause any problems in practice). I suspect {query} will be removed (or at least deprecated) in a future version of Alfred.

[mikejandreau]

Thanks for the feedback, everyone.

 

I think I'm going to go with the simpliest option of prefacing the setup options with :

 

I'm also going to consider making some changes @deanishe suggested around the keywords and using external files and whatnot. I already made the change to the "tell application" stuff.

 

Thanks again!