Forum Activity for @researchcooperative

Explaining the Sign up form, a two-way problem, and a possible two-in-one solution

Using Jamroom


OK. Just checked back at my Ning site, and in fact this is what happens there too. I should have seen this more clearly already. Thanks for spelling it out.

What is different at Ning is that the applicant can fill out the full profile form BEFORE being approved, and the Admin can see the full profile BEFORE deciding whether to give approval.

Not being able to work in this sequence, by default, seems to me a fatal flaw in the logic of the JR signup process.
updated by @researchcooperative: 02/15/16 06:20:53AM

Explaining the Sign up form, a two-way problem, and a possible two-in-one solution

Using Jamroom

All true. But I won't be able to 'sell' the property I'm building if it doesn't have doors and windows that open and shut. I really do see the profile forms as the windows and doors of a social network: this is fairly basic functionality, though not structural in the engineering sense.

Recently I've been watching new apartment blocks going up around me here in Kyoto. The basic structural work is great and the finishing work is pretty good... it has to be, to compete with the over-supply of housing here in Japan.

In this case, it all happens, and comes together, because some very big developers have fat wallets to bring in expert teams at all stages of the work.

JR may still be building prefab pieces, but I think it is not too far from being able to offer some model homes ready for finishing. The Keith Hay building company is still going strong in NZ after almost 80 years in the low-cost housing market. JR has a world to play in and look forward to.

Explaining the Sign up form, a two-way problem, and a possible two-in-one solution

Using Jamroom

Thanks for all that. I'll extend the room building analogy a little further...

At the moment it seems like the form designer lets us design windows of any shape and size, with or without openings or curtains, but if we actually want these windows and curtains to be made and used (so that people inside can communicate with people outside), then we have to buy the materials and apply the hammer and nails and sewing kit ourselves, whether or not we have carpentry and sewing skills.

And as my site is currently configured, with the default, minimal Sign up form, if someone knocks on the door to come inside, I have to let them in before I can see them or talk to them.... and they have knock on the door before knowing what questions I am planning to ask if I let them in.

Assuming they knock, and I let them in, then they will see my questions in the Profile form, and they can decide themselves whether or not the answers should be private, but the point is moot because there is no actual window for them to show their answers to the world. They can see their own answers on their own profile page, using the settings cog, but no-one else except Admin can see them.

So now I'm locked in the room with this stranger I let in...
updated by @researchcooperative: 02/13/16 09:21:13PM

Explaining the Sign up form, a two-way problem, and a possible two-in-one solution

Using Jamroom

Dear Paul,

Thanks - that is encouraging, but is all work I will need to employ a CSS guy or developer to do.

As part of (my dream) program to have on off-the-shelf-usable AND flexible form system, a toggle switch could be used to make the Sign up form the de facto Profile form, and to make that Profile form public (by default) to all visitors on the users's top profile page, apart from fields designated as private by Admin.

I still can't see how to make profile data fields public in the existing system, even with the privacy settings set for maximum visibility for each field in form designer.

As a logged in user in my regular member quota, I can see the profiles of other members in the same quota, but not the data in their profile form. I can only see my own profile data, and only by clicking on the obscure cog (settings) icon at the top of my profile page.

The JR system seems designed by default to hide information rather than to make it public. Why the bias? Why not design the system to be just as easily public as it is private, without asking Admins to make their own special hand-made templates, etc.

Recently I have tried talking to someone with CSS skills, but no JR experience, so find myself trying to explain a system that I don't understand myself. I can't train the developer I need for this project!

On the other hand, I don't want to be dependent on costly developers for every revision of the site content and for responses to every upgrade, which is why I am hoping for Site-Builder like facilitation for the critical form-designing and publishing steps.
updated by @researchcooperative: 02/12/16 06:42:30PM

Explaining the Sign up form, a two-way problem, and a possible two-in-one solution

Using Jamroom

