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.


  • '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.

After some review, I realized that I perceived this idea differently than it was actually written. It's still not the same as how I think it should work.

Personal Opinion: This is too different from how usergroups work. Certain aspects, such as listing all things a user has listed in their homenode, would take a lot of work from a database standpoint, as I understand it, because it would require querying all known sets of data to find out if a user has listed anything. If the user wants people to know about these things from their homenode, they'll put them there -- that's how it used to be with the "foo everythingians" nodes.

I'm so full of arrogant pride that I'm right (spawned by the fact I just woke up) that I'll even create a fake conversation to detail what I think is wrong with insanefuzzie's idea (which is a lot closer to what I want than one might think) and detail how I think things should be done.

What was the purpose of the foo everythingians nodes, as sleeping wolf perceives it?
To provide an index for users based on qualities they had, and to allow looking for commonalities.

Okay, but insanefuzzie's idea does that.
I don't think so. Let's take a theoretical example that never existed: Pagan Everythingians. As a node, it would be reasonably safe to say it might contain: (apologies to those whose names I use if I get anything wrong)

Now, how would one go and use a search field to find Pagans in general if each of us popped exactly that in there?

It's real simple. You tell users to semi-nodespace themselves, so that you would be Pagan: Animal Totemist.
You really can't trust users to do such things properly. If you don't believe me, go to eBay and do a search for Plam. Look at all the Plam Pilots! Most users will fill out the field once and never check if they even spelled it right.

Okay, then we restrict everything in advance.
Not only would this require more code, but who comes up with the categories? One of the neatest things I've learned about Library Science is that it admits the futility of outright categorization. Above, sexuality is suggested as being restricted to 'straight' / 'gay' / 'lesbian' / 'bi' /'undecided'. Aside from the fact that this attempts to pigeonhole bisexuals (we're not all 50/50; there's your Kinsey 2s and 4s, your cyclics, those who have sapiosexuality), as well as the other groups (is being a 'vanilla' gay male the same as being a bear?), this also doesn't fulfill the "out" everythingians node — it tells us who is comfortable with the self-awareness they have.

If you're so smart, how would you do it?
As a basis:

  • take usergroups — a list of users with something in common.
  • Add a field, 255 characters of text for each user, linkable as per the homenode fields at the top of homenodes, to specify what about them makes them part of this group. This way in addition to listing characteristics it can list things like 'gay age' and such.
  • Allow users to add and remove themselves from the group via the group page, in addition to the group creator being able to add/remove/edit users.
  • Drop the /msg alias; if the group creator can add, it could turn into SPAM/flamewar/whatnot very, very quickly.
  • Retain the space at the top to put some text, but restrict it to links and such, since I think it currently supports superdoc functionality.
  • Creation of these 'user tag groups' would be a Level 5 power (because in mind it complements room creation rather well), allowing users to self-categorize.
  • Obviously, no experience would be granted for their creation.
  • Don't bother working at making it homenode-accessible; the whole idea, IMNSHO, is to go and provide indexes to users, not vice-versa.
  • Oh, and sort the list of users by username for fast lookup. No one wants to look at users sorted by date of addition to the list or order that they joined E2.

Is my idea perfect? No. It doesn't work for birthdays (though it does work very well for addresses). It doesn't autoprovide links from homenodes, though I feel the structured part of homenodes is already overdone as-is -- imagine the homenode load time if it had to sift through all 'userlists' or 'usertags' (as I call them to myself) to find out what users had what to say about themselves.

Blockquoth sleeping wolf:
What was the purpose of the foo everythingians nodes, as sleeping wolf perceives it?
To provide an index for users based on qualities they had, and to allow looking for commonalities.
Now you'll have to forgive me for joinging into this by tacking on a writeup. E2 is a big place, and will only get bigger. As it takes new and interesting curves, is a system like this going to be able to adapt? For example, sleeping wolf mentions the idea of who would come up with the categories. While it is easy to define some of the categories now, as this grows it may not be so easy.

But, I am all for making it easier to communicate with groups. For example, living in Tampa, I would love to be able to easily find everyone in Florida when I want to have a meet. When I first started, going to the user registry for Florida was interesting. There were all types of entries in all manner of forms. However, because we are evolutionary, someone went in and cleaned it up and standardized the way of its formatting.

I realize that having someone oversee the groups is labor-intensive, and sucks if that person goes away. But those issues will work out in time, without us having to code anything at all.

But say I wanted to find all of the musicians in the southeast. Much more challenging task. I first have to gather up every name from the UR, then go through each of the names and figure out if they might be a musician, then /msg them individually.

So here is my proposal. Perhaps it can coexist peacefully with the other ideas above, but here goes. Allow easier creation of groups, ala Yahoo groups (to a degree) for /msgs only. This way we can all be individuals, while making it easier to find those with common interests. As a second point, it allows for evolutionary expansion of the concept without user interaction (i.e. someone deciding the categories). I would love to be able to /msg Florida_Musicians.

But the biggest point for me is it does not get me to try to conform to any one category. I already get spam from someone who has lifted my email address on e2 (e2 at Setting up categories would mean that people could send targeted advertisements and the such.

Finally, have nodes where the users of a group are shown. But also allow a user to opt-out from being shown in that node when they enter the group.

Anyway, that's my two cents, and no matter which direction we move in, if I can offer any help please let me know.

Log in or register to write something here or to contact authors.