Add a version field for workflows

[vrtcl1dvoshun]

Need the ability to add a version field to keep track of workflow changes and prevent updates from wiping out user customizations.

 

If not, then I suggest developers at least add their app's version to its name as follows: "My Alfred Workflow (2.3)" which would remain consistent with the way Apple denotes different app versions. The version number should show up in both the filename of the workflow and in the name that is seen in Alfred's workflow preference pane.

[vitor]

If your concern is wiping user data, then you’re thinking about it wrong. Settings shouldn’t be kept inside the workflow’s directory for this exact reason, you should use the appropriate directories (~/Library/Application Support/Alfred 2/Workflow Data/ and ~/Library/Caches/com.runningwithcrayons.Alfred-2/Workflow Data/). There are some tools (this one is for bash) to make this easy to manage. To keep track of new versions, usually a system like the one implemented by Alleyoop is the way to go (try Monkey Patch for this).

[vrtcl1dvoshun]

While you've provided good advice, I'm not a developer. I just want to use the workflows that have been made available and not have to scour the internets for updates. Not every workflow has been setup with this process. As I see it, there needs to be a standard for:

• where you keep user settings
• for updating the workflow
• for finding new workflows
• documenting what the workflow does
• documenting what needs to be changed in the workflow (i.e., user home folder, username, etc.)
• what version the workflow is currently at (visible in the Alfred preferences pane)

I'm sure others could add to the list. My biggest frustration is that I feel like the developers of Alfred didn't forsee the collaborative community that would develop around workflows. As it currently stands, there is a forum (a forum!) that is being used to post workflows and their issues, feature suggestions, updates, etc. What an incredibly ineffective and inefficient means of communication for the development, support and distribution of workflows!

 

You mentioned Alleyoop. From what I've gathered from the forum and its original developer, phyllisstein, it is deprecated. When I tried Monkey Patch, the vast majority of workflow had the error "Could not check for updates." Hear me when I say that I'm not criticizing either developer—they've performed the work on their own time and no other person that comes up with a workflow is required to use their system. A workable solution here should come from the developer and the developer only—this will ensure that others can be confident in their using it.

 

Since there is no point in continually remaking the wheel, there needs to be an accessible and user friendly central repository from which any user can browse, download and update any workflow or theme. The repo should allow user feedback and submission of bug reports. It should be searchable and up-dateable from Alfred's interface. It should allow contribution from those who want to contribute. GitHub could be a fine answer to all these suggestions; perhaps there is something else, but IMHO any solution is better that what we currently have.

Edited December 5, 2013 by vrtcl1dvoshun

[vitor]

While you’ve provided good advice, I’m not a developer.

Which is probably why you’re not seeing the limitations of some suggestions.

• There is a standard for where to keep user settings (the directories I pointed out).
• There is a standard for updating workflows — the Alleyoop way. It’s an unofficial standard, but it is the most used one. If you read the first lines of Alleyoop thread, though, you’ll see mentioned that an official standard is on the way.
• There is a (again unofficial) place to find workflows, alfredworkflow.com (currently down).
• Most developers hate writing documentation, so the ones who do usually will do it the way that is most convenient to them, having to adhere to a predefined way is a sure fire way to have less documentation. Workflows can do a huge array of things, documenting one is like documenting any other app, you cannot have a good standard for this, because each one is (can be) so different from the other.
• Similarly, what needs to be changed is a different process with every workflow, you cannot have a standard for something that is so different each time.
• Some workflows show the version with the name, others do not, it’s the developer’s choice, even if there’s a field available to input the version, I guarantee a lot of them will be left blank, similarly to how many of them lack a Bundle Id, even though the field is there. Versioning is not exact, there isn’t even an absolute standard on how to version changes (there are recommendations, though).

You simply can’t demand those things (well, you can, but won’t get very far), because developers are people, and people with different levels of expertise, time, and commitment. They may not agree, not care, or simply not know how to do certain things. I’ll give you an anecdotal (and personal) example — I’ve stopped posting my workflows on alfredworkflow.com because it’s a hassle; it takes time, and I don’t always remember to do it, which means I have no idea which ones are missing there or which ones have out-of-date screenshots, and I also do not feel like taking the extra time to go through it (I’ve done it multiple times already, and it’s an extremely tedious process), I want to build and share more workflows, not spend all my time making sure they’re all up-to-date on every third-party reference site, so I have chosen a few places where I’ve committed to keep them updated. Don’t forget that most workflows are free, and developers build them for themselves; sharing them and updating them with feature requests also takes time.