After some attempts to find information about the Sign up form by searching in documentation, I found that (a) the Sign up system is controlled by the User module, and (b) the actual Sign up form is not accessible, for design purposes, with this module.

I have left a comment explaining how to access the user Sign up form here:
https://www.jamroom.net/the-jamroom-network/documentation/modules/945/users

I hope my explanation is correct.

PROBLEM: At the Sign up stage, before a new account has been approved, Admin can only see what is in the Sign up form, because the User cannot add information to their profile until their account has been approved.

If the Sign up form only requires a user name, email address, and human check, the Admin may not have enough information to judge if the applicant is suitable for the site.

QUESTION (aiming for a two-in-one solution): Is it possible to set up an autofill function from the Sign up form to profile form fields in the new user's chosen quota?

An auto-fill function might be useful for three inter-connected reasons:

1. The Admin. could design a Sign-up form with more fields (without duplicating what is required in the Profile form).

2. Sign up data would not have to be re-entered by the new user (account and profile owner) when filling out the Profile form after approval.

3. The Admin would be able to check the Profile of the new user to see the information needed for approval, after receiving a pending user account notice




updated by @researchcooperative: 05/16/16 03:18:26PM

Designing a profile form for profiles in Quota X, and a different form for profiles in Quota Y

Using Jamroom

Dear UH,

Thanks. All true... Will continue to tinker.

Designing a profile form for profiles in Quota X, and a different form for profiles in Quota Y

Using Jamroom

Thanks very much.

1. For the forms A and B (member forms) ALL the entered data needs to be visible on all the profile pages, and ALL the fields need to be shown in the signup form, but they do not all need to be "required" fields. The new user can think about the optional fields and later add more details if they want, once they are confident about how the site works.

There is one instance where I would like to make a field that is not publicly displayed on the profile page, and that is a field labelled "Private message to Admin". This is a field that allows new members to express any concerns or questions they have directly during the signup process.

What and where is the "User Account" form you mention? If this is different from a Sign-up (create) form, how is it created?

2. I think you may be right that it can all be done with the form designer as it stands, but from an admin point of view, it is awkward to keep track of shared vs non-shared fields, for different quotas.

It is important to be able to see how the complete form will look to users while we are setting it up (the WYSIWYG perspective). This may be 'mere convenience' from an engineering perspective, but from the perspective of gaining users of JR, it would be a big plus.

3. If a field is displayed to "(group) all users including logged out" does this make selecting any of the quotas or other user groups redundant? I imagine it does, but it might be nice to have some kind of prompt or device indicating that this selection overides all other selections (if this is how it works).

4. In general, it is a good thing for each member to have personal privacy control over how their profile is displayed, but for some sites, site owners might want to over-ride such control. Perhaps, under control of Master Admin, there could be a toggle switch for "Admin overides member/Member overides Admin" vis a vis the Privacy controls.

5. In Profile Form A, I am restricting ordinary members to 2 website links (which also helps to discourage spam linking by free members). In Profile Form B, as a privilege of "Special Member" status I am allowing 3 website links (which may be commercially useful for such paying members). In the final version, the subtexts and help messages may be different for these fields in the Regular member and Special member forms.

This is another reason I want to keep all fields for different forms separate (i.e. for profiles in different quotas) -- so that any field can easily be modified for quota-specific purposes as the need arises, without having to worry if that field is being used for profiles in another quota.

6. I may be able to achieve my goal of separate forms for separate quotas simply by adding a quota label (Q1, Q2 etc) to each field, and keeping all Q1 fields together, all Q2 fields together etc. For example, I could label them profile_Q1F1_name, profile_Q1F2_location, profile_Q1F3_work_interests, etc. (using the quota numbers assigned by the jr system).

But then, how do I merge/synchronise the fields in the "sign-up (create)" and "update (settings)" areas?

