Dynamic results

[Florian]

Hey guys,

 

I do believe this is a missing feature. I know the team wants Alfred sleek and instant, but then we hack the hell out of it and we still like it

 

So here we go, how can we get those results to display dynamically; and by that I mean 2 different things:

 

 

 

Case #1 - Single result or multiple "display only" results

Say for example a step in your workflow takes a little bit to complete (not too much otherwise you want to do that in the background and pop back alfred or offer an osx notification with a button to be clicked). In this situation a progress bar would be nice, wouldn't it? 

 

proposed solution: why not taking advantage of the external trigger (or older callback methods?) and kick off a separate thread from the script filter that will sleep some time before calling again (somehow we know that this is an "again" call because we stored the query & timestamp somewhere). This would probably make for a dynamic line, no?

 

 

 

Case #2 - Multiple results

In this case you have a list of things to return. Say for example today's top artists from mtv. But you also want some metadata on them, and a picture. So you've got to make a first call to mtv's website then you have your list of results (display 1) and then you'll fetch metadata (display 2) and icons (display 3). If you wait for state 3 to be reached for each artist you want to display, this is going to take forever. But display 1 is already an ok time to start showing stuff. And then 2 and 3 can be reached at different times by each artist. It needs dynamic results, no?

 

proposed solution: I don't really know how to do that here. Maybe tinkering live with the plist file to turn the list of results into a whole bunch of single results that respond to the same keyword (which is actually the initial keyword + the current query). If you do so, probably you can get results to be added to the list that is currently being displayed. But if you want to refresh items from the list, then is the user has started scrolling down, it'll take him back up. 

Bottom line, not ideal for refreshing items, but okay for progressively adding items.

 

 

This is a call for ideas to all the old timers (David Ferguson, Carlos-Sz, Tyler Eich, Vítor, Shawn Rice, phyllisstein, CarlosNZ, raguay.customct, ctwise, ... i know you guys like challenge!) and everyone else. Let's hack together

[Carlos-Sz]

I never thought about Case #2 but Case #1, specially a progress bar, I did.

 

I made an iTunes Playlist to Folder workflow (with mp3 conversion as an option) that can take a lot of time to be completed.

 

Right now the workflow will update its status in the background and every time the workflow is started the user will see the current progress instead of the options to run the workflow (the workflow knows it is running and thus will give the current progress). The progress and all using a plist file.

 

Alfred “search” command does not update itself even if it is visible. If Alfred updates itself when visible then things could be different for a progress and even for a drill-down alike menus. Things would be dynamic.

 

I even made a small xCode application to display the progress but it kind of breaks the Alfred experience somehow.

 

I ended up making a stand alone application to copy some iTunes playlists to a folder (in my case, a SD Card for my car).

 

Anyway, maybe some more advanced features would be nice to consider in a future version of Alfred.

[Florian]

I do know that alfred doesn't refresh. But you can force it to. Here a very very quick mockup. You actually have to disable the workflow to make it stop. Keyword "hello".

http://dl.getdropbox.com/u/14050630/POC%20refresh.alfredworkflow

Edited May 25, 2014 by Florian

[Carlos-Sz]

I do know that alfred doesn't refresh. But you can force it to. Here a very very quick mockup. You actually have to disable the workflow to make it stop. Keyword "hello".

http://dl.getdropbox.com/u/14050630/POC%20refresh.alfredworkflow

 

I know you know that. I was kind of thinking out loud.

 

I still have to play with external trigger a bit more. Nice example btw.

 

However, there should be a way to show progress but not taking over Alfred app. 

 

In my workflow, the progress is show only if the keyword is typed but it would be nice that once typed I could update the window without reload it or taking over Alfred app. I hope I was clear.

[Florian]

What about some sort of companion app for alfred? That could deal with notifications, progress. And probably the community could come up with more uses of an optional extra set of features.

[Carlos-Sz]

What about some sort of companion app for alfred? That could deal with notifications, progress. And probably the community could come up with more uses of an optional extra set of features.

 

Pashua is interesting. It can provide that OSX interface much like a xCode app that we can code.

 

But I’m not sure if they fit the overall Alfred experience. We move the user from Alfred UI to a common OSX UI. This transition that makes me think if this path is the right one.

[rice.shawn]

