¿ªÔÆÌåÓý

  1. GroupManagersForum
  2. Topics

Additional member attribute(s) #suggestion

 

Has there been any thought/discussion to add one (or more) fields to the member information?

Not trying to turn the member list into a full-out database - but for some lists it's nice to have one more bit of information about a person.? ?What street you live on for the neighborhood list.? What your plot number is for the community garden list.? ?Stuff like that.?

I could certainly add a database, but that would have to be maintained separate from the list membership, which will end up being out of sync over time.??

Couldn't find anything searching old topics - is this wish list worthy?

- John Mc
 

John Mc,

Has there been any thought/discussion to add one (or more) fields to
the member information?
There is one "extra" field. If you open a member's page there's the "Notes" tab.

Alas, that feature is rather out-of-sight-out-of-mind right now, there's no indication given in the list that it holds content, and there are no notifications when a moderator updates that field. At least the update does get logged in the Moderator Activity log.

Not trying to turn the member list into a full-out database - but for
some lists it's nice to have one more bit of information about a
person. What street you live on for the neighborhood list. What
your plot number is for the community garden list. Stuff like that.
I've often wished for functionality like this, but I've never come up with a proposed "best" way to do it.

Just adding more fields to the Members list is one approach. But it can make that list cluttered, which could ultimately be an impediment to its primary use cases. Maybe there would be a clever way to manage what is shown when there are too many columns to fit the user's window; a bit like Excel's split and/or freeze features.

I've also thought of having it be another selector, "Notes", in the Members list view button that currently selects Members, Moderators, Pending, Bouncing, or Banned. When "Notes" is selected then the custom fields are shown rather than the standard fields. But I think you'd have to have at least the email field automatically included, or both email and Display name. So you rapidly run into the same width problem as having them in the primary members list.

A pro or con of those ideas (depending on your use case) is that it would be available only to moderators.

Possibly one could do a similar thing built on the member Directory so that it could be made available to members if desired. In my classmate groups it would be desirable to allow members to add their current address, phone number, nick-name in school, activities, or other information to help everyone remember them. Even a second "then" picture to go with their current profile photo/avatar.

Couldn't find anything searching old topics - is this wish list
worthy?
I'd say yes. We could kick it around here some more if you like, or just go for it in beta.

Shal
 

OK, I found the Notes field, but when you do a Search it doesn't search said notes field.? But as you suggest you could put the Notes in the drop-down; that might be useful

Seems like we have two different use cases.? ? ?I'd like a field that I can search on and email this subset of members.? ?But your use case of just 'additional information' on members, and let them fill in what fields they wish.

Your examples make me think - One implementation could be to create a default database for each group created called 'members'.? Tie it to the member list, but we could add any fields we wanted to.? If a member went away the entry in this database would go away.? Database could have the standard 'choose visibility' settings? (Now I wonder if this is become implementation gone wild.? :-)


I'm up for anything in beta - depends if you want to try a simple use case though (make notes searchable) or something more involved and database-like

- John



On Wed, Jan 10, 2018 at 12:27 PM, Shal Farley <shals2nd@...> wrote:
John Mc,

> Has there been any thought/discussion to add one (or more) fields to
> the member information?

There is one "extra" field. If you open a member's page there's the "Notes" tab.

Alas, that feature is rather out-of-sight-out-of-mind right now, there's no indication given in the list that it holds content, and there are no notifications when a moderator updates that field. At least the update does get logged in the Moderator Activity log.

> Not trying to turn the member list into a full-out database - but for
> some lists it's nice to have one more bit of information about a
> person.? ?What street you live on for the neighborhood list.? What
> your plot number is for the community garden list.? ?Stuff like that.

I've often wished for functionality like this, but I've never come up with a proposed "best" way to do it.

Just adding more fields to the Members list is one approach. But it can make that list cluttered, which could ultimately be an impediment to its primary use cases. Maybe there would be a clever way to manage what is shown when there are too many columns to fit the user's window; a bit like Excel's split and/or freeze features.

I've also thought of having it be another selector, "Notes", in the Members list view button that currently selects Members, Moderators, Pending, Bouncing, or Banned. When "Notes" is selected then the custom fields are shown rather than the standard fields. But I think you'd have to have at least the email field automatically included, or both email and Display name. So you rapidly run into the same width problem as having them in the primary members list.

A pro or con of those ideas (depending on your use case) is that it would be available only to moderators.

Possibly one could do a similar thing built on the member Directory so that it could be made available to members if desired. In my classmate groups it would be desirable to allow members to add their current address, phone number, nick-name in school, activities, or other information to help everyone remember them. Even a second "then" picture to go with their current profile photo/avatar.

> Couldn't find anything searching old topics - is this wish list
> worthy?

I'd say yes. We could kick it around here some more if you like, or just go for it in beta.

Shal
 

John,

Seems like we have two different use cases. I'd like a field that I
can search on and email this subset of members. But your use case of
just 'additional information' on members, and let them fill in what
fields they wish.
Yes, yours is moderator's info for actions, mine was info for all members. Of course I'd still like to be able to search mine.

I'm a lot less certain about enabling members to take actions like emailing the subset found by search. That could be powerful but it could also be disruptive in some groups.

Your examples make me think - One implementation could be to create a
default database for each group created called 'members'. Tie it to
the member list, but we could add any fields we wanted to.
That's yet another good idea.

I think, rather than making it a default database, I'd have a new column type that ties to the email addresses in the Members list. Adding a column of that type to a table would enable the linked functionality (auto-populate a row for each member).

This also addresses the member/mod visibility question by making it the table creator's choice. We'd likely need to think about whether the address field should have its own visibility control for member/mods - as I suspect my case for allowing members to see each other's addresses is the rarer case.

If a member went away the entry in this database would go away.
That's one feature I would *not* like. And it has been one of the reasons I've not worked out a proposal in detail. I hate the idea that I'd lose information just because a member took the (all too common) approach of changing their email address by unsubscribe/resubscribe.

Premium groups have a "Past" members list which retains information about members who've left or been removed. I'd like a table like this to retain rows for "past" members, but marked somehow as such. However this may encroach on the Premium feature so I'm not sure Mark would go for it.

(Now I wonder if this is become implementation gone wild. :-)
Maybe. Once you start down the direction of creating relational tables it seems like things could get wild pretty quickly. But then the whole site is built on database queries, if I understand correctly, so it may not get as wild as I think (databases are not my specialty). Perhaps it would primarily be a question of user interface complexity, and that's what would most likely impact Mark's willingness to implement.

I'm up for anything in beta - depends if you want to try a simple use
case though (make notes searchable) or something more involved and
database-like
Go ahead and suggest what is right for your use cases. I'll chime in there or not, or maybe make my own suggestion if I feel inspired. Groups.io already has a lengthy to-do list, even in the Database column, but I think we have to trust to Mark's judgment about implementation priorities.


Shal

1 - 4 of 4