7. Editing the profile template(s) to display what has been designated for display is a difficult manual step for me. It is counter-intuitive that after choosing display options in form designer, there is no actual display. I don't comprehend it.

This is another thing I would like the proposed "Form Builder" module to handle... so that after choosing the display settings for each field, no further action is needed for the display to happen (or not happen, according to the setting chosen).
updated by @researchcooperative: 02/05/16 06:02:14AM

Designing a profile form for profiles in Quota X, and a different form for profiles in Quota Y

Using Jamroom

Dear Paul,

Thanks. The following are four main types of form that I need. The first two are member profile forms, the second two are administrative profile forms.

I will need to adjust the actual fields used in each form, over time, so I want to keep the flexibility of the basic form (field) designer, but am looking for a way to have the forms organised in a way that keeps the different forms separate. Hence my suggestion of a Form Builder to work with the form (field) designer.

For the second two, there will only ever be one profile each in the respective quotas. In addition to the editing hub, I have a translation hub, and audio hub, and so on, and these will also require their own profile forms.

Do the display (visibility) settings in form designer over-ride profile owner's privacy settings, or vice versa?


A. Regular member profile form (for sign up and later completion/modification)
Quota = Regular member
* = required
Visibility: (group) all users including logged out.
Privacy controls: default = not private, can be searched (but user may unpublish if wanting to go offline)

1. Name*
2. Location*
3. Work interests/services offered*
4. Affiliation
5. Preferred method(s) of contact
6. Preferred language(s) of contact
7. Contact details*
8. Joined (year of joining PSN)*
9. Short biography or other description
10. Website 1
11. Website 2


B. Special member profile form (for use by members willing to pay subscription for access to transaction services, etc.). This may also be a signup form for companies that do not require regular membership.
Quota = special member
*=required
Visibility: (group) all users including logged out.
Privacy controls: default = not private, can be searched (but user may unpublish if wanting to go offline)

1. Company or other name*
2. Location*
3. Contact person*
4. Preferred method(s) of contact
5. Preferred language(s) of contact
6. Contact details*
7. Services offered
8. Discounts offered
9. Joined (year of joining PSN)*
10. Company history
11. Website 1
12. Website 2
13. Website 3


C. Publish Science Network Info form (for network profile and working groups, etc.)
Quota = Publish Science Network (jrsite owner). This does not need to be a sign-up form. It just needs to be a profile form that can be edited by Admin whenever needed.
*=required
Visibility: (group) all users including logged out.
Privacy controls: default = not private, can be searched.

1. About*
2. Location*
3. Preferred method(s) of contact
4. Site language
5. Network contact*
6. Services offered

D. Editing Hub profile form (for forum, groups and information related to editing services). This does not need to be a sign-up form. It just needs to be a profile form that can be edited by Admin whenever needed.
Quota = Publish Science Network
*=required
Visibility: (group) all users including logged out.
Privacy controls: default = not private, can be searched.

1. About*
2. Hub contact
updated by @researchcooperative: 02/04/16 08:15:47PM

Designing a profile form for profiles in Quota X, and a different form for profiles in Quota Y

Using Jamroom

Dear Douglas,

I don't understand the answer, sorry. When I go to:

http://publishsciencenet.jamroomhosting.com/profile/admin/templates

... I see nothing that leads me to something that looks like your code.

And does your piece of code relate to the process of designing a standard form for all profiles in a particular quota?

I guess what I am looking for is something like Site Builder - let's call it "Form Builder" - that takes the basic foundation provided by jrCore and the profile form designer, and then makes it easy to design create(=signup?)-and-update forms for a particular quota without having to work with code strings.

Is this technically possible? I'll invest $1000 in this for JR if it can be done.

I am not asking for something that reduces the flexiblity of Jamroom.

I am asking for something that makes the flexibility much more usable by a much larger potential customer base for Jamroom (including myself).

Until then, I feel stuck. I am stuck.

