Workflows Best Practices

[CarlosNZ]

Did you intend to post this in this thread?

Yeah, sorry, I know it's off topic, but I was just replying to a query that came up regarding one of my workflows.   

[RevellNL]

If a workflow gets updated, is the Data Storage directory then wiped clean?

[jdfwarrior]

If a workflow gets updated, is the Data Storage directory then wiped clean?

 

No sir, that's why a folder outside of the actual workflow folder is recommended to be used.

[deanishe]

How do you guys and gals go about developing a workflow? Do you keep your code in your normal code directory and symlink it to Alfred's workflow directory?

 

Or do you code in the workflow directory and then copy the files manually into a separate directory with source control?

 

I've been trying the former, but it's causing problems with Dropbox syncing and git.

[derfla]

I code in the workflow directory and this is also my git directory. So I have one directory only.

And if I push to github, a WebHook on my website is called automatically, which generates the new workflow file from source. Then all the users of my workflow will get an update message the next time they use the workflow, and after confirming the workflow will be updated automatically.

 

So I don't have to copy between directories or export and upload new versions. I only have to develop in the workflow directory and to push to github.

[deanishe]

I suppose it wouldn't be a problem having the screenshots and Readme in the workflow (I've been writing a separate help file). I guess I'd end up having the generated .alfredworkflow in there, too, as I use GitHub as the download location, too. I'm not so sure that's a great idea, though.

 

Have you had any problems with .git directories in Dropbox? I don't think I'd like to try sorting out and Dropbox conflicting files in the git objects database.

[deanishe]

This is very similar to how OS X works in that you have apps which don't change and a storage area for preferences and support files. When the app (or in Alfred's case, workflow) is upgraded or updated, the source app or workflow can cleanly be replaced without changing settings.

 

Having said that, I appreciate that syncing workflow settings is desirable and have added a note to have a good think about this after Alfred has been released

 

I've been thinking about this (it would be great to be able to sync things like API keys across machines).

 

Could there not be an Alfred.alfredpreferences/workflow-settings subfolder in the Dropbox in which workflows can create folders named after their bundle id much like the cache and data directories?

 

It wouldn't need to be actively supported by Alfred in any way (just a convention). Alfred would just need to not delete it. Dropbox takes care of the syncing, and a workflow's files will always be at ../../workflow-settings/my.bundle-id relative to the workflow's directory.

 

Dropbox/Apps/com.runningwithcrayons.Alfred/my.bundle-id would be a more Dropbox-like alternative if syncing workflow settings, but not workflows or preferences, is desired.

 

It certainly seems to be a much cleaner solution than keeping user data in the workflow directory itself. That would probably need a specific directory name (e.g. config or settings) that Alfred knows about and would have to be careful not to overwrite when upgrading workflows.

[derfla]

I suppose it wouldn't be a problem having the screenshots and Readme in the workflow (I've been writing a separate help file).

 

I think so too. But my auto-release script removes some files before generating the .alfredworkflow file.

 

Have you had any problems with .git directories in Dropbox? I don't think I'd like to try sorting out and Dropbox conflicting files in the git objects database.

 

I don't use Dropbox syncing, so I can not help here.

[deanishe]

I went with your advice, sort of. I'm still keeping the code in a subdirectory because I need to put the .alfredworkflow file in there, too.

 

But I wrote a build script that excludes the files I always forget to delete, and an install script that can symlink the workflow to Alfred's workflow directory when I'm working on it and install it properly when I'm not.

[deanishe]

Might I also add here, for Workflow authors, that using an external script file, rather than writing a script in the provided text box, may make debugging significantly easier for users (and yourself).

 

It's considerably easier to run an external script in Terminal with an argument than copy an embedded script to a new file, emphasising that it has to be a (likely UTF-8 encoded) plain text file, not a Pages/Word document, replace {query} with an argument, save the file, and then run it from Terminal.

 

When Alfred's debugger arrives, it will still be simpler to debug an external script, due to having line numbers that correspond to line numbers in your editor.

 

What's more, at least in the case of Python files, Unicode characters inserted into embedded scripts by Alfred are often not the same (in terms of normalisation) as those passed as script arguments, so testing a script in Terminal and then pasting it into the Script text field may result in "Heisenbugs".

Edited February 6, 2014 by deanishe

[deanishe]

More of a UX thing, but it's a behaviour I think is great and have used in all of my workflows since I saw it in Carlos's Recent Items workflow. It's similar to the way Alfred's filesystem navigator works.

A lot of workflow use "multi-level" queries using a symbol as a delimiter, e.g. keyword level1 ➣ level2 ➣ [query].

When you reach a new level the query typically looks like this, "keyword level1 ➣ level2 ➣ " (note the trailing space), ready for the user to enter a query. What Carlos's workflow does (and now also mine, cos it's awesome!) is back out to the previous level if the user deletes that trailing space, so hitting backspace on the above query would take the user back to "keyword level1 ➣ " (again with a trailing space).

I think this makes a workflow much easier to use (if it's appropriate, of course), and it's pretty simple to implement (if query.endswith(DELIMITER): call_alfred_via_applescript_with_query(previous_level)).

What do you guys and gals think of it?

[Tyler Eich]

More of a UX thing, but it's a behaviour I think is great and have used in all of my workflows since I saw it in Carlos's Recent Items workflow. It's similar to the way Alfred's filesystem navigator works.

A lot of workflow use "multi-level" queries using a symbol as a delimiter, e.g. keyword level1 ➣ level2 ➣ [query].

When you reach a new level the query typically looks like this, "keyword level1 ➣ level2 ➣ " (note the trailing space), ready for the user to enter a query. What Carlos's workflow does (and now also mine, cos it's awesome!) is back out to the previous level if the user deletes that trailing space, so hitting backspace on the above query would take the user back to "keyword level1 ➣ " (again with a trailing space).

I think this makes a workflow much easier to use (if it's appropriate, of course), and it's pretty simple to implement (if query.endswith(DELIMITER): call_alfred_via_applescript_with_query(previous_level)).

What do you guys and gals think of it?

 

This method is certainly applicable in many situations, but I tend to dislike interfaces that call Alfred via AppleScript while I'm typing. They make the UI flickery; it feels too much like a hack.

[deanishe]

Yeah, the UI "flicker" is definitely unpleasant, but I think that, on balance, one keystroke and a bit of flickering is preferable to having to hit backspace a whole bunch of times.

And it does allow you to write much cleaner code when you don't have to worry about truly serpentine queries.

Still, I tend to prefer the pragmatic over the pretty.