Demo your workflows in a beautiful way

[Florian]

Hey guys,

 

I just made a very simple framework to enable people to demo their alfred workflows in a prettier way than a gif. It's a mockup of alfred all in javascript and CSS, with fake osx notifications and pretend key display. Scripting is very easy and all in json and there is all the callback, timing and looping you might want.

 

Here is the live demo; it should be fully operational. More is coming but feel free to fork it on github already ! 

 

To all those who have somewhat complex workflows, now you can explain in a very simple way. I'm also thinking Packal could integrate this Detailed instructions on github.

 

 

Edited August 14, 2014 by Florian

[Don Dahl]

Hi Florian. This is a bit offtopic, sorry. Can't seem to find the original thread.

I'm wondering if your pirate bay workflow could perhaps support other (private) trackers one day? 

[Florian]

The original thread was deleted. The workflow could indeed be extended to more trackers. You can find the code on github and contribute or send me a private message so tha we can talk about it. 

 

I did have in mind to optimize workflow speed more than anything (and having a single source is a big part of it) and i never really had a use for other trackers. 

[deanishe]

That's a marvellous idea!

 

Not going to consider using it, like, until it works on Safari and Firefox, but I'll be keeping an eye on it.

[Florian]

That's a marvellous idea!

 

Not going to consider using it, like, until it works on Safari and Firefox, but I'll be keeping an eye on it.

 

Then if that's all it takes... There you go It's now up for all browsers. I'm also thinking, when alfred iOS will come out, this could extend to iphones as well but for now it'll do. 

 

I take requests by the way: what does it still need to be useful? 

 

Do you have ideas of workflows that could be well illustrated with that method? It can pause, play in any direction, loop, trigger events at any state...

[smarg19]

This is a wonderful idea, but as for suggestions, there probably needs to be some way to simplify JSON creation. I have only cursorily read over the docs, so I haven't thought deeply about this, but some sort of bridge from .plist to your JSON schema, even if it only gets you part of the way (which is almost certainly going to be the case), would likely increase adoption. I for one will look to implement this. I think it's a great idea and great implementation so far.

[deanishe]

Good idea.
 
Being able to create a skeleton configuration file from info.plist would save a lot of mindless typing.

[Florian]

I don't really see what could be extracted from the info.plist. Could you help me out?

 

Below is what describes a "state" of alfred in my simulation. What in there should come from the plist? 

{
	"alfred": {
		"title": " an input query",
		"icon": "imgs/icon.png",
		"list": [{
			"title": "result 1",
			"sub": "explanation of result 1"
		}, {
			"title": "result 2",
			"sub": "explanation of result 2",
			"selected": true
		}]
	},
	"duration": 1000
}

Edited August 14, 2014 by Florian

[deanishe]

The keywords and corresponding icons with a template for adding the demo output.

 

Stephen's ZotQuery has over 20 keywords. I can't see him entering them all by hand, plus example items.

 

Basically, try to make it as easy as possible to create a demo because the alternative—creating an animated GIF—is pretty darn simple.

[smarg19]

Also, there is at least the potential for writing a script that accepts Alfred's XML. I know that many workflow authors write their scripts separately (not in Alfred's internal Run Script boxes), so for the alfred['list'] items at least, you could parse the XML output of a workflow's filter script into the proper JSON. This would act as a sort of "recorder", making the JSON creation even simpler. You could simply pipe the XML output from one script into the "listener" script for parsing.

Edited August 14, 2014 by smarg19

[Florian]

Also, there is at least the potential for writing a script that accepts Alfred's XML. I know that many workflow authors write their scripts separately (not in Alfred's internal Run Script boxes), so for the alfred['list'] items at least, you could parse the XML output of a workflow's filter script into the proper JSON. This would act as a sort of "recorder", making the JSON creation even simpler. You could simply pipe the XML output from one script into the "listener" script for parsing.

 

That sounds smart. I would love to do that. But I have no idea how to. To me if feels that option 1 is to actually rewrite Alfred and execute the code myself with a given query, option 2 is to intercept the queries and their related XML outputs from the real alfred. What would be your approach?

[smarg19]

Option 2 basically. For example, in Terminal I run python alfred_filter.py query | florian_parser.py | pbcopy. My workflow's alfred_filter.py script takes query and outputs the standard XML that Alfred expects. But instead of being run in Alfred, I pass that XML to florian_parser.py (just a dummy name, and Python is a personal preference ). You take the XML and parse it into your JSON schema. I could then copy that JSON schema to start building the JSON for the demo. To my mind, it shouldn't actually be too hard. The conversion from XML to JSON isn't overly tricky, and your JSON schema pretty closely mirrors Aflred's XML schema. So, the only thing your asking workflow authors to do is run their scripts externally from Alfred once to start the JSON generation.

[raguay.customct]

Just use the Alfred Debugger on the Script filter. Tell it to show all information and it will show the xml output. That way you do not have to worry over commandline to Alfred differences.

[Florian]

Option 2 basically. For example, in Terminal I run python alfred_filter.py query | florian_parser.py | pbcopy. My workflow's alfred_filter.py script takes query and outputs the standard XML that Alfred expects. But instead of being run in Alfred, I pass that XML to florian_parser.py (just a dummy name, and Python is a personal preference ). You take the XML and parse it into your JSON schema. I could then copy that JSON schema to start building the JSON for the demo. To my mind, it shouldn't actually be too hard. The conversion from XML to JSON isn't overly tricky, and your JSON schema pretty closely mirrors Aflred's XML schema. So, the only thing your asking workflow authors to do is run their scripts externally from Alfred once to start the JSON generation.

 

And where you do have this alfred_filter.py?

[deanishe]

I think alfred_filter.py is meant to symbolise any Script Filter script. A lot of us write Script Filters as command-line scripts and run them from Alfred via bash:

/usr/bin/python alfred_filter.py "{query}"

[smarg19]

 

I think alfred_filter.py is meant to symbolise any Script Filter script. A lot of us write Script Filters as command-line scripts and run them from Alfred via bash:

/usr/bin/python alfred_filter.py "{query}"

Exactly. As a start, you probably can't get this to be as easy a transition for every workflow writer. So I would take the low hanging fruit. Plus, a lot of writers do structure things this way (I know Dean and I both do for all of our workflows). 

 

But raguay's idea is good too. Have the parsing script accept STDIN, then I can pipe a script to it or paste in debugger XML. Either way, it should be relatively easy.