I’m pretty certain somebody has asked this before.
We’re tracking location data, and sometimes there are multiple locations associated with businesses or people.
There are three “quick-and-nasty” solutions that I’d prefer to avoid:
Create an entity to house this data, and link it as a to-many relationship; or
Just add a bunch of extra fields labelled 2-upper limit (e.g., Physical Address, Physical Address 2, Physical Address 3); or
Create company entities for each of these addresses and duplicate the data.
All of these have major drawbacks.
The entity is harder to update than a single text field. Users will get confused. The data can get ruined by somebody accidentally re-assigning the relationship, etc.
Although it is unlikely to occur, there could be some businesses that have 20 or even 30 individual shops, meaning that the question ‘how long is a piece of string?’ starts cropping up.
Data duplication is bad. Maintenance nightmare.
Is there any way to have an “add another +” option for Text (normal text, email, phone) fields to prevent this issue from causing headaches?
Unfortunately we will never introduce collection-fields, since a separate Location or Address database is a way to go here. But what we can do is to improve usability of collections for such case. How do you want it to work from UI point of view?
Tough question to answer, and I’ll do my best to explain my thought process.
The users I’m writing this system for really don’t like tech and are big on the idea that “fewer clicks = better”. Also if there’s a way to ruin the data, I can guarantee they’ll find it.
If I were to add a table of addresses, the big selling point would be not having to navigate into the address object. It’s just another level of complexity.
Which is why I like tables and lists, but they’re not without their quirks.
If we take the current state of Fibery, and tabled relations inside entity panels, I would be happy enough to do it this way if I were the only person using this app. Alas, I am only one of many.
I think huge improvements could be made to the tables and lists. For example
When they are included (whether as a relation, or embedded in a document) is optionally turning off items the bar at the top for all non-admin users.
Everything other than the search, and sometimes the ‘New’ is just more visual clutter for a lot of users, most of the time.
The ‘+ New’ button inside the table actually not behaving like a button is a point of frustration for users. It would be nice if this could also be turned off/hidden, or configured to open the default form.
Forcing users to create a new record or update one already related instead of searching for and linking existing records (perhaps attached to other entities) is a reasonable workflow request. In this example, I wouldn’t want them to look through addresses assigned to other companies and steal that entity relationship.
I got a bit side-tracked there. Back to the topic of “collections”.
Addresses are one of many things that entities can have multiple of. For this reason, writing a solution solely for addresses seems a little silly.
Again, I really like how tables and lists are implemented. With how the system is currently, me simply writing a button automation to create an address would suffice for now.
(On that note, being able to group buttons into a structure would be a really good feature, e.g., a menu, a toolbar, or multiple columns. And turning off buttons based on conditions. Yup.)
If you mean top button, it exactly opens a form. If you mean last item as New row, it adds a new entity inlined and this is what people expect
In Table View you always create new records, so of you will have Table View to show addresses, there is no risk to change the relation when adding a new address. And you can change address fields inline in table view as well.
We use to-many relationship fairly extensively to solve for this issue.
Some Drawbacks to consider:
Forms and cannot handle these inputs when creating a new entity (You need separate fields for input).
Data is not viewable/editable in a table, list, or board view of the entity. Again we get around this with separate fields (This also requires a ton of automations to work properly)