Also, in my case, I need the create and update (settings) forms to be the same form, in effect, so that users can see what they have already filled in and published, and what remains to be added when the log-in on another visit.

I do not see how to make two forms (with create and settings fields) effectively one for ease of use by users who have just one profile.

This is one of the things I would like the proposed "Form Builder" to take care of (as an option of course, since some sites may want to separate the sign-up form system from the profile form).

Is it expected that there will only be one profile create (sign-up) form per user, but potentially many different profile 'settings' forms, for each different profile the user may make?

It would be nice if the "Form Builder" could allow admin to design profile forms like this:

1. Regular member sign-up and primary profile form (i.e. sign-up = primary profile form, with optional fields that can be completed at any time after sign-up).

2. "Add-on profile forms" (in one or more quotas, depending on the options Admin has given to regular members). Each "add-on profile form" will likely vary according to the quota, since quotas may have very different functionalities depending on what modules are available to users in each quota)

I have other specific questions, but will leave them for a another post, another time.

Thanks.
updated by @researchcooperative: 02/04/16 06:28:40AM

Designing a profile form for profiles in Quota X, and a different form for profiles in Quota Y

Using Jamroom


(The following comments can be skipped to see a short and perhaps answerable question at the end.)

Thanks again...

I understand that the above quoted statement is a kind of shorthand for explaining the system... but what I need is a step-by-step guide that explains how to create profile forms that PEOPLE see.

In writing such a (hypothetical) guide, please begin with the point of view of a non-member visiting a Jamroom site, and wanting to see what kind of people are members. First step of a curious non-member will be to visit the profile pages (and this will apply to 99% of Jamroom sites, regardless of their purpose, I imagine).

The profiles may represent actual individuals, or they may be company names, or groups, or whatever. But a person is looking at their computer and wanting to see what the site is for, and what others are doing there.

So how does the site administrator make sure visitors can see those profiles?

Who is in control? Do profile owners always have the power to make their own profile public or private (i.e. published or not published?). Can Admin. make this optional or not optional by default?

In my case, as Admin., I want profile owners to be able to publish or unpublish their profiles, and for their profiles to be easily seen by all users if published. So I will be selecting "Display to (group) all users including logged-out" for every field in the create form and every field the settings form. Does 'display to all users including logged out' mean that a selected field will be seen on all profiles in all quotas by all visitors to the site?

The problem I have is that nothing I do with the form designer seems to have any visible effect on profile pages.

A few fields have previously been hard-wired (at my site publishscience.net) to be visible on profile pages, but 'Display' for a newly created field in the 'Form designer' does not seem to mean actual display on profile pages.

There are missing steps and no direct links between designing a form field, choosing display options for a set of fields, and actual display to people looking at the site.

In principle, there are four categories of PEOPLE who might or might not see a published profile:

A. Logged in Master Admin.
B. Logged in profile owners
C. Logged in network members
D. Non-members and all logged-out members, profile owners, and Admin.

As a logged in Master Admin., I would like to be able to design a sign-up form with muliple fields, for a specific quota, and then do a preview of how it will look to the people in Group D.

And then, with one click (i.e. "Save form" button), I would like it to become the form that new members see when they sign up, confirm with their own preview for their primary member profile, and then publish. And I would like that to be the same form they see when they return to the site and want to edit their regular member profile data. Forms designed for other quotas should be set up and work with similar convenience.

For my network, I would prefer 'publishing a completed, filled-in form' to mean publishing for Group D, but for other networks the default might be to publish for group C, or logged in members of a 'private group' within a larger network membership.

I agree that flexibility is good, and needed, but I wish the Jamroom administration system could be more admin-friendly and regular-member-friendly in its operation.

I can see that the basic system is fantastic, but in this essential matter of form design, it remains unusable for me.

In short, I don't know what 'display to Quota means'. What does this mean?
updated by @researchcooperative: 02/02/16 07:38:15AM