I have an application that requires registering 2 different types of user— Business Users and Professional Users. The user profiles of each are very different. For example…
Business User accounts represent businesses and the profile contains things like:
- Business Website URL
- Number of Years in Business
- Business Hours of Operation
- Area of Professional Specialization
- Education / Degree
- Professional License Number
- Avatar Image
I would like to have all users complete a “quick” registration, requiring only the basic Joomla user account credentials (name, email, password) plus their Account Type (Business or Professional). Then on first login, I want to have them complete their user account profile by providing all the additional information like the items listed above. I want to separate the initial registration from completion of the profile because the full profile contains information the user may not have readily available at the time of registration. Requiring all of it at the time of registration may create a barrier to registration and result in a poor customer experience.
METHOD A:
Create two content types (Business User and Professional User) by extending the core SEBLOD User content type. However, because some items are required to complete the profile, this approach leads to the undesirable experience described above where users must complete the entire profile at time of registration.
Question: In this scenario, is there a way to present only part of the Business User or Professional User form at the time of registration (without requiring all the other info), and after registration present the full form, including additional required fields? If so, how?
METHOD B:
An alternate method may be to separate the additional profile information by creating new content types (Business Profile and Professional Profile) that do not extend the SEBLOD User. The additional profile information could then be associated with the user, but not actually be in the User content type. I’ve experimented with this approach, but it’s not clear to me how to create the separate Profile article (of the correct type) at the time of registration, and associate it with the User.
Questions: I’m wondering if anyone has had experience with similar scenarios, and if so, how they implemented them. What are the best practices for this type of requirement?
I’m new to SEBLOD, and don’t have a lot of experience with it. I’ve searched the forums and other resources for answers to these questions and haven’t found them. By posting this, I hope to hear some good ideas. I’ll sort out the details, but appreciate any ideas you have about the best overall approach to a requirement I suspect others have dealt with before.
Thanks everyone in advance for your ideas and suggestions.
Denver
Please check out the Manuals section if you haven't done so yet, and also the tutorial on storage to get started.
You should be able to use a single user Content Type - makes it easier in the event that a Business user becomes a Professional. Have a look at this post.
Using conditionals (option 5 in the Content Type Workshop), you can turn on and off fields based on other fields. So in your case, the user id, and user group id would be the triggers. If the user id is not filled then its a new registration, so everything else is disabled. Then after they log back in, you can check for the ID and the user group id to enable/disable the other fields.
That's one idea anyway...
Regards,
Randy
Thanks a lot for the suggestion. I'll try the single content type with conditionals approach and see how that works. Because I'm not very familiar with the full utility of conditionals, that approach wasn't obvious to me. If it works, it will solve another challenge I've been dealing with, too. That would be a great bonus.
Thanks again!
Denver
Nice idea, i was just looking fot that, and i was planning the same... one single content type for mutiple users membership profiles...
Thanks
Randy's proposed solution has worked very well. I have a single Member content type based on User. A single field that is required upon registration identifies the type of user. Evaluating that field allows me to set other fields Hidden+Disabled or Visible+Enabled as required depending on the type of user. At the time of initial registration, most of the profile fields are Hidden+Disabled allowing the user to do a "quick" registration. This I accomplished by defining a rule that makes them Hidden+Disabled when User ID IsEqual / In '0'.
Thanks, Randy for the suggestion!
Hi denverh
Thanks! Look like a nice solution, i will try that on my website :)
Hello SEBLODers!
This approach has worked pretty well to a point, but I've recently encountered a problem. Maybe Randy or someone else can shed some light on it.
Consider this simplified scenario:
- I have one content type (Member).
- I have a field (Member Type) that identifies a user as either a 'Business' or 'Professional' type user.
- Some fields are meaningful only to Business users and so are conditionally Disabled+Hidden for Professional users.
- Some fields are meaningful only to Professional users and so are conditionally Disabled+Hidden for Business users.
- ALL fields are required.
With this configuration, when a Professional user submits the form, the required Business fields are not a problem. As long as they are conditionally Disabled+Hidden, the required field is not enforced. This is good for my purposes. Similarly, when a Business user submits the form, the required Professional fields are not enforced. Again, this is ideal for my needs.
The Problem:
There is one field-- a FieldX field where Professional users are required to enter one or more Past Employers. The conditional configuration of this field is to be Disabled+Hidden for Business users just like all the others, but for this and only this field, the required field validation is still enforced even when the field is Disabled+Hidden. So while my approach here works for ALL other fields in my Member form, it does not work for this one field.
Questions:
Does anyone have an idea why it doesn't work the same way? And more importantly, does anyone know how I might make it work like the others?
Feedback:
The learning curve with SEBLOD has been steep the last few weeks, and while I've been frustrated at times, I have to say that my overall experience with SEBLOD has been very positive. Moments like this threaten my project schedule and sanity, but thanks to the good help of people here in the forum, my frustration is usually short-lived. I'm finally nearing completion of a feature-rich application I could never have developed so quickly without SEBLOD. So I'm optimistic that I'll learn something new to solve this problem, too. Thanks in advance for your feedback and suggestions!
Denver
Hi Denver,
It appears that this is an issue on the Tracker.
SO...A possible work around...
Could you add a Default value to the FieldX like: N/A?
Another method Instead of using FieldX, use Text Fields, then enable one by one as the previous one gets filled out. Just make the first one required. Its more cumbersome, but it might also do the trick...
Would something like that work?
Randy
Hey, thanks Randy! It's obvious this isn't your first rodeo where SEBLOD is concerned. You've got quite an arsenal of clever workarounds always at the ready. I'll use separate text fields so I can keep it required and still support multiple entries by revealing each as the prior one is filled. I like that idea. It's not what I want, but it will work.
Thanks!
Denver
Denverh or Randy,
I'm trying to figure out how you did this. I'm somewhat following and understand the concept, but lost as to where everything is set up and the settings that are made.
I found the conditionals area. I have no idea what I'm really looking at.
What I'm looking to do is have people who come to the site make a selection. Registered or Guest. A guest would not have a lengthy profile just a short "about me." A Registered person would have a more indepth profile.
As such a person selecting either guest or registered would be placed in those registration categories on the back-end. I tried a radio button solution with the selection equalling the user category ID, but it didn't work.
LCMA -
Glad to help you out here. Your requirement sounds very similar to mine. I've got this working pretty well now and I'm happy with it. In my case, I hide nearly all fields at the time of initial registration (when Member ID = 0), and selectively hide/display fields depending on a Member type (either "Business" or "Individual").
In the Conditional States + Computation view, under the Conditional States column, locate a field you want to hide on the "short" version of the form. Click "Add" to add the conditional behavior.
For the first parameter (immediately following "This field") select both "is Hidden" and "is Disabled" (you'll use two rows to do this). Ignore the next two fields and uncheck the checkbox labeled "2". It's purpose, as I understand it, is to toggle a behavior that automatically creates an opposite state. I didn't want this, so I unchecked it.
After WHEN, define the condition(s). You can use multiple rows to combine conditions. When you have multiple conditions, set the AND/OR field for each additional condition. You will define each condition by first identifying a field, the condition you want to evaluate, and a value to be used in the evaluation.
For my requirement, I defined 2 behaviors (is Hidden, is Disabled), and 2 conditions as:
This field is Disabled, is Hidden WHEN member_id is Equal / In 0 OR member_type is Equal / In 2.
Note: The value '2' in the example above is the actual value derived from a radio button in my form. If you click the orange arrows next to the field, you can select from the options you have defined for the field being evaluated and SEBLOD will populate the field with the correct underlying value.
Note2: All I have done is selectively
Hide+Disable fields. Some fields are always visible. All others have the
above conditional rule applied to them if they are a Business type user
(fields they should NOT see), and a slightly different variation for
fields that Individual Users should NOT see. The only difference in the
conditions is in the final parameter (member_type).
Hope this helps!
Denver
Denver,
Thank you for the reply, I think I'm following what you are doing. I know just enough programming to really mess things up, but I understand the concept and logic behind what is taking place - if that makes any sense.
I apologize for the late response, it's been a crazy week.
I'll work on this today and let you know how it goes.
Thanks you Denverh for the detailed explanation. I am implementing this now and will test it soon. We always appreciate when users explain how they found the solution rather than just "solved".