Pashua is interesting. It can provide that OSX interface much like a xCode app that we can code.

 

But I’m not sure if they fit the overall Alfred experience. We move the user from Alfred UI to a common OSX UI. This transition that makes me think if this path is the right one.

 

I used Pashua in the Alfred Cron workflow in order to help people have an easier way to define jobs. You could also look into CocoaDialog, which has a bit more flexibility, but I really like how Pashua works overall.

 

For notifications, you could use Terminal Notifier. Well, you could check for a Growl installation and use that and then fallback to Terminal Notifier.

 

CocoaDialog actually has ways to create progress bars, which is pretty cool.

 

To make it easier to use, just implement the dependency bundler (I seem to be pitching this a lot today). Both Pashua, CocoaDialog, and Terminal Notifier are available as default options, so you won't have to include either in your workflow, and users won't have redundant copies on their machines.

 

It seems like the best way to do this would be to use a mix of CocoaDialog and External Triggers. Basically, the workflow itself would be in two different parts: the first part would just launch a background process that would do everything necessary. The background process would update a small little text file in the cache directory that CocoaDialog could interface with for the progress bar, and you could even use Terminal Notifier to notify which steps are being done. After everything is done, then you would have that background process call the external trigger in the workflow to complete everything.

 

I'd recommend caching all the results in order to minimize everything as much as possible.

 

It's a fun idea. I'm completely swamped right now, but I might put something together if I get a chance.

[Carlos-Sz]

I used Pashua in the Alfred Cron workflow in order to help people have an easier way to define jobs. You could also look into CocoaDialog, which has a bit more flexibility, but I really like how Pashua works overall.

 

For notifications, you could use Terminal Notifier. Well, you could check for a Growl installation and use that and then fallback to Terminal Notifier.

 

CocoaDialog actually has ways to create progress bars, which is pretty cool.

 

To make it easier to use, just implement the dependency bundler (I seem to be pitching this a lot today). Both Pashua, CocoaDialog, and Terminal Notifier are available as default options, so you won't have to include either in your workflow, and users won't have redundant copies on their machines.

 

It seems like the best way to do this would be to use a mix of CocoaDialog and External Triggers. Basically, the workflow itself would be in two different parts: the first part would just launch a background process that would do everything necessary. The background process would update a small little text file in the cache directory that CocoaDialog could interface with for the progress bar, and you could even use Terminal Notifier to notify which steps are being done. After everything is done, then you would have that background process call the external trigger in the workflow to complete everything.

 

I'd recommend caching all the results in order to minimize everything as much as possible.

 

It's a fun idea. I'm completely swamped right now, but I might put something together if I get a chance.

 

The question that popped in my mind when I was making a progress bar (xCode app) to show a workflow progress was: if I really need all that OSX interface then maybe (I said maybe) I should make an application instead of a workflow… Anyway, I’m still thinking about all those external options.

[rice.shawn]

Touché.

 

It seems like some of the workflows here have evolved to proto-applications, but, really, they're all (mostly) wrappers that are handled through Alfred's elegant interface, and that interface is the reason to keep them as workflows. From much of what I've (and you've) seen around here, configuration of workflows has always been a problem. When there get to be too many options, then the first place people went was to have people write a JSON or some other type of config file, but that usually led to many support requests as people, for instance, didn't get the syntax correct or, worse, used Textedit in rich text mode to write the file, thus introducing smart quotes and general crashes.

 

Many of us then resorted to using Applescript Dialogs for some stuff (which are INCREDIBLY UGLY), but were too limited by them.

 

Alfred is, as someone here once pointed out — I'm blanking on who, becoming more and more an elegant wrapper for the terminal. And, well, the terminal still scares many people, so Alfred is a nice easy way in, but we all know that the terminal is full of progress bars (apt/wget/curl/most anything else), and those do help.

 

Maybe another way to think about it is that Alfred makes it so that you don't have to write a new interface for you new Application. Or, for those of us who aren't so great with any sort of C, it's a great wrapper for us to make pseudo-applications out of shell scripts.

 

When I keep coming back to this, I keep just thinking that we're using Alfred because of its interface and accessibility, and many of us are starting to pull in these UI's for more complicated configs and displaying more information (which is an area that Alfred does not excel), and, now, Florian has a great idea about how to implement what is, basically, a long-running process elegantly in a way that assures the user that it's still working.

 

