This is a proposal to add, essentially, a new dbtable (a database table belonging to an ecore, for those non-ecorey people) to the site: one containing user data, most of which would normally belong on homenodes, and make it universally searchable/viewable. This would end the need for, for instance, EMAR, The Everything People Registry, "out" everythingians, etc, and would also make it possible for users to edit their entries in these themselves, rather than taking up someone elses time, as well of course fixing the (IMO) main problem with moving this sort of stuff out of the nodegel - the loss of its easy viewing/searching.
I've discussed this with several of you individually, as well as in #everything and the chatterbox, and the general consensus is that it's a good idea. I'd love to hear further comments: I'll add any blabbed /msgs I receive to the end of this node, and/or please discuss in edev or by adding a writeup. No-one I've talked to so far has actually expressed an opinion that this is a little GTKY-like, which it is, I suppose, but it will end up *removing* GTKY-type nodes from the nodegel, and will stop people complaining about the loss of a public "out" everythingians/other "blah" everythingians node.
Essentially the dbtable would have three columns: 'user_id', which would be the node_id of the user, 'category', the name of a category, and 'data', the actual data for that category/user. For instance, 'category' might contain 'location' for a particular row, and for me the 'data' field would contain 'Southwick, Wiltshire, England'. Okay, this is a sorta yucky design, no unique column, kinda against the whole idea of a database, but it'd be silly to restrict us to arbitary columns like a normal table structure would have to do. An alternative might be to make category a mere numeric lookup from another table, this would be a little more complicated but probably better, especially if the level power I discuss below were to be implemented. N-Wing says vote and messageignore (db)tables don't have a primary key column.
The category name and data fields would probably be restricted to the 'standard' 255 characters, although the prior should be perhaps be further (artificially) restricted to 50 or so. As CzarKhan says, "It is after-all for basic information and not your life story."
You may wish to take my babbling about databases as just a way to show the design, rather than a way to actually implement the thing. I think we can actually just store this in a hash or something? I admit to having no idea about how that works (I'll work on that after I wake up), but just adding this to the 'user' dbtable would be nice, or even still having a separate table but something indexed by a unique user_id key, for (obvious) performance reasons. (This paragraph was added during period of extreme tiredness. It wouldn't work because searching/viewing in the way I describe wouldn't be (realistically) possible.)
Searching/viewing and editing would be performed via two (or perhaps just one) superdocs. The editing superdoc would be similar to the way everything settings are entered, perhaps? Anyway, perhaps all predefined fields could already be on that page, ready to enter, complete with comboboxes for the ones with limited values, and while new values would be added/removes via a system similar to everything settings, and fields without any values in them at all would be simply ignored (a 'None' option could be added to combo boxes for this).
The searching/viewing superdoc could allow people to view all entries of a certain category (sorted by data, or user name, or length of being a user, or whatever), and also to search for specific values inside that category (searching for 'England' in 'location', or 'bi' inside the 'sexuality' field, for instance). Categories should be selectable via a combobox.
You would also modify the user display pages so that if a user had any categories attached to them then it would be displayed on their homenode; obviously this would be a user setting, which could also specify where the fields were to be displayed. I'd suggest being able to show them before the doctext, after the doctext and after the bookmarks, in some sort of table, and also inside the user details table in some sort of compressed form. There should probably also be a user option to specify whether their database fields should be displayed on their homenode at all, although I'm not sure if this is worth the effort or even sensible. Also, you could provide mini-links to search for other people with the same category existing, or with the same entry under that category, again being an optional user setting for these to appear.
I'd suggest that there be a node under everything settings (only visible and editable by gods) which defines predefined fields and, in some cases, limits available values. brainwave suggests it would be a good idea for some sort of guidelines to be put in place for when this is to be changed (Will it be done after a certain number of requests are made?). Suggested fields, which obviously are just the opinion of me and a couple of other noders and should be defined by the admins:
'location', freeform, but preferably in '[optional place ,]
[state/county ,] country' form (perhaps the latter portion of this could be combobox based or something, maybe involving optional javascript, to try and keep it in the correct form), to replace The Everything People Registry. In fact we could also split it up into multiple edit boxes to keep it consistant.
'address', freeform, to replace EMAR.
'gender', restricted to 'male'/'female'/'other' or something similar. The consensus among the people I've talked to seems to be that allowing this field to be freeform wouldn't be a good idea, your opinion may differ. Maybe rename the title 'physical gender'/'sex' or something, although IMHO that's just silly, we all know what it means.
Starke says Instead of having a bunch of angry transexuals and such, I suggest you have "I was born with a penis" or "I was born with a vagina"
blondino says Gender: I consider myself male/female/neutral and I'd rather not say. (the "I'd rather not say" element shouldn't be an option, it should simply be defined by leaving the entry blank, surely? - fuzzie)
'religion', freeform. Or alternatively we could make this a combined options/freeform selection (see first paragraph after this list) with the options being a large list of religion "categories".
'sexuality', restricted to 'straight'/'gay'/'bi'/'lesbian'/'undecided'.
brainwave says In the sexuality combo box I would like to see asexual as an option. You may think this is a frivilous request, but I think it is a helpful option for priests, nuns and others who are chaste for various reasons (although they may arguiably have another sexuality) as well as those who just plain prefer not to have sex.
PLEASE READ THE PARAGRAPH AFTER THIS LIST BEFORE COMMENTING FURTHER ON THE RESTRICTED NUMBER OF CHOICES PROBLEM!
'homepage', a URL, perhaps automatically placed into a hyperlink.
'picture', a URL, also perhaps automatically placed into a hyperlink and/or img tag.
'email', an e-mail address, again with the automatic hyperlink thing. (Thanks to The Librarian for suggesting this). We could automatically anti-spam this, perhaps randomly.
Perhaps a generic 'interests' field for a command-delimited set of interests. The same for 'hobbies', too, perhaps. I'm not sure about these two; some thinking needs to be done. mkb notes that this would work in a very similar way to LiveJournal.
'aim', 'msn', 'icq', 'yahoo', 'jabber', for userids of people using the 'major' IM programs. We could check at least jabber, msn and icq for some sort of semi-validity, the others are pretty much freeform as far as I know. Also possibly 'irc' for their IRC nick. In most cases it's possible to have some kind of 'online' graphic or 'add me' link associated with these, perhaps we could have these where possible, obviously it would have to be a user pref whether to display them or not.
'livejournal' for their LiveJournal id, which we could automatically link over there, seeming as though many people have moved their daylogging/daylogs over there.
'birthday', which obviously has to be a date (we could validate this input to be in the correct form, a popup javascript calendar would be easy to code). This replaces who to send gifts to, and when.
wertperch says There's also MBTI personailty types, SparkMatch type, possibly others of that ilk.
We could assimilate MBTI types of E2 members, for instance.
We could replace the E2 Family Tree with a superdoc constructed on the basis of an 'introduced by' category, perhaps.
CzarKhan says had you considered a freeform ethnicity portion?
Specifics, such as details about sexuality, could be placed under 'sexuality details' or some other similar category name ... this should probably be bound into the edit page, so that a textbox for entering details is next to any combobox which might exist, to try and enforce naming conventions (note that you could fill in details while not choosing an option from the combobox). We could also bind the search page up like this (if the category is sexuality, you can search for a certain sexuality or 'sexuality details' keywords or both (which should be the default)). This would basically make the options just recommended options, which would be easier for most people, but would not make them mandatory, as they could fill in only the details if required, and most searches would still work.
Or we could just scrap the whole combobox/choice system. sabby says Any box where you have to ponder wording, it's probably easiest to let be plaintext. If they don't fit into a generic "easy" choice, then they are going to want to explain. (Asexual preists, for instance, would most likely call themselves hetereosexual but not practicing, for instance. heh.)
Things such as age, eye colour, height, etc, belong on homenodes; there would be nothing much useful gained by adding them to this list. However there is a suggestion by Oolong that perhaps anonymous statistics based on this might serve to help us work out such things as the average age of our userbase. So perhaps 'age' could be a category, with a checkbox making it anonymous if wished.
Remember, people wouldn't have to fill in any of these fields at all, certainly not all of them, so if they didn't like the restricted options available in some cases, it's their choice whether to have that field at all (or indeed whether to have any field at all). One thing people have commented on the lack of is some sort of 'transsexual' option under 'gender': I personally don't think it belongs there, a separate field would be fine for that, and other people agree with that.
Incidentally, note that we could easily change existing superdocs/create new superdocs to access this data in a nicer way, for instance a tree-like E2 Family Tree-like view for location, possibly entitled "The Everything People Registry" to maintain links which point there.
I would be happy to finish the design of, and implement, this system, if that would be useful to the admins; I have been reviewing and discussing performance implications of this and the such. The other option would be to implement this off-site, which I don't think is an acceptable solution, and neither does anyone I've talked to about this, because it doesn't really help to resolve any of the issues involved, other than site load, again, IMHO.
Another issue which I'd like to state my opinion on is the possibility of some of this being only available to level powers: The one case in which I think this might be a good idea is in the addition of *new* custom categories only being available to higher-level noders. This wouldn't restrict people too much - they could ask a sufficiently high-level noder to temporarily add a category onto themselves, thereby allowing someone to add the category themselves (the original high-level noder could then remove the category, and others could still add it due to it not being a new, unused category any more), and it would help to stop the addition of frivolous categories, which I feel would soon become confusing.
Later note: Also, possibly the automatic linking of the 'homepage' and/or 'picture' categories from homepages could be restricted to higher-level noders (level 2 or above, say) or after verification from editors/much-higher-level noders or something. This would also cut down on abuse.
(edev) sleeping wolf says That's one approach. The big problem is that people will want fields ad nauseam. Since, though, insanefuzzie has written up eir approach, now I a fire lit under me to write up mine. (I wanted to wait until I pseudo coded it)
(edev) insanefuzzie says The ability to add whatever fields people want (preferably limited by if you can get a higher-level user to agree) is part of the whole point of my idea... something flexible which everyone can use for whatever they want.
sleeping wolf feels some kind of nodetype would be best, and that everyone would want to look at things through the specific category, rather than viewing on homenodes. I personally feel that a database would be better, and that people would like to search both ways. Sie also seems to forget that, as the entries would be open to other users, spelling mistakes and the such would probably be noticed (and hence corrected, I'd hope) very quickly.
More to come here as soon as I have managed to retrieve sleeping wolf's e-mail from my currently defunct machine.