Interface for selecting pictures to order prints

Continued research indicated (Gemini) that one way to solve this could be creating an individual record for each image, then one could link these records (images) to a field “Selected Images”. 

While it sounds logically doable, it also sounds like a lot of hassle. The images are now as linked records in an attachment field, where the record is a client specific “project”. Splitting this up to individual records for each image would eat up our records quota fast.

One could of course have this separate image table only temporarily, only until the image prints are ordered (and the client has signed off on the delivery). But it just sounds cumbersome to build and maintain, with a lot of potential breaking points.

Any thoughts on this approach?

Björn

Sorry to bump this this way, but would one of you “usual suspect” helpers be able to help here: ​@ScottWorld, ​@DisraeliGears01, ​@TheTimeSavingCo or ​@Mike_AutomaticN?

😊

The only way I’ve seen this done natively within Airtable is using a separate record per attachment as Gemini said. Not to say that’s the only way.

But I would think you’d be better off using Fillout or even Softr/Glide for something like this, if you want to keep all images on one client record in Airtable. 

In Fillout you’d build an update form and then generate a unique url for each client. They’d log in and be able to see their images and they should be able to check a box underneath each image they want to keep. 

Softr/Glide might be a little overkill, depending on volume, but worth looking into/asking Gemini about :)

Maybe one of the other users you tagged can jump in with an Airtable native solution for you.

Thanks ​@Holly Nilson-Clay! I thought briefly about Fillout, I have used it to complement Airtable in some other instances, but I couldn’t see the immediate way. I’ll have a real look at it based on your input.

Cheers,

Björn

PS. The interface is not for clients, but for our own staff, if that makes any difference.

Aah, ​@Holly Nilson-Clay, just after hitting Send I remembered the logical problem with Fillout I couldn’t solve 😀. If I get a selection check box done in Fillout, how would I get this back to Airtable? And I don’t mean mechanically, but the logic in Airtable? How would I in Airtable store the choices, and be able to reconstruct them, or let our user perhaps change the selection. Somehow this would need to accomodate for storing the attachment URLs of the selected images. Another Attachment Field in the Airtable named “Selected Images”, is it that simple…? 

Björn

Hmmm, I think you could do this with a custom interface?  If not, the one record per image thing is how I’d handle it too I reckon

Thanks ​@TheTimeSavingCo, I had not thought about the custom interface option, since I haven’t tried those at all yet. I'll give it a try!

In Fillout, you can only give people a choice of images from Airtable by using a linked record field. So each one of your images would need to be its own individual record in a separate Images table.

- ScottWorld, Expert Airtable Consultant 

Yeah, I just figured out how to handle something like this in a custom interface using a “cart” style interaction. Funnily enough the key to get it working with some of the custom interface constraints is bad database design. For my example it’s a catalog of film discs that are requestable. If you have requests as a separate table, the custom interface has a hell of a time coding something to talk to that table behind the scenes. The solution I came up with was writing the requests to the movie catalog table as the requests don’t have many fields (name, email, which movies as an same table linked record). Then I added an automation that copies those into the requests table and uses a delete script to get them out of the catalog table. 

I was actually going to post about this as a potential solution for you ​@0800-grizzly but I ran into a roadblock late yesterday as the requests are still unsubmittable by public users (inside an embed for instance). Even though it’s just a form writing to the same one table, I think custom interfaces don’t allow that interaction with the public (so annoying). That said, you’ve specified it’s for internal users, so this might be something to pursue. As Scott said though, you’ll probably end up needing a record per selectable image. Some of it can be handled through auto deletes, it depends there on the volume you’re looking at.

Custom Interface. In Omni, you can implement a cart using custom interface. It can store selections on local storage and give you the functionality you need. You do need to be quite technically specific about exactly how you want it to behave,

Thanks ​@ScottWorld! This means that in this case Fillout doesn’t bring anything substantially different than Airtable to the table (no pun intended), since if I keep each image as an own record, this can be solved already in Airtable. It’s a pity Fillout doesn’t read attachment fields for its “Picture choice” element, I’ll drop them a line about this.

Cheers,

Björn

Thanks ​@TheTimeSavingCo, ​@DisraeliGears01 and ​@VikasVimal.

I’ve yesterday had some success with a custom interface. The basics were actually easy enough to get done, probably by pure luck my first prompt got me a perfectly working core functionality. Of course, only when seeing that in action I realised a lot of other stuff that was needed, then it got messy :). I’ll start from scratch today and see if I can prompt better, when learning how to deal with this approach.

In short the solution was a cart-like UI where images from an attachment field with Google Drive links is presented with a checkbox and “Save selection” and “Reset” buttons. Saving a selection wrote (copied) the selected Google Drive link to another field in the same table, “Selected Images”. I think this works well for our purposes since this is a one-off thing, not an actual cart needing multiple request for different selections (hence needing a separate “Requests” table). I even got the selection “box” collapsible, which was nice. So this is basically the same solution as you came up with ​@DisraeliGears01, minus the automation to transfer the data to another table, as far as I can see.

The thing where I got stuck was when I wanted to add another cart element that would be shown only if the purchased product contained add-ons like albums or photo books that needed a separate choice for cover photo. I can’t yet get this to work, the second cart instance is not shown.

Dunno if there’s restriction in Omni, the React stuff or my promping skills :), but this is where I’ll continue now.

For reference if anybody’s interested, here’s the first prompt that was successful for the limited case:

• An interface where our own users, not clients, can select which images to be selected for printing. The images reside in the table Projects in the attachment field Project Images as Google Drive links. The user should be able to select, e.g. with a checkbox, multiple images so that the information will be stored in another attachment field in the  same table, for example called Selected Images.

Cheers,

Björn