UX Patterns for Handling Search Terms?

What are people’s thoughts on accepting search terms in Packs?

I have this challenge in my IMDb Pack, for example: user provides search term, I need to return a movie.

Right now I just return the first result. Often works, but sometimes doesn’t. How I handle it:

  • Suggest that users craft better search terms, by including a movie’s year
  • Allow them to supply a direct reference to the resource (imdb id) instead of a search term

Tonight I found myself wanting a nutrition facts Pack (anyone wanna make this??) and realized there would be similar issues. A user searches “peanut butter” but do they mean just-peanuts peanut butter? Kraft?

How would you help get the user to the result they’re looking for?


Great topic @Nick_HE! A few tactics I’ve seen:

  • Have separate “search” and “get” formulas. The search formula returns an array of items, perhaps with an optional parameter to let the user set the max number of results. The get formula only returns a single item and is primarily used with IDs.
  • Use parameter auto-complete to allow users to search by name and select one of the results.

Thanks @Eric_Koleda , these are good ideas!

For the search formulas it would be cool to template out a way for users to search, choose a result, and stick it into a table. My head goes to spitting out a bulleted list of the options, but I don’t know of a way to programatically generate a button beside each result that would add it to a table. Instead I guess there could be another table that holds the search results? Flow would be:

  1. Type a search term into an input
  2. Hit a search button
  3. Search button wipes the search results table, and then populates it with a new row for each search result
  4. Search results table has a button column with an “Add” button, which adds the item to another table where you’re collecting chosen results

For bonus points, the search results table should be filtered to only display rows that are CreatedBy the current User(), so that concurrent users aren’t messing each other up.

For parameter autocomplete, does that work in column formats or just when writing in the formula builder?

1 Like

Ya, I think that’s about the best you can do today. It’s not possible to generate buttons in a list as far as I know, so the user-filtered results table is probably the best approach.

There are ways to programmatically create buttons but they’re deep magic courtesy of @Paul_Danyliuk

I hesitated to type “not possible”, knowing that @Paul_Danyliuk probably had an incantation for it. That said, I only consider the supported ways to do something, using non-experimental formulas.


Haha possible ≠ recommended

Joke’s on you both @Eric_Koleda @Connor_McCormick1 :joy: It is possible to generate a list of buttons with not a single row of black magic.

100 likes on this post and I’ll show you how :slightly_smiling_face:

P.S. I said “row”?? Haha! Not a single word lol.

P.P.S. Oh, maybe I was too quick to read the task. Not so confident anymore. But I’ll give my idea a spin nonetheless.

1 Like

Yep, here you go!

The trick is to utilize a Canvas Column. You can have a template canvas value that’ll be used for new rows, and that template canvas should be nothing but a button referring to thisRow.

  1. Create a table like this:

  2. Add a button in the canvas:

  3. Set up the button to show thisRow.Label as a label, thisRow.[Is disabled] as Disable If formula, and thisRow.[Actual button] as its action.

  4. Make sure there’s no trailing newline. If you can put a cursor on a line below the button, press backspace so that the line with the button is the only line.

  5. Set up the canvas column to use @[Template row].Canvas as the value for new rows:

  6. Now you can get those buttons in a formula and join them together into a single line :slight_smile: Filter out the template row if needed.

    Use locking so that clicking a button won’t bring up a formula editor. Alternatively load these buttons into a table cell and not directly into a page.

Pros: no black magic, all legit tricks :slight_smile:
Cons: object overhead and cluttering the global namespace with buttons (Button 1, Button 2 etc). Besides, on a free tier each such button will count towards the limit.

P.S. It’s not exactly what you were originally thinking (a programmatically generated bullet list with buttons) but perhaps you could still make a workaround with this trick.


@Paul_Danyliuk has done it again !

its such a joy to see the Grand Master at work to deliver another useful trick.

i love it

well done



Wow, I stand corrected! Only white magic this time :slight_smile: