I am struggling to find a way to handle dynamic (or user defined) options within an option set. Since there is no way that I am aware of to achieve this through standard workflow, I was hoping someone could help with the following use case:
Scenario is a marketplace between Clients and Consultants.
There is an existing option set for “Skills” where a client can specify the skills they are looking for and an expert can reflect they have those skills. e.g. UI Design, App Development, QC Testing. This is, of course, completely standard.
But then clients wish to be able to add their own custom and more specific skills e.g. Brand development, Employee retirement training, Legal writing review and edit
The only workaround I have thought of is for the client to capture these in texts and submit in a form, and then an admin adds on the back end. But this would not be real time and far from ideal.
Any advice here would be most appreciated.
Cheers
SP
As far as I know Bubble still has not enabled better manipulation of option sets and there are no workflows available to create or edit them and everything is done manually.
Therefore if you really need these ‘sub-skills’ as an option set, I think it is only possible to do as you mentioned for the workaround…but, even thinking about that it seems like you’d end up needing to create another attribute on the option set to know which specific user has added those ‘sub-skills’ and attributes can not be a data type, so a direct relation to the user data type is not possible…so you’d be needing to add the user ID as a text field and then end up searching the DB for the user with that text field.
Also, your option-set would likely become extremely difficult to manage, because again, no workflows for option sets, so no way to sort and filter to remove a ‘sub-skill’ when a user wants to edit or remove a sub-skill…and your list is just way too long eventually, just having 100 users with 5 ‘sub-skills’ is a scary option set of 500.
In my mind, sub-skills, since they are at the specific user level, do not need to be an option set to provide the benefits of option sets (the faster load speed for filters) and you could just have a data type for ‘sub-skills’ that has a field related to the option set option and then another field for a list of text to show the ‘sub-skill’…with that you could in theory add some abilities to filter that list and group things so that if a user was searching for a service provider and selected a specific skill from the option set you could show all the unique sub-skills and then group users based on those who added that particular sub-skill.
I think overall though, you are thinking about replicating what Upwork does when a user is requesting service and they choose a category, then add some skills and then can choose some sub-skills. My belief about how Upwork does that, is they have those sub-skills as an option set and are not relying on the freelancers to create them, instead the freelancers choose from them.
@boston85719, thanks for the thoughtful response. Sorry I wasn’t clear in my original post, but these aren’t sub-skills, but rather additional specific skills. But I don’t think that changes too much about your response concerns ether way. And yes, you are right that this is essentially an Upwork clone but for a very specific niche market.
Reading this portion makes me think that option sets are not the best method for capturing and using this data…the Client will create this, so how are you going to ‘match’ the Consultant who has those unknown sub-skills? Because a consultant when making a profile will not create sub-skills and there is no way to know which sub-skills Clients would make in the future.
If the client is making them, no need for option-set, just use a data type or a list on the data type you are using for the Clients ‘searching for service posting’.
It would presumably be a list displayed on that service request listing page. I also wouldn’t expect Consultants would ever really search for service requests based on a sub-skill.
If it is a very niche market, I would say just create a list of additional specific skills and have it as an option set that is related to the “Skills” option set. There couldn’t be so many for a specific niche that it wouldn’t be worth the hassle of creating.
Hmm, I’ve kind of had it as a “rule” in my head that the minute you need to support the use case you have described, you have to go the custom data type route because end users can’t add options to option sets. So, if it’s a hard requirement that clients be able to add skills, I think you have to go with a custom data type, no?
Yes, this is a big part of the scenario that I have been struggling with. To your point, how could I manage standardization and correct entry of skills?
Actually, it’s the opposite. The scope of possible skills is somewhat infinite. A better description would probably have been a niche market that doesn’t traditionally engage in online consulting matching. One of the reasons is this very issue that the skills matching is so broad.
Thanks for the response @mikeloc. I have been trying to stick with option sets due to their efficiency. The UX responses on the skills and jobs search is instantaneous. But I can see that practically your path may have to be the final outcome unfortunately.
Oh, no doubt, @SerPounce… I would want to stick with the option set, too, but I’ve been down that road before, and I really thought the only answer is to use a custom data type. I’d be thrilled if someone comes along with an answer that uses an option set, though.
by standardization do you mean the Use OF CorrEcT CapitalIZATIOn and SpelinGSS of Wrodz? I don’t know how that would be possible, but assume there may be a plugin, or Regex patterns…I’d say more likely a plugin for spelling and regex patterns for capitalization…but you could always default the inputs to lowercase when saving to the DB and then on display use the Capitalized words or some other set up where you extract the first letter and capitalize it and then show the remainder of the text.
If correct entry is more focused on association with a “Skill” from the option set, that wouldn’t be too hard to have them select the skill before adding the specific skill.
Yes, spelling is definitely apart of it. Another example would be conciseness and search practicality. If a client wanted to add “Brand Development” I wouldn’t them to type in “Localization and increasing of my lovely brand so I can get more money”.
In that case…limit the input character count, provide some helper text like ‘be concise’ ‘no more than 3 words’ and then also in helper text provide an example or two.
Making sure they follow the 3 word pattern example would require regex I think, as I don’t believe Bubble has a word count…however, there is a free plugin that does
So, I’d say you use a ‘tips’ or helper text, plus limit character count in the input and then employ the countable plugin to verify the number of words.
Of course if a user adds some junk that wouldn’t be searched well, that is kind of on them and their loss and I wouldn’t expect it to be reflective of the app, but all other things you could do.
I think check out this other free plugin as well…it looks like it will spell check
Curious if anyone knows if a custom plugin could programatically overwrite an option set from database immediately after any create, update or delete operation on a database table aka thing?
