Date   

moderated Re: Member Data Improvements request #suggestion

John Wirtz SF
 

Interesting stuff.  However, these sites don’t talk about people not having names but rather how different cultures treat names.

I’d expect the majority of groups her are pretty conventional in terms of name requirement.

 

Long Company names is an easy thing, just define the number of characters allowed in a field.  It’s not unusual for a text field to accept up to 255 characters I believe.  Developers restrict this property with very large databases to save storage and also accelerate searches and indexing. 

 

A lot of this depends on how the subscribers database on group.io is organised and it’s properties are defined.

 

Regards

 

John
SFSS group

 

From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Jeremy H via groups.io
Sent: 08 April 2020 10:56
To: main@beta.groups.io
Subject: Re: [beta] Member Data Improvements request #suggestion

 

Ah yes - see https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/ (based on https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ ), https://blog.jgc.org/2010/06/your-last-name-contains-invalid.html or https://www.w3.org/International/questions/qa-personal-names. Or the discussion in https://developers.slashdot.org/story/10/06/17/2347257/falsehoods-programmers-believe-about-names .

Or the somebody's struggle with (IIRC) Hawaii DOT - they wanted her full legal name - she said it has 39 letters, your system will only accept 38...

So - if a group does have a requirement like this - I would go with Duane's idea of extra, group definable, fields. And a group wanting to make them mandatory will have a group management issue as to how it does so.
I think that's the only thing we can reasonably ask Mark to implement.


moderated Re: Member Data Improvements request #suggestion

Jeremy H
 

Ah yes - see https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/ (based on https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ ), https://blog.jgc.org/2010/06/your-last-name-contains-invalid.html or https://www.w3.org/International/questions/qa-personal-names. Or the discussion in https://developers.slashdot.org/story/10/06/17/2347257/falsehoods-programmers-believe-about-names .

Or the somebody's struggle with (IIRC) Hawaii DOT - they wanted her full legal name - she said it has 39 letters, your system will only accept 38...

So - if a group does have a requirement like this - I would go with Duane's idea of extra, group definable, fields. And a group wanting to make them mandatory will have a group management issue as to how it does so.
I think that's the only thing we can reasonably ask Mark to implement.


moderated Re: Member Data Improvements request #suggestion

Bärbel Stephenson
 

People in e.g. Mongolia have a single word as a name, no first or second name, just the one word name.

Ever increasing amount of people do not want to be identified by a gender, so title if they do not have a PhD or other such professional title that could also cause an issue for them.

Barbara

On 8 Apr 2020, at 08:29, John Wirtz SF <john@...> wrote:

Christopher,

I don't get this. Can you give me instances of a group that has members without names.

I stress that should the mandatory option be available - I suggest it as an option - our group would insist on that data. I don't want to deal with people who have something to hide as hey are the most likely to cause trouble down the line under the protection of anonymity.

We have run groups since 2001 and I can count less than five trolling type incidents.

Cheers

John
SFSS Group



-----Original Message-----
From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Christopher W.
Sent: 08 April 2020 01:00
To: main@beta.groups.io
Subject: Re: [beta] Member Data Improvements request #suggestion


On 2020-04-07 at 9:49:03 AM, John Wirtz SF <john@...> wrote:

Desirable additional fields would be:
- Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc)
- Firstname (mandatory field)
- Lastname (mandatory field)
I don't think that any of these can be mandatory. Not everyone has a title, a first name, or even a last name.

--
Christopher W. <lists@...>







moderated Re: Member Data Improvements request #suggestion

John Wirtz SF
 

Christopher,

I don't get this. Can you give me instances of a group that has members without names.

I stress that should the mandatory option be available - I suggest it as an option - our group would insist on that data. I don't want to deal with people who have something to hide as hey are the most likely to cause trouble down the line under the protection of anonymity.

We have run groups since 2001 and I can count less than five trolling type incidents.

Cheers

John
SFSS Group

-----Original Message-----
From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Christopher W.
Sent: 08 April 2020 01:00
To: main@beta.groups.io
Subject: Re: [beta] Member Data Improvements request #suggestion


On 2020-04-07 at 9:49:03 AM, John Wirtz SF <john@...> wrote:

Desirable additional fields would be:
- Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc)
- Firstname (mandatory field)
- Lastname (mandatory field)
I don't think that any of these can be mandatory. Not everyone has a title, a first name, or even a last name.

--
Christopher W. <lists@...>


moderated Re: Member Data Improvements request #suggestion

John Wirtz SF
 

I’m no database developer but un-defined fields could cause problems as they would be likely contain incompatible data from group to group, i.e. numbers, text, etc.

Normally, when setting up field properties, it is wise to specify the type of field content.

 

