Single address input vs. 6 individual text inputs? (user shipping address details)

Is there an advantage or limitation between using the address input for a user’s shipping details? My concern is that the address is usually formatted into the database by bubble and it may not recognize a home address entered by the user. Is it safer to create 6 individual text inputs (town, city, zipcode, etc…)?

1 Like

The only thing I’d think of are parts of a shipping address that don’t get formatted automatically - like apartment number, P.O. Box, even offices in larger buildings can get complicated once rooms need to be labeled. Obviously I don’t know what your customer base is, but I’d think that the address input is better for locations on a map and individual inputs for an accurate shipping address.

4 Likes

Having a map next to the input might be useful to visually show that the user is putting in a “google format” address. I can see scenarios where that is not useful. And I’d recommend making the map “this element can’t be clicked” otherwise users might start messing with it pointlessly.

for any n00bs finding this thread (like me), I just discovered that Bubble’s default address input parses apartment numbers into the “subpremise” field (I was looking at room number and getting no cigar!)

Major lesson learned: I had lancebychance.bubbleapps.io listed in my google geolocation and google maps api keys as referrer, but when I upgraded the app to a personal plan and activated the domain … ouch! all of a sudden the address field was not working (because i had forgot to add lancebychance.com as a referrer!). Support pointed out my mistake, but in the mean time, I “re-discovered” the reason to “keep it simple.” Why depend on google maps api keys in this case when I can just use Stripe’s built in address verification? Why risk a potential billing hazard or add another “externality” (in this case the google maps geolocation etc) when Stripe offers the same service (there is nothing that irks me more than a client calling me with a “system is down” message when it turns out some credit card expired somewhere (yeah, i probably am not routing the credit card expiration messages to the client properly but that’s another story :smile_cat: --it’s still a potential hazard and i can only imagine the nightmare when one approaches having a hundred then thousands of clients… ) ?

As I am eventually hoping to adopt the sub-app model, I realize any “cool” but ultimately unnecessary feature I try to implement will just cause headaches for my clients’s customers, then my clients and therefore me!

(On a tangent, I am probably going to swap out my contact form element for Tawk.to, “less is more” “more is less” “less dependency on Bubble/billing lapses is more quality time” “more decentralized data processing is less likely to cause headaches down the road!” ) :beers: