This was a comment on my other post but I want to raise it as its own issue as to whether this solution addresses the problem of new users not knowing how to create a Page or Group on Friendica?#Friendica @developersRE: dillyofapickle.com/objects/8aa…

[randompenguin@dillyofapickle.com]

@marcusxms I think I would prefer linking to the help page descriptions rather than putting them in that form. Friendica is too cluttered to begin with, I don't want to clutter it up even more.

[andy@friendica.hubup.pro]

Nice @randompenguin

I think the account types in THIS drop down menu should use clearer logical terms.

I am not suggesting to rename the account types, but to think about whether a slightly modified wording here would be helpful to a new user who hasn't read any explanations about Friendica's account permissions.

• Personal (default)
• Personal (soap-box)
• Personal (love-all)
• ...

[randompenguin@dillyofapickle.com]

@andy I agree with that. I was considering:

• Personal (standard account)
• Personal Soapbox (auto-approve Follow requests)
• Personal Love-all (auto-approve Friend requests)
• Organization Page
• News Page
• Public Group
• Restricted Group
• Private Group (experimental)

Not sure about including the explanations behind Soapbox and Love-all though.

[marcusxms@friendica.dk]

@andy @randompenguin As for some terminology improvements, how about this PR?:
github.com/friendica/friendica…

I've kept longer descriptions for soapbox and love-all since I think what one sends/receives is a "contact request" that can then either be accepted as a follower or friend. The request type is the same? Also considering "connection request". On the other hand, on Facebook "friend request" is more common, where maybe other networks don't have friends but just following in either or both directions.

[randompenguin@dillyofapickle.com]

@andy @marcusxms Private Groups automatically accept new followers? That doesn't seem right if that's how it works. Shouldn't a private group require manual approval of new members?

[randompenguin@dillyofapickle.com]

@andy @marcusxms I don't think "connection request" or "connections" is the way to go with terminology. I think most people are familiar with the terminology of "Friend request" and "Followers" over "connections."

IMO Friendica should really try to use the more common terminology. Which is why I think "nickname" should also be replaced with "handle." "Circles" is probably fine, though "Lists" seem to be the more common term for such a feature. That's what Mastodon calls it. That's what Facebook used to call it, when they had that feature.

[randompenguin@dillyofapickle.com]

Is there any reason I shouldn't be exposing the account type and page flag data on the front-end?

The way I wrote my mod each option has a numerical value. The first digit represents the account type and the second the page flag. So any URL with parameters to auto-select an account type from the dropdown would be like ?type=32.

But it could also be written to use strings for the option values and then equate those to numbers on the backend, so then the URL with params would be like ?type=group.

[marcusxms@friendica.dk]

@randompenguin Right now there's two scenarios right?: The regular account creation flow that allows creating any account type, and then there's the create new group button which could then limit the list to groups and preselect one of those?

I think I'd do something like make endpoints on the backend either return a list of all account types or only groups (fx. based on a GET parameter), and then the frontend preselects whatever is first in the list.
Then if, on the backend, new types are added, or a new account type is made default, the frontend automatically selects the new one? think fx. assuming a given number for a particular account type in the frontend would be more likely to break in the future, as new changes happen, because when the meaning is duplicated they can get out of sync and that would break things.

I think I'd use "type=group" over a (magic) number.

Edit: I hoped that answered it and I didn't miss your point.

[randompenguin@dillyofapickle.com]

@marcusxms I don't really know how to correctly create a new endpoint in Friendica. I assume there's some preferred way of doing it and I'm pretty sure I wouldn't accidentally do it the right way.

[marcusxms@friendica.dk]

@randompenguin I'd make the link to create additional accounts pass GET variables both to indicate additional registration and the type, so something like:
register?additional=true&type=group
...or it could be a single variable with multiple distinct values.

...then in Module/Register.php in content() I'd fetch that GET variable:
$var = $_GET["type"]
$anothervar = $_GET["additional"]

...and then if additional is set I'd pass a list of account types to the template, and if type is group that list of account types would only be groups.

Then the template just doesn't have any specific filtering logic for this - it just renders the list of all account types it receives, if it receives any.

Also I think now or at some point we should split off the additional registration template from the regular registration template, because they should likely differ quite a lot in the future, both in allowing one to set the account type but probably also other things like the help text. Then additional registration could possibly also omit the password as suggested, but then the form handling function should be able to distinguish initial registration from subsequent registration and only require the password in the first case.

[randompenguin@dillyofapickle.com]

@marcusxms I can see the value in the URL parameters being human readable rather than a "magic number." Really the only thing I don't like about switching from a number to a string is processing the number into the database takes 2 lines of code while the string requires 36 lines of code (because it needs constants defined first then needs a switch-case to equate it to the numbers).

But that part is all on the backend and invisible to users. The URL params are visible to users in the browser address bar, so should probably be human readable.

[randompenguin@dillyofapickle.com]

Out of curiosity, is there some particular reason to hide the label on password fields? Both the core and theme field_password.tpl templates have this in them:

{{if $label != false}}
	<label for="id_{{$field.0}}">{{$field.1}}{{if $field.4}} <span class="required" title="{{$field.4}}">*</span>{{/if}}</label>
{{/if}}

It's easy to override it by putting {{assign name="label" value="true"}} before the template call, I just don't understand why it normally hides the password field label?

[randompenguin@dillyofapickle.com]

@marcusxms Oh, okay I get it now. I guess I was confusing "endpoint" with "route" and was thinking I needed to create a whole new URL in routes with another PHP page and template. If it's just getting the URL parameters and working with them on the backend that's not a problem. I already wrote JS to do this on the client side so I'll just rewrite that in PHP.

[marcusxms@friendica.dk]

@randompenguin It seems the post() function already knows whether it's an additional account, so based on that it could process and set the account type received. It sets this variable:
$additional_account
...to either true or false already.

So then one can check if it's true and in that case check what the submitted, requested account type is and set it.

[randompenguin@dillyofapickle.com]

@marcusxms Nice!

[randompenguin@dillyofapickle.com]

Okay, I've incorporated the suggestions and I've got it working on my Dev Server.

So the final product will use human-readable URL parameters, so if it is "?type=group" only the three Group options will be in the dropdown list. And I did something similar for the "Page" and "Personal" options. No/invalid params means it shows the whole list of account type options. Trimming the list and pre-selecting is now handled on the backend in PHP rather than on the front-end with JS.

I'll try to put this together into a PR sometime this weekend.