My rationale is that most people will be happy to supply First and Lastnames along with their email addresses.  Anymore then that (addresses etc) become more controversial from a data protection point of view.

The “mandatory” is easy,.  In the field properties, one can set an option to not a allow a ZERO VALUE.  Just needs a toggle to switch it on or off in line with the group owner’s preference.

 

Anyway, over to the developers….

 

John
SFSS Group

 

 

.

 

From: main@beta.groups.io <main@beta.groups.io> On Behalf Of Duane
Sent: 07 April 2020 20:26
To: main@beta.groups.io
Subject: Re: [beta] Member Data Improvements request #suggestion

 

On Tue, Apr 7, 2020 at 11:57 AM, John Wirtz SF wrote:

Desirable additional fields would be

Something that I just thought of.  Instead of having dedicated fields added, how about having 5(?) extra fields in the member record that could be used by group management for whatever purpose they want.  (It would be up to them to keep a list of what it represents.)  I'm sure there are some groups that would want 30, but 5 seems like a reasonable number and can contain a lot of information if used wisely.  That also might make it more likely to be implemented since it could cover a lot of applications instead of a few specifics.  I don't know how difficult it would be to make them mandatory for a group where they're used though.

Thanks,
Duane


moderated Re: Member Data Improvements request #suggestion

Christopher Warrington
 

On 2020-04-07 at 9:49:03 AM, John Wirtz SF <john@...> wrote:

Desirable additional fields would be:
- Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc)
- Firstname (mandatory field)
- Lastname (mandatory field)
I don't think that any of these can be mandatory. Not everyone has a title,
a first name, or even a last name.

--
Christopher W. <lists@...>


moderated Re: Member Data Improvements request #suggestion

Duane
 

On Tue, Apr 7, 2020 at 11:57 AM, John Wirtz SF wrote:
Desirable additional fields would be
Something that I just thought of.  Instead of having dedicated fields added, how about having 5(?) extra fields in the member record that could be used by group management for whatever purpose they want.  (It would be up to them to keep a list of what it represents.)  I'm sure there are some groups that would want 30, but 5 seems like a reasonable number and can contain a lot of information if used wisely.  That also might make it more likely to be implemented since it could cover a lot of applications instead of a few specifics.  I don't know how difficult it would be to make them mandatory for a group where they're used though.

Thanks,
Duane


moderated Member Data Improvements request #suggestion

John Wirtz SF
 

Email Distribution Groups – General observations

The main purpose of such a group is to enable us to be able to reach all our subscribers (also customers) from a single email address with messages delivered directly to their email client inboxes.

Despite popular opinion, Facebook has never been an effective replacement for email groups.

We are ex users of “egroups” and “Yahoo Groups”

So, why do we favour the use of email groups?

Running a small business with limited resources, the group is ideal to send targeted messages to our subscribers, straight to their email client inboxes.

Once the site is set up – the manual is a great help – the group needs little maintenance.

The most onerous task is subscriber management.

Like most small businesses, we have a developed customer database. 

In an ideal world, I’d like to manage customer group subscriptions to the group from our own database – I am very wary of duplication – and have a dedicated table synced to a MYSQL type table on Groups.io either directly or to the subscriber’s database.  Failing that, links between these data sets could exist internally to the group.io between the database section and the subscriber’s database table.  The table facility in the database section already exists.

The current problem is that the main subscriber’s listing doesn’t carry enough fields against which to filter and search records. 

Desirable additional fields would be:

- Title (mandatory field, drop down (Mr, Mrs, Ms, Dr, etc)

- Firstname (mandatory field)

- Lastname (mandatory field)

These fields would make searches and filtering a lot easier and by consequence would greatly ease the subscribers maintenance process. 

Our own policy is to not allow anonymous membership as it is always those who are likely to mis behave thinking they are immune form recognition.  At present we are forced to use the “display Name” field to record that information and it cannot be made mandatory.  Searches are not instant as we have first and lastname in a single field.

I realise it is possible to download a “csv” file but even this requires two steps from the groups site.  Once downloaded, one has to split columns and carry out other manipulation before the data is ready for use.

As a general comment, I am always a little surprised that after many years of experience of open communications across the internet, social media and forum platforms allow anonymous membership. 

Concluding, I would like to see improvements in the subscriptions data table – additional fields - and syncing of internal and external data tables.

I would add that it’s refreshing to know that one can reach out to those who are empowered to make changes and improve the site.

John Wirtz
Owner SFSS Group

 


moderated Re: Digest sent before member accepted #bug

 

On Mon, Apr 6, 2020 at 7:56 AM Marv Waschke <marv@...> wrote:
On April 4, a user requested membership to our restricted, private archive group, received our standard reply asking for more information. Before replying, the as yet non-member received a message digest from the group. They mentioned this in their reply. I approved the request for membership. The logs show the request and acceptance, but no email delivery is recorded. I believe both the delivery of the digest and the absence of a log record of the delivery in the Email Delivery History are defects. The group is trollope.groups.io. The member is EJP.


The logs cycled before I was able to look at any possible digest delivery (I've increased the log retention on those logs now). But I went through the code and I don't see how that could have happened. 

Please let me know if you see something like this again.

Thanks,
Mark


moderated Re: Site updates #changelog

 

I could do without both the “active topics” and the ugly hashtag thingy. I get really tired of someone trying to direct what I do and don’t read and engage with. This seems to be happening on a lot of platforms in attempts to be more “social”. 

For those folks who prefer to be controlling with their group members, enjoy. Just give the rest of us the option to not opt in (and make it an “opt in” rather than an “opt out”).


Patti


moderated Re: Digest sent before member accepted #bug

Chris Jones
 

On Mon, Apr 6, 2020 at 04:05 PM, Marv Waschke wrote:
Could that have affected the digest sending logic?
Only time will tell...
(Sorry!)

Chris


moderated Re: Digest sent before member accepted #bug

Marv Waschke
 

I just noticed Duane's comment on Time Zones. The digest was sent across the international date line. Could that have affected the digest sending logic?
Best, Marv


moderated Digest sent before member accepted #bug

Marv Waschke
 

On April 4, a user requested membership to our restricted, private archive group, received our standard reply asking for more information. Before replying, the as yet non-member received a message digest from the group. They mentioned this in their reply. I approved the request for membership. The logs show the request and acceptance, but no email delivery is recorded. I believe both the delivery of the digest and the absence of a log record of the delivery in the Email Delivery History are defects. The group is trollope.groups.io. The member is EJP.
Best, Marv Waschke


moderated Display member time zone #suggestion #done

Duane
 

While I was checking this morning to see if digests were being delivered (based on a question I was looking into), I noticed that some members didn't get one.  Then it dawned on me that they aren't in the same time zone as me (used as the group default) so will get theirs later/earlier.  In cases like this, it would be really handy if there were a notation in their member record of which TZ they have selected.  I wouldn't want to be able to change it, just see it.  Maybe next to or just below the Joined date.  Due to some areas not having an official abbreviation, showing them in UTC might be best.

Thanks,
Duane


moderated Re: Site updates #changelog

Bruce Bowman
 

On Sun, Apr 5, 2020 at 02:22 PM, William Ellis wrote:
I understand people's reluctance to change something that they "see no value" but for those of us with groups where it would be a plus - why not.
IIRC, the main concern expressed with the new homepage wasn't so much the addition of an "Active Topics" div, but that the big "Top Hashtags" buttons tend to dominate the layout. In turn, the current hashtag layout is difficult to tap/navigate on mobile devices.

If the new layout was implemented in conjunction with a setting to hide the "Top Hashtags" div entirely, I believe this might go a long way toward resolution of the deadlock.

Regards,
Bruce


moderated Re: Site updates #changelog

 

Mark;

How about giving the Admin of a group the right to upgrade the home page?  I understand people's reluctance to change something that they "see no value" but for those of us with groups where it would be a plus - why not.

I don't know what it is like to do something like letting people select and I am sure it is more work than rolling it out everywhere.

We.


moderated Re: Site updates #changelog

Duane
 

On Sat, Apr 4, 2020 at 10:24 AM, Mark Fletcher wrote:
I would still like to roll it out everywhere because I think it's a superior experience.
Will it be an option or mandatory?  I still have the same reservations about the new page layout as when it was originally announced.

Thanks,
Duane


moderated Re: Site updates #changelog

Andy Wedge
 

On Sat, Apr 4, 2020 at 06:35 PM, Mark Fletcher wrote:
I made a mistake and forgot to remove that from the list before I posted it.
If it was just a mistake then no problem. At least we understand the discrepancy between the changelog and what actually changed. Hopefully the changes to the homepage and the Zoom integration can be rolled out shortly.

Many thanks,
Andy


moderated Re: Site updates #changelog

 

On Sat, Apr 4, 2020 at 9:27 AM Andy Wedge <andy_wedge@...> wrote:
I've seen the previous discussions on the hompage changes and the recent release and rollback of the zoom integration. I am still perplexed by the fact that these changes were included in the changelog when in fact they had not been released. How many of the others in this week's list are like this?


(Many snarky responses typed and deleted).

I made a mistake and forgot to remove that from the list before I posted it.


Mark


moderated Re: Digest generation problem #bug

Jim Avera
 

On Fri, Apr 3, 2020 at 04:12 PM, Mark Fletcher wrote:
Is anyone else encountering missing messages in digests?
I think I've received a couple of "digests" containing only a single message in the past week.