But, Carlos, as always it's a good thought and question, and it reminds me that I need to go re-learn some flavors of C. 

[rice.shawn]

I'm pretty sure that Andrew didn't quite expect us to go as crazy as some of us have with these workflows when he created the infrastructure. I mean, you, Carlos, have basically rewritten Evernote on top of Evernote. Luxinate is just crazy. When I first saw the workflows, I just thought that they would be there for easier things (i.e. toggle caffeine or caffeinate). I love how much we're pushing the limits of what Alfred can do. I'd love to troll through the forums and try to get a tally of just how many apps have been obsolesced via workflows. Now, if someone could write a performant and pluggable keylogger, we could replace TextExpander. That would be rad.

[Florian]

Ah ah that was me the terminal quote. I wish i had more time to dedicate to Alfred... Anyway.

 

So this Pashua or CocoaDialog (yes, with dependency bundler ) option is a good one for a specific case : a long running process.

 

What if you have a short one (say ~3 seconds for an install or for fetching whatever data)? it's barely worth it to get out, trigger a progress bar, and pop alfred back up. So in my opinion, the self refreshing workflow i made up there would be an okay alternative so long as actual dynamic workflows aren't an option.

 

But what about multiple output workflows? Say I fetch the metadata of a bunch of movies on separate pages. It's gonna take a little time for each of them and it'd be cool to display the first ones you get before the latest ones. Any clue on how to do that? I was thinking that maybe changing the plist file to dynamically add a new Script Filter for each movie fetched could work (but that depends on how alfred is implemented, someone would have to try that if we don't get a better idea). Anything else?

Edited May 30, 2014 by Florian

[rice.shawn]

For dynamically changing the plist, look at Dean's Fuzzy Folders workflow. I know he does some stuff like that in it.

 

For a three second operation, it would just be best not to have it refreshed at all but just a regular script filter with a "please wait" or something. I guess you could refresh at that point.

 

If the result is a variable time (say anywhere from one second to two minutes), then you could try to do something to estimate the amount of time for the operation to complete and then put up a progress bar if, say, it goes over five seconds. So, if you were downloading things, then you could try to figure out the speed, etc....

 

While the self-updating script filter could be really cool, it seems most important to think of the user interaction. By doing this self-updating thing, you're expecting the user to sit there and watch it, and you're not letting them out of it either because it'll just keep calling itself, so that sort of thing might really annoy a user. Putting up the CocoaDialog for something that's too quick would be a similar (but less of an) annoyance.

 

For another recursive workflow, here's a countdown timer. Just do something like "countdown 9" and watch it go.

[rice.shawn]

Ah ah that was me the terminal quote. I wish i had more time to dedicate to Alfred... Anyway.

 

You're totally right! My silly memory.

[Carlos-Sz]

Ah ah that was me the terminal quote. I wish i had more time to dedicate to Alfred... Anyway.

 

So this Pashua or CocoaDialog (yes, with dependency bundler ) option is a good one for a specific case : a long running process.

 

What if you have a short one (say ~3 seconds for an install or for fetching whatever data)? it's barely worth it to get out, trigger a progress bar, and pop alfred back up. So in my opinion, the self refreshing workflow i made up there would be an okay alternative so long as actual dynamic workflows aren't an option.

 

But what about multiple output workflows? Say I fetch the metadata of a bunch of movies on separate pages. It's gonna take a little time for each of them and it'd be cool to display the first ones you get before the latest ones. Any clue on how to do that? I was thinking that maybe changing the plist file to dynamically add a new Script Filter for each movie fetched could work (but that depends on how alfred is implemented, someone would have to try that if we don't get a better idea). Anything else?

 

 

That’s not easy… I would display what I can get faster and let a first menu item to lead the user to get more…

 

As I said before we may have to avoid taking over Alfred.

 

@ Shawn “... rewritten Evernote on top of Evernote.”

[rice.shawn]

That’s not easy… I would display what I can get faster and let a first menu item to lead the user to get more…

 

As I said before we may have to avoid taking over Alfred.

 

I half agree with the second statement (it depends on what the user can expect), but I completely agree with the first statement. That sounds like a contradiction, but it's really not...