Add option to 'Duplicate and Update'

[nikivi]

I opened an issue some time ago : 

 

 

Where my issue was that making some changes to the workflow like adding an external trigger that the author did not include in his/her workflow would get erased on updates. In my case, I usually add external triggers to workflows where the author did not include them.

 

So what I am forced to do when I see an update prompt, is cancel it, then manually duplicate the workflow, then update, then transfer my external triggers (or other objects I made). 

 

I wish Alfred added an option to `Duplicate and update` which will duplicate the workflow being updated, and then go on and grab the update. Then it would at least be easier to quickly go to the duplicated workflow and transfer the objects I need. And then deleting the duplicate workflow.

Edited September 27, 2017 by nikivi

[nikivi]

Another thing I've been thinking of on how to solve this annoying problem is if we could somehow toggle certain objects to persist on changes. 

 

So updating the workflow will update everything and all the objects but not the objects that user chose to keep. 

 

Although that seems overly complex and is bound to cause many problems. So I think Duplicate and Update solution is the best there is for this kind of problem.

 

I really really hope you consider adding it. Thank you. 

[deanishe]

4 hours ago, nikivi said:

bound to cause many problems.

 

This.

 

4 hours ago, nikivi said:

Duplicate and Update

 

I'm sure the current behaviour is annoying, but as with your Searchio! PR, I very strongly suspect that you are the only person for whom this is a problem worth mentioning.

[nikivi]

I do think though I am not the only one who feels this is a problem. As in the thread linked above, there are other people for whom updates that erase their own objects they use to personalise someone's workflow getting erased with each update is annoying.

 

For example even in Searchio workflow, I have objects like this that I add : 

 

 

Those too get erased with each new update. I understand that keeping track of user changes to workflows and have the updating work is impossible. 

 

But I do ask to please consider adding the Duplicate and Update feature as that for me would at least solve this problem and save me a lot of time in the process.

 

Thank you.

 

 

 

[deanishe]

5 hours ago, nikivi said:

As in the thread linked above, there are other people for whom updates […] is annoying.

 

That's a pretty large misrepresentation of the thread. You posted it, and the only other person who expressed an opinion was @dfay, who said it's not really a problem.

 

5 hours ago, nikivi said:

in Searchio workflow, I have objects like this that I add

 

As I said in your PR, Searchio! is absolutely meant for users to add their own elements. That's exactly why I try to avoid pushing updates.

 

5 hours ago, nikivi said:

save me a lot of time in the process.

 

Again, I think you're misrepresenting the scale of the problem. Firstly, it really only seems to be an issue for you, as nobody else appears to habitually add External Triggers to everything. Secondly, it takes literally a few seconds to create a duplicate yourself. Unless you're updating many workflows every day, "a lot of time" is a gross exaggeration.

 

Sure, it would be a useful feature to have on occasion, but let's not exaggerate how large of an issue it really is. Workflows based on my libraries don't download updates unless you explicitly tell them to, and OneUpdater saves new versions in ~/Downloads. So it's not like it requires more than literally a few seconds' effort on your part to create a duplicate and then perform the update.

 

Certainly, it takes much longer to copy your Triggers over and reconnect them.

 

Edited September 27, 2017 by deanishe

[vitor]

18 hours ago, deanishe said:

I very strongly suspect that you are the only person for whom this is a problem worth mentioning.

 

Agreed.

 

12 hours ago, deanishe said:

as nobody else appears to habitually add External Triggers to everything.

 

And on your (@nikivi) Workflows, it might be that people don’t have such a nicer time setting them up. The most used triggers (i.e. non-External) are empty, which means users need to set them up on first use. Sure, in theory it’s less work in the long run, but in practice, considering the number of users preferring each type of trigger, it might be a worse experience overall.

 

12 hours ago, deanishe said:

As I said in your PR, Searchio! is absolutely meant for users to add their own elements. That's exactly why I try to avoid pushing updates.

 

What if your update mechanism recognised pre-releases, and didn’t download/warn about those by default? That way you could still release small fixes that you deem nice but not important enough to disrupt current users, and those os us who don’t add extra nodes could still get them.

[nikivi]

1 hour ago, vitor said:

The most used triggers (i.e. non-External) are empty, which means users need to set them up on first use. Sure, in theory it’s less work in the long run, but in practice, considering the number of users preferring each type of trigger, it might be a worse experience overall.

 

I agree. But now all my workflows have a keyword trigger. And I solved the annoying problem of not having a clean prompt for myself with a JSON utility to strip title and subtext so everyone is happy. ?

 

I suppose @deanishe is right and updating does not happen all too often and manually duplicating workflows that are affecting my custom set objects is not so bad. But it would be quite cool if Alfred to offer such feature for painless transfer of customisations. I know you can cancel the update, right click on the workflow, duplicate it and then run the workflow again for the update prompt and then download the update. But one button option that does all that for you would still be quite nice.

 

And transferring triggers and objects after is not so bad since I set them up with a purpose so they are worth it for me.

 

I mean I can't be the only one customising workflows made by other people. I have my own quirks like loving to lowercase everything and adding external triggers to call from Karabiner, but I can't be the only one to have something like that.

 

But the customisations can also fundamentally change workflows too like in example with GitHub jump where I augment it to go to different parts of the repo based on modifiers : 

 

 

I just don't see how a feature like that would actually subtract from Alfred's user experience. It would only make it better, even if for few people like me.

 

 

 

Edited September 28, 2017 by nikivi

[deanishe]

1 hour ago, vitor said:

What if your update mechanism recognised pre-releases, and didn’t download/warn about those by default?

 

That's precisely how it works.

 

2 hours ago, vitor said:

That way you could still release small fixes that you deem nice but not important enough to disrupt current users

 

The problem is it disrupts me. I use the workflow a lot, and I don't like messing up my own configuration to make it ready for release  

 

55 minutes ago, nikivi said:

But one button option that does all that for you would still be quite nice

59 minutes ago, nikivi said:

I just don't see how a feature like that would actually subtract from Alfred's user experience.

 

It's not that it wouldn't be a beneficial feature, it's that it would require Andrew to spend his finite time implementing it. Time that could be better spent on features that are more useful to more people.

 

56 minutes ago, nikivi said:

I mean I can't be the only one customising workflows made by other people.

 

You're not. But pretty much everyone else sticks to changing keywords and hotkeys, which are preserved on update. Adding External Triggers to everything is a behaviour that appears to be exclusive to you.

 

1 hour ago, nikivi said:

But the customisations can also fundamentally change workflows too like in example with GitHub jump where I augment it to go to different parts of the repo based on modifiers

 

That's precisely the kind of thing you should submit a PR for. It would be useful to very many users of the workflow.