You cannot have a “central repository from which any user can browse, download and update any workflow or theme, [that allows] user feedback and submission of bug reports, [in addition to allowing] contribution from those who want to contribute”, because you cannot make developers work a certain way. Not every workflow developer has a github account, not every one posts their code there, and not everyone will want contributions. That’s a way too utopic view. Workflows are like other apps, each developers shares them the way they feel its best for their workflow — what you’re suggesting would be akin to having a central repository for every OS X app for discussion and collaboration; it cannot be done, not in any official capacity, as not everyone will like that central repository or the way it works (case in point, just look at the amount of linux distros, everyone as something to say, and a little tweak to do), so it couldn’t be complete and we’re back to square one, thats why every developer picks their own way of sharing the workflow.

I’ll end by pointing you to the workflows best practices thread. It starts off with “This thread will serve as reference for a list overall "best practices" when creating workflows for Alfred 2. This will be an evolving document, so check back occasionally for updates”. So it’s a place where your ideas will be welcomed for discussion, and given greater weight.

I hope I’ve been clear in my points. Let it be noted that I’m not disagreeing with you, quite the contrary — there should be standards for things, we should be adhering to them, but developers are human beings, and making users adhere to a certain way of doing things is no easy feat.

Edited December 6, 2013 by Vítor

[vrtcl1dvoshun]

@Vitor

 

Thanks for the informative reply! To further clarify my thoughts, while I certainly don't expect for every single workflow out there to be contributed to a central repository (I imagine there'd be an issue in dealing with pseudo-redundancy), I do maintain that there should be an official (as in blessed by the developers of Alfred) means to do those things I've already mentioned. As it currently stands there isn't. I imagine it to be in their interest to at least make it an option. A point you already made best states the reason:

 

"I want to build and share more workflows, not spend all my time making sure they’re all up-to-date on every third-party reference site"

 

I understand that people don't always want to adhere to an opinionated way of doing things, but a little opinion goes a long way in increasing the productivity of everything that we do. After all, we do both use an opinionated operating system with good reason.

[vitor]

After all, we do both use an opinionated operating system with good reason.

Right on the money.

 

I do maintain that there should be an official (as in blessed by the developers of Alfred) means to do those things I've already mentioned.

I agree, although sadly I think it’ll take a while. Alfred hasn’t got a big team of developers behind it (which is in many cases an advantage), and those are complex problems. Like I mentioned, the workflows best practices thread might be a good place to suggest changes that are not technical in nature.

[Andrew]

Just to add my few pence to this conversation... all of these issues is something that I'm very much aware of and something I definitely aim to facilitate improvements in the future

[Adrian]

You cannot have a “central repository from which any user can browse, download and update any workflow or theme, [that allows] user feedback and submission of bug reports, [in addition to allowing] contribution from those who want to contribute”, because you cannot make developers work a certain way. Not every workflow developer has a github account, not every one posts their code there, and not everyone will want contributions. That’s a way too utopic view. 

 

Actually I think that is not utopic at all. Central repositories works very well for a lot of other projects, but that does not mean that every one *has* to use them.

 

If you write a plugin for WordPress you could post it anywhere you like, but there also is a central repository on wordpress.org where you get the benefit of easy installation, automatic updates, comments and reviews etc, and it is a single official site that all users looking for plugin can use and it is integrated in WordPress. It works really well.

[vitor]

Actually I think that is not utopic at all. Central repositories works very well for a lot of other projects, but that does not mean that every one *has* to use them.

 

Exactly my point. Notice the repeated use of “any” and “every” on the original request and my reply.

The original complaint stated

 

(…) Not every workflow has been setup with this process.

 

(…)there needs to be an accessible and user friendly central repository from which any user can browse, download and update any workflow or theme. (…)

[emphasis mine]

My argument is exactly that you cannot impose this on every case, for every workflow — that is utopic.

[deanishe]

Actually I think that is not utopic at all. Central repositories works very well for a lot of other projects, but that does not mean that every one *has* to use them.

 

If you write a plugin for WordPress you could post it anywhere you like, but there also is a central repository on wordpress.org where you get the benefit of easy installation, automatic updates, comments and reviews etc, and it is a single official site that all users looking for plugin can use and it is integrated in WordPress. It works really well.

There's Packal, which is the de facto central repository for workflows. Shawn, the creator, is also working on a workflow to automatically update any workflows that you've installed from Packal (you have to submit a version number when you upload one to Packal). For the time being, I wrote a workflow to search Packal, which can also tell you which of your workflows are updateable.

Ideally, Packal would be "advertised" more clearly on this board: a forum is really not a great platform for showcasing/discovering workflows (or collecting tutorials/documentation etc.).