So, what does the system hold for the user this time?
It’s really a tricky thing I must say.
As I mentioned before I will test a dependent dropdown through States and Cities. At first let’s create tables of states and cities and set a relation between these tables in order to relate states to cities. Take a look at the initial data:
Now I can check out variants of dependent dropdown realization that QuickBase offers. Unfortunately QuickBase doesn’t support conditional dropdown function, so the developers offer such alternatives:
Recommended way of implementation: to select from the final dropdown (in our case it’s Cities) and to use record picker rather than a drop-down menu for selection, as it gives a possibility to search. And after saving through lookup fields get the State from relation. This is how the city selection looks like:
And the record after value selection:
For better understanding of how it is done check the peculiarities of set up specified in this article.
The dependent dropdown alternative that QuickBase offers for the specific case with State and Cities solves the issue not so bad. But the goal of my testing is to show users the level of flexibility of different systems.
I can understand why developers try to represent any restrictions of the system as its peculiarities or even advantages. I was puzzled a bit with this statement:
"There is a better way to accomplish this than using dropdown lists whose content depends on the selection"
I think that suggested variant is not an appropriate solution in many cases. For example, there are several dropdowns which dependend on one dropdown?
So I my point is QuickBase doesn’t support dependent dropdown at this stage. Anyway the user decides if the offered alternative is good for him.