ideas for names redesign

[Teffania]

Attached doccument from teffania regarding ideas about name redesign and cases of name types that actually occur. Not quite finished, but good enough to give ideas. not quite knowing what she was doing either, so please forgive silly ideas, and just appreciate any good ones.

this probably should be in the blueprints area, but the silly thing insists on everything being stored offsite.

Conversation with bat, edited highlights:
*majority of names are located in a large table and tagged with attribute
*Bat: primary SCA and primary mundane go in the canon_person table, for speed of look-up. The canon_former table will hold everything else.
*Bat: suppose I decided to change my SCA name to Karl Faustus, but hadn't gotten around to it yet. I'd have sca name = Karl Faustus, mundane = Paul Sleigh, registered = Karl Faustus von Aachen, nickname = Eric the Fruitbat, former name = Eric of Tobar Mhuire, former name = Eric of Tobermory.
*Where Gratian just has a list of former names now, it would become a list with attribute labels.
*You could have any number of some of them (eg a woman who has been married twice and changed her name both times would have two former mundane names).
*possible attributes:
Here's a list:
  former mundane name
  current alias or nickname
  registered name
  former registered name
  device
  badge
  blog
  Facebook
  email
  website
 former name (no longer used), alternate name (eg alternate persona, persona nicknames), former mundane name, registered name, former registered name (officially changed), misspellings (found on official documentation)...
*mispellt name
Bat: Why do we need to track misspellings? Better to just kill them on sight, surely?
Teffania: because when I audit old records, I want to know it was the same person. and be able to search for them. (old mispellt records) (but not shown in canonlore)
*Teffania: re pictures and stuff - too much data entry. I'm barely keeping up with the amount of data entry i need to do from fix me's. Which comes back to not enough gratian enabled helpers which comes back to1) ease of installation, where the problems now seem to be with wampserver and 2) not enough pedant's who aren't already busy.
Bat: Yes, it's the sort of feature I can put in now and leave dormant. When (if) you ever get enough helpers, then they can go wild with it. There are always features like that, disabled for lack of time.
Teffania: built capability for them in if you like, but with firm instructions not to unleash it in canonlore so no-one knows about it until a canon is willing to take it on as a project. contact adresses are generally ephemeral. pics would be nice, but initially create a big workload on implementation, and then create a slow trickle of later increased workload. I worry about finding later canons who can cope with the work. And finding pedants who can delegate - not easy.
Bat: This is one of those features that are easier to do all in one go then disable, rather than just building part of it.
*We're basically just talking a big list of key-value pairs. Easy to implement, easy to use.
  Every one would be handled slightly differently in CL, but in Gratian they'd all be dead easy to edit.
* http://localhost/canon/person.php?id=3021 is an example of way too many former names cluttering up the list (I removed 3 valid former names which were variants on the listed ones). But i need to be able to search for them, don't mind people searching for them in canonlore either, but displaying them - not really necessaary.

Teffania other ideas not clarified in conversation:
*Having primary sca and mundane name seperate for quicker searchign sounds good, but there would be a certain flexibility if the primary name could be selected from the list of attribues, so that when we find out one of the names was incorrect, and one of the presumed mispelligs is actually the correct one, she can jsut change the attribute. So she suggests the primary mundane and sca names at least visually to the user remain in the attribute list, so the user can just select a different attribute to change them to a different name type. It's probably a good idea to have a read only display of primary names in bold seperate from the attribute list.
*Teffania suggested mulitple attributes because there are some convoluted combinations of attributes, and do you really want to create an attribute tag for each? eg alternate registered name (mispelt registered name is even an option- that's why they publish errarta- but I think we can delete those)
*If you really want to later program in an O&A checking function on names marked as registered names, that wouldn't be a bad thing. But it would be a low down on the wishlist thing. (stage 2 of the project) Perhaps it would be good as a soft verification tool - ie it either gives an ignorable error message when you enter a name as registered that can't be found in the O&A (rememebr it has occasioal errors, so not a hard rule), or there is a verification report that lists people whose registered name doesn't match the O&A that can be run occasionally. note so many names have special characters in them - O&A checker would either have to discard them or find a version of wildcard replace that works or something like that.

see also related: https://bugs.launchpad.net/gratian/+bug/501225
(note teffania has started data colection of registered names, former names, alternate names, devices, alternate devices, badges. She does wish for each to be verified by addition of the date and kingdom text.)

[Paul Harrison (paul-francis-harrison)]

I would recommend not worrying about performance unless it becomes an issue.

I like the idea of multiple attributes.

As I understand this, we are talking about two tables, people and names. Each name entry has a field, person_id, allowing a person to have multiple names. If each person entry had a primary_name_id field the primary name would be guaranteed unique, and the SQL would be fairly painless.

Not so keen on using this system for device, badge, blog, email, facebook. This is straying too far toward the Inner-Platform antipattern. For things that will not be displayed on the website, a freeform text field should suffice. Even for things that will be displayed on a the website, a freeform blurb is worth considering. Failing this, fields in the person table.

[Eric TF Bat (bat-flurf)]

Let's imagine we had either (a) a whole bunch of eager Gratian users doing bulk updates, or (b) some kind of public web-based UI just to update this info. Let's also imagine we wanted Canon Lore to look a bit more like the new Facebook profile page, ie with links to identifying information for people, social media cross references, pictures, etc etc. What sort of stuff could be stored in a CL award recipient's "page"?

Currently we have:
* SCA name
* SCA branch
* Former/Alias names (all in one undifferentiated list)
* Reigns (for royalty)
* Awards received (well duh!)

We could add:
* Publicly viewable mundane name, if they approve of having it out there.
* Other names -- nicknames, former names, aliases, emergency backup personas for the next time the royals ban Welsh people, etc, each with a type indicator.
* A picture, Facebook style, as a link to an external storage facility, with height/width, date and caption.
* Registered name (eg Silfren the Singer is registered as Selfran the Singer, so the former is her commonly-used name but not her registered name) with date and kingdom of registration.
* Registered device, with date and kingdom and a link to the Lochac Roll of Arms page (if no better representation exists).
* Registered badges, ditto.
* Assorted social media links: Facebook, web page, blogs, Twitter, chat (MSN, Google Talk, etc), Skype, Flickr, etc, each with a date to say when it was included in our list.

Now obviously this is a lot of extra work. Is it worth it? I don't think so. But see this as a set of what's possible and a superset of what's desirable. Now how to prune it back...?

I take back what I said about it being easy to implement. The two biggest problems are:

1. Each type of data requires slightly different information. Pictures need a hyperlink, a date, a height and a width. Aliases need a type (alias, former mundane, common misspelling, etc), a name, a date and a public/private flag. Social media references need a type, a link and a date. Registrations need the text of the registration, the registration date, the kingdom, and the entry date. And so on. To do this right, we would need careful design. Is it worth the complexity? It would be a "Small Matter Of Programming", ie a reasonably involved job. Granted it's new work, therefore more fun than bug fixing and maintenance...

2. We would have to give people the ability to update their own entries, ie have a user/password system, with all the support calls and abuse prevention that entails. There would need to be a bulletproof UI, web-based. We'd need an abuse reporting system ("Is this photo acceptable? Click to report it.") with the attendant commitment to respond to abuse claims quickly. We would need to redesign the layout of the Person page on CL, not only so it could include this new info but also so it would still look OK without it. We would need to redesign the Person page in Gratian...

OK, not easy. Fun, highly impressive if we were the first kingdom to get it working, tremendously beneficial for my CV if I ever want to go work for Facebook... but not easy.

[Teffania (teffania)]

For interest and comparison:
Page example from Anealan Op
http://aneala.sca.org.au/OP/person.asp?id=2
the concept of free text space for persona description is interesting

From memory one of the other kingdoms has photos and contact details, but it also lacks the database structure of Canon lore you can only rigidly look up a person in a particular way (searhc I think, no browse, no similar hits either), no browsing no getting distracted by who else got awards at that event, who was reigning, who regned before the etc....

Personally, I think photos and stuff are generally going to be more work than blessing. Ok photos might be cool, but post implementing stuff like this - always a lot of data entry work. We don't want the short termism of facebook photos, but instead a phptp intended to last 10 years. And then there is the isues of permission - we need the photographers's explicit permission to use the photo, and then it would be a very good idea to have the person in the photos permision to use that photo - a nightmare to chase up. And then there will be people who don't want to be identifiable by workmates for whom other scadians constantly pester sending in photos for. Even with the theoretical team of data entry ppl and everyone uploading their photo in the correct format, how do we prove the person is the one with the rights to approve copyright on a photo or is the person in the photo? Can of worms.

One possble useful (and previously requested) attribute we did miss earlier was preferred title, and possibly persona gender for any possible default title calculation.
https://bugs.launchpad.net/gratian/+bug/501223

Re the problems: If we remove the photo and social media link component, how much simpler does that make the project? Suddenly we have attributes that are within the realm of reason to maintained by canon because they don't change too often. And a number of them have clear official update sources rather than relying on individuals reporting things.

Teffania
p.s. I never got the impression you wanted to work for facebook....
p.p.s Back to the reminder - whatever is produced has to be maintainable code. Are you painting yourself into a corner again where no one else but you can fix this program? Is it a good idea to invest more time into a great program, but one that can't have minor issues tweaked (eg if royals create a new award style) due to lack of other programmers in the language if you fall under a bus?