Date   

moderated Re: Move Default Sub Settings onto Main Settings Page #suggestion

 

Bruce wrote:


Many creators of new groups fail to fill out the Default Sub Settings. ...
To head that off, I suggest that Default Sub Settings be moved to its own block within the main group Settings page...

I think that would lead to more trouble and confusion, both because it would make the Settings page even longer and because it would be mixing to conceptually different types of controls. I don't think defaults for member subscription settings belong mixed in with group settings.

It would be better, I think, to find a way to draw the new group owner's attention to the Default Sub Settings tab.

Perhaps a new group could have a green banner at the top of (each tab of) the Settings page with Settings, Default Sub Settings, Cover Photo, and Member Notices listed as bullet points under a heading reminding the user to review each tab (but not Export Group Data, and I'm really unclear on the Member Sync tab that seems to come and go). As the Update (or whatever) button is used in each tab that bullet item would be removed, until all four are removed and the banner itself goes away. In the banner, each bullet point could have a short phrase or sentence to indicate what that tab is all about.

 
... or if not all of it, at least those portions that relate to time and date.

I like this better. Those settings are arguably misplaced among the new member subscription defaults, as they initialize new user accounts instead. This does cause some confusion. Some new group owners do not have a firm understanding of the distinction between a member's subscription to (membership in) their group versus that member's account at Groups.io.

The settings don't really belong among the group settings either, but at least there are fewer of them so they wouldn't overload that tab so badly.

Shal


moderated Re: Move Default Sub Settings onto Main Settings Page #suggestion

Michael Pavan
 

On Mar 4, 2020, at 8:32 PM, Bruce Bowman <@BruceBowman> wrote:

Many creators of new groups fail to fill out the Default Sub Settings. Later, when they discover that all their current subscribers are on the "wrong" time zone (or whatever), they find themselves needing to retroactively (and painstakingly) fix this setting for everybody, one by one.

To head that off, I suggest that Default Sub Settings be moved to its own block within the main group Settings page...or if not all of it, at least those portions that relate to time and date.
Agree.

PLUS the Default Sub Setting's default should be that of the group's creator as the logical place to start from (not California's).
Many/most groups are all in their creator's time zone, and most creators would likely prefer their members begin with those settings.
Of course, some groups are in more than one time zone (and outlier members will have to adjust theirs).


BETTER YET,
prompt Groups.io accounts (email address) to set (or verify) their time zone before they join each group,
and if that group is set for a different time zone, have them choose which time zone they want for that group.


moderated Re: Move Default Sub Settings onto Main Settings Page #suggestion

Ann Wild
 

Bruce, i totally support your suggestion. But there does not appear to be a way for an owner to change the time setting "one by one," as you suggested.  I tried and couldn't do it.  If I could make individual changes, I would be willing, though it would take a great amount of time.  Duane says each member has to make their own individual change. How unfortunate that I initially missed that setting!


moderated Re: Profile Privacy #suggestion

Andy Wedge
 

On Thu, Mar 5, 2020 at 06:14 PM, Peter Rawbone wrote:
Is there a case for the default settting to 'Other Members of your Group' ? 
I wish that were the case for the group I run as I spend some time explaining to people on our restricted membership group how to make themselves visible in it. For more general and open groups though such as GMF and Beta where initial group profile details may be copied from the account profile, I think a warning prompt showing the information that would be visible to other members upon joining (with an option to change those details and settings) would be good if they were subscribing online. For members who subscribe by email though, it would complicate the process.

Andy


moderated Re: Move date #bug

Glenn Glazer
 

On 3/5/2020 10:16, Mark Fletcher wrote:
Happy to change the label to something else if we can agree on something better.

Thanks,
Mark 

My suggestion would be for two columns: date uploaded and date modified. The first is invariant and never changes, the second changes on re-upload, moves, permission changes, etc.

Best,

Glenn

--
PG&E Delenda Est

Virus-free. www.avast.com


moderated Re: Move date #bug

 

On Thu, Mar 5, 2020 at 10:13 AM Glenn Glazer <glenn.glazer@...> wrote:
I think I've spotted a bug. When a file is moved from one directory to another, the date uploaded changes. I realize this is probably the mtime of the underlying file, but that's not what date uploaded means to me.

Not a bug, in that it's doing exactly what it was coded to do. (also not the mtime of the underlying file).

 
So, preferably, I would see the original date and time of upload preserved, but alternatively change the label if that's not possible.

Happy to change the label to something else if we can agree on something better.

Thanks,
Mark 


moderated Profile Privacy #suggestion

Peter Rawbone
 

We are always encouraging our Members to select to show their details to other group members.  Not easy as some are not particularly computer literate and can't / won't do this.
Is there a case for the default settting to 'Other Members of your Group' ?  I certainly think so.
Regards
--
Peter

[Mod note: Added #suggestion hashtag]


moderated Move date #bug

Glenn Glazer
 

I think I've spotted a bug. When a file is moved from one directory to another, the date uploaded changes. I realize this is probably the mtime of the underlying file, but that's not what date uploaded means to me.

So, preferably, I would see the original date and time of upload preserved, but alternatively change the label if that's not possible.

Best,

Glenn

--
PG&E Delenda Est
 


moderated Re: Default database view #done #suggestion

Peter Rawbone
 

Oddly, it now functions on all pages, thank goodness.

--
Peter


moderated Re: Problem with Time Change for Digest #bug

Duane
 

On Wed, Mar 4, 2020 at 04:34 PM, Ann Wild wrote:
Is there anything I can do to make the 6 AM digest come out at 6 AM EST for all our group members?
There's nothing you can do for the others except have them sign in and go to https://groups.io/account?page=prefs to change their timezone to EST (before the time change on Sunday ;>).

Duane


moderated Move Default Sub Settings onto Main Settings Page #suggestion

Bruce Bowman
 

Many creators of new groups fail to fill out the Default Sub Settings. Later, when they discover that all their current subscribers are on the "wrong" time zone (or whatever), they find themselves needing to retroactively (and painstakingly) fix this setting for everybody, one by one.

To head that off, I suggest that Default Sub Settings be moved to its own block within the main group Settings page...or if not all of it, at least those portions that relate to time and date.

Thanks for your consideration.

Bruce


moderated Re: Problem with Time Change for Digest #bug

Ann Wild
 

Mark, I just changed the timezone to EST for my own account and for the Default Sub Settings for the group, but the latter only applies to new users.  Is there no way to reset the timezone for the group?  I, unfortunately, missed changing PST to EST in the Default Sub Settings when I set up the group.  The real issue is this: Is there anything I can do to make the 6 AM digest come out at 6 AM EST for all our group members? Thanks.


moderated Re: Problem with Time Change for Digest #bug

 

On Wed, Mar 4, 2020 at 11:47 AM Ann Wild via Groups.Io <annlwild=aol.com@groups.io> wrote:
In a recent change, Mark wrote, "Now, we force a digest to be created at 6AM local time for each subscriber, based on their timezone...."  That, however, is not happening for us in the EST time zone.  The last three digests we have gotten have been time-stamped after 9 AM EST, which appears they were sent out on PST time, not EST local time. 

Please check to make sure that your timezone is set to EST. You can do that through the Preferences page in your Account.
 

Prior to the change, the digest that was sent out at 10:30 PST would be time-stamped for us around 3:40 AM EST, which was 5, not 3, hours ahead. I never figured that out given that individual messages are always posted intermediately.
_._,_._,_
It was arriving around 3:40 AM EST because the process that forced digest generation was taking hours to complete (it started at 10:30PM PST). Switching to this new system, along with a bunch of optimizations I did means that digests should go out pretty close to on the hour that they're forced.

Thanks,
Mark 


moderated Problem with Time Change for Digest #bug

Ann Wild
 

In a recent change, Mark wrote, "Now, we force a digest to be created at 6AM local time for each subscriber, based on their timezone...."  That, however, is not happening for us in the EST time zone.  The last three digests we have gotten have been time-stamped after 9 AM EST, which appears they were sent out on PST time, not EST local time. 
 
Our group has a lot of early risers and posters, so the new later digest after 9 AM EST is a problem.  If it were to arrive close to 6 AM, as I thought it would based on Mark's change, that would fine.  But that's not happening, and we are getting fewer messages.
 
Prior to the change, the digest that was sent out at 10:30 PST would be time-stamped for us around 3:40 AM EST, which was 5, not 3, hours ahead. I never figured that out given that individual messages are always posted intermediately.


moderated Storage usage colors #suggestion

Duane
 

I'd like to see the Help page updated to show which colors will represent the various amounts of storage used, maybe a short color bar beside the item name (or even surround the name with the color, like a hashtag).  [I realize that if not much space is used for a specific item that it may not show on the group's Usage/Upgrade/Billing page in the bar.]  I've been able to figure out some, but a couple aren't being used on my groups:

Files - Dark Green
Photos - Dark Blue
Images in databases - ???
Images in wiki pages - ???
Message attachments - Light Blue

Thanks,
Duane


moderated Re: Default database view #done #suggestion

dave w
 

Is this the wrong place to suggest that the user 'Action' buttons should be at the top of the table?

Wanting to give instructions to non literate users is a lot easier when they dont have to scroll to the bottom of page.
Placement may make sense for experienced users, but raw amateurs don't follow quickly.
Thanks
davew


moderated Re: Search Function - Search Options Available From All Pages #suggestion

Bill Hazel
 

While in a discussion on GMF about searching and including the Official Help page in the results, it occurred to me that it could be added as a default option in the drop-down menu at the groups.io level so it would show up on every page.

I'm usually pretty aware of what's on a webpage but it took me nearly 3 months to really figure out that the Official Help page was a completely different source of information and I've looked for help a lot!

The only reason I did figure it out is I kept finding links to it in messages.

Bill


moderated Re: File uploaded dates incorrect #bug

 

On Mon, Mar 2, 2020 at 10:04 PM Andy W <andy_wedge@...> wrote:

it seems the majority of my files are showing an uploaded date of 7-Feb (2020) when they were actually uploaded in 2019. I'm wondering if it had something to so with a #changelog entry from 12-Jan:

The Feb 7th updated date was an unintended side effect of a change I made to optimize our ability to re-index files when regenerating a search cluster. Sorry about that, it's not something that should happen again.


Mark


moderated Re: After deleting member, that member can't request re-subscription (gets "That email addr already registered") #bug

 

On Tue, Mar 3, 2020 at 9:23 AM Jim Avera <jim.avera@...> wrote:
On Mon, Mar 2, 2020 at 01:50 PM, Duane wrote:
AFTER they log in, they should click the Apply for membership button.  All appears to be working as it should be.
No, the user was offered an "Apply for Membership" button, and clicking it should apply for membership. 

I just tested this. Click the Apply button, enter your (existing) email address, and it comes back with an error saying that email address exists and that you need to Log In. Clicking the Log In link in that error message gets you to the login screen, where after you enter your password, the group application flow continues as if you had previously been logged in, and your application is submitted. Is this not what you saw?

 
OTOH, one valid reason to force the user to login to the old account, would be if simply having a GIO account is intended to prevent anyone else from submitting subscription requests in your name.  That's nice, but I would rather there be an explicit "Lock out new subscription requests while not logged in" feature; because doing that by default leads to an unpleasant experience for naive users.

I'm not saying the current Join flow is the best, and I'm certainly open to suggestions for improving it, but having an option and defaulting it to allowing any rando to use your email address to apply to any group is a recipe for abuse.


Thanks,
Mark 


moderated Re: After deleting member, that member can't request re-subscription (gets "That email addr already registered") #bug

Jim Avera
 

On Mon, Mar 2, 2020 at 01:50 PM, Duane wrote:
AFTER they log in, they should click the Apply for membership button.  All appears to be working as it should be.
No, the user was offered an "Apply for Membership" button, and clicking it should apply for membership. 

Whether or not an old account exists, the subscription-confirmation process is the same, i.e. a request is sent to the owner/moderators, who approve it, and the user gets a Welcome email back.  

Making them log into their old GIO account, which they probably don't know exists and don't care about, makes a simple operation complicated and unintelligible for non-tech-savvy people (which describes many people likely to join my group, sad to say).

OTOH, one valid reason to force the user to login to the old account, would be if simply having a GIO account is intended to prevent anyone else from submitting subscription requests in your name.  That's nice, but I would rather there be an explicit "Lock out new subscription requests while not logged in" feature; because doing that by default leads to an unpleasant experience for naive users.

-Jim