Forum Activity for @researchcooperative

Display settings for profile template fields - how to select for editing vs viewing purposes?

Using Jamroom

Sorry - I was confused when I wrote my confusing post. I was talking about the areas shown in the attached screen shots.

What I was trying to understand was that when we set up the profile-image.tpl field, it has to be marked as active in a check box, and it also has to be assigned to ("displayed to") one or more quotas (or user groups) where we want members to be able to see the field and edit their profile images.

I have now set this to "Normal Users" - thanks Paul!

The "default profile privacy" is determined by quota configurations for the profile module, and in my site this is set to "Global - visible to everyone". So when my members update their profile image, any visitor can see it.

I will call this post solved.

Is it feasible to build a central "Text editor settings" control module?

Suggestions

Re Michael's advice... Having an easy way to remove text formatting in the editor would be useful (and a lot easier than using copy and paste into the text editor of an external email program to use the formatting removal button there). It could be useful as a standard feature for many site users because it is a common action to copy text from a formatted source into a post. Removing all previous formatting can make it easier to apply new formatting.

However, my no. 2 question above was really how to format a block of text in Open Sans after it has been formatted in something else. Open Sans is not in the drop-down list. It is only available as the automatic default. It is a good default font, but is there any reason why it cannot join the other fonts in the drop-down list?

My no. 1 issue above seems to have been solved. Since I first wrote, there has been update of the tinymice editor in one of the modules, and now I am seeing the same default font options in Sitebuilder as in other areas of the system. I don't know if this is because of the module update, but in any case THANKS!

Re no. 3 question about a "centralised control panel for default text editor settings"... That was a big ask I suppose, as there has been no reply to that part of the post (sorry for making a complicated post).

I am happy enough with the default size range that is now everywhere the same (8, 9, 10, 11, 12, 26, and 36). I would tweak it if I could do so easily (with an editor settings control panel) but this is not an urgent matter. The default range of font styles is also good for my purposes.

Is it feasible to build a central "Text editor settings" control module?

Suggestions


This works if you write a text, format the text, and then have no wish to return that text to the default font.

If you do want to take the existing text back to Open Sans, it has to be completely rewritten. It can't be selected and reformatted with the default.

Indecisive perfectionists have a problem here.

Perfect decision makers don't!

Is it feasible to build a central "Text editor settings" control module?

Suggestions

Here are two screenshots, one for a Blog entry, one for a Sitebuilder text html widget

Thanks

Is it feasible to build a central "Text editor settings" control module?

Suggestions

Thanks. I've just now resurveyed the font scene...

The following areas all offer the font sizes 8, 9, 10, 11, 12, 26, and 36: Blog, Comments, Pages, Forum, Group description, Documentation, Comments.

The Site Builder text editor is different: 8, 10, 12, 14, 18, 24, and 36.

I've actually used 26 as a heading in a blog post. Some people might want 36 occasionally. Perhaps if the JR default options were to be unified for all text editors, the range should be 8, 9, 10, 11, 12, 14, 18, 24, 26, 36 (ten choices).

On my site, if I could easily set the range to ten choices, with a central font control setting, I might choose:

10, 11, 12, 14, 16, 18, 20, 22, 24, 26

I think at present, JR has provided text editors in all the public-facing areas where they are needed, and avoided them in areas where it is good to have a single default.

Is it feasible to build a central "Text editor settings" control module?

Suggestions

1. I have the impression that the text editors used in different parts of the JR system have been pulled in from different places, and are not unified in the range of font sizes offered (and perhaps also not in the range of styles offered... sorry, I have not checked).

2. The editors also seem to use "Open Sans" as a default, but "Open Sans" does not appear in the font-style drop down list. This means that if I convert a text to another font to see how it looks, I cannot convert back to Open Sans.

3. What I would like is a centralised control panel (a "Text editor settings" module?) that tells all the editor-related widgets:

(a) what range of font sizes should be shown on all editors,
(b) what font styles should be made available from those that JR offers as default, and
(c) what the default font size and style settings should be for the entire site, inside all text boxes, whether an editor is provided or not.

This way, it would be possible to create a standard look across the entire site without having to learn and visit all the nooks and crannies where code has to be changed in order to change font options in the text editors.

In the end, I would like to easily select a range of font sizes that is more likely to be useful for my particular site. At present we have some common small fonts, up to 12, and then there is a big leap to large font sizes:

8, 9, 10, 11, 12, 26, 36 (seven choices provided)

I would like to have text editors that show font sizes of:

10, 11, 12, 14, 16, 18, 20 (seven choices wanted)

I think for readability of larger text areas, font sizes in the range 10-14 are most likely to be needed.
Below 10 is way too small for most purposes, and the sudden jumps -- from 12 to very large (26) and enormous (36) -- skip sizes that are more likely to be useful (in my book, so to speak).
updated by @researchcooperative: 03/10/19 12:09:06AM

Display settings for profile template fields - how to select for editing vs viewing purposes?

Using Jamroom

Today I found a curious thing - the option to edit a public profile image (independent of the signup registration image) does not just depend on activating the template field (profile_image) for a given quota. It must also be set up to display in that quota.

Without both settings, the edit image widget thing that appears on the profile image links through to the profile editing page, but no field is shown for actual editing. I found that I could solve this problem by using the display options to display the profile_image template to the quota that holds the profile.

So "display" in the display settings for the field can mean two things, display for users and visitors to the site, and display for editing purposes in the profile settings form.

Display options include "Display to all users, including logged out", but do not include "Display to all quotas (for the purposes of editing by profile owners)"

Because the display options panel includes both various user groups and different quotas, I am chronically confused about which combination of display options is going to be needed for a given module or module template.

Would it be possible to separate, in different fields for selection, the display options for users, and the display options for quotas, and explain separately, in each case the significance of choosing to display or not display the item in question?

In the present instance, I do want (a) all profile owners to be able to edit the public profile images of all profiles they own, and (b) all users to be able to see the public profile images created by profile owners.

For this, what should I do?

Should I:

(a) select all quotas individually (to make the editing function available for all public profiles), and

(b) select the "all users "group, including logged out users" (to make the profile images visible to all visitors to the site)?

If so, then it might be useful to have an option to display a template field to "all quotas". Then, for an item that we want all visitors to see, and all profile owners to have editing options, we would only need to select the "all users" and "all quotas" options.
updated by @researchcooperative: 03/07/19 11:44:52AM

Products module for profiles selling with Paypal - How to explain the Shipping and Handling price?

Using Jamroom

In case it is useful, here is the URL where I am testing the Products module:

researchcooperative.org/awaraku-press/product

I have nominally 8,000 members who are mostly academics, many of whom might like very much to have an easy way to resell books they no longer need, in a community of other academics.

Thanks
updated by @researchcooperative: 11/23/18 06:05:03PM

Products module for profiles selling with Paypal - How to explain the Shipping and Handling price?

Using Jamroom

The new Products module is embedded in JRCore, and looks great to me. It is set up so that any member can use their own Paypal account to receive payments for physical products sold from their own profile.

There is no need for the network owner to pay an expensive subscription to Foxycart, but the system is limited to Paypal. I see this as a good stepping stone option. If network members like it and there is demand, then it may become worthwhile for the network owner to invest in Foxycart.

The module asks the profile owner to first define one or more product categories, and then add products within each category. The set up has very useful generic features that can be used to sell and offer shipping for products in many different ways. Since one item can be given only one price at a time, we have to list the same item twice (e.g. for local and international shipping) if we want to show different prices. For a small number of products, this is not a problem.

When a product is added, two fields are automatically shown (corresponding to templates in the form designer): "Shipping and Handling", and "Buy it Now Price". The latter links to the profile owner's Paypal account. For this to happen, the profile owner must add their Paypal account email in the last or near-last field on the profile settings page. The profile must be in a quota for which PayPal Buy It Now module has been activated.

What I don't understand is this:

Should the "Shipping and Handling" price appear along with the "Buy it Now" price when a buyer pays for the product, or should the seller set a "Buy it Now" price that includes the shipping and handling, and then create a help note for buyers to explain that the "Buy it Now" price includes the stated "Shipping and Handling" price?

In my test of the system, it seems that the "Shipping and Handling" price does not reappear when the potential customer lands on the Paypal page to make a payment. Only the "Buy it Now" price appears.
updated by @researchcooperative: 02/22/19 07:51:37PM

Notifications text for "forum category" - can it be made more generally understandable?

Using Jamroom

One of the default language strings for the notification settings page is the following:

"When you are watching a forum category for new topics how do you want to be notified?"

Even as site owner I don't immediately understand this. How can this be phrased in simple English so that a newly joining member can understand what it means?

For me, the opaque terms are "watching" and "forum category"

Perhaps this could be simplified to:

"If you are following a forum, and a new message is posted, how do you want to be notified?"

Any other suggestions?
updated by @researchcooperative: 11/23/18 01:40:15AM