WeRelate talk:Data entry design

This Fall 2009 (rescheduled to early 2010 due to another project taking time this Fall) Dallan will be re-working the "Edit" pages for Person and Family pages. You are invited to give your comments on the design. The ultimate goal of this discussion is to generate concrete ideas and consensus for how the re-worked Edit pages should function.

Initial Discussion

Dallan, noting that WR isn't expected to come out of beta for another six months or so, I have a couple of suggestions on layout for when you're editing a page. Low priority, but worth keeping in mind, I think. Mainly, when you're editing a page, and you come to the Source Citations section, some of those little boxes on the form are so small, it's awfully hard to see what you're doing -- or to read what's already been typed in them. First line is the namespace dropdown, the Title box, and the Record name box. There seems to be a lot of wasted white space on that line. If you push the end of the Record name box to the right to be flush with the las box on the next line, and back up the label "Title" to the left a bit, I calculate you can more than double the viewable portion of the title box. That would make it a lot easier to edit that element -- especially with form headings like the census, where the first part of every Source page title is identical. It would be useful to see more info there, too, if we go to an author/title kind of page title. On the second line, you could likewise slide the Date and subsequent fields to the right, thereby doubling the amount of viewable space for the Volume/Pages box. Again, this box often includes a good deal more citation detail than that -- at least, the way I'm using it, it does. E.g., for census listings, I'm including the ED no., page no., and house/family no. in there. As I say, this is all just food for design thought. I've designed quite a few Access forms over the years (at the library) and I don't think any of them was tweaked fewer than five or six times before I made them available to other staff members! --Mike (mksmith) 14:37, 28 April 2009 (EDT)

Thanks for the suggestions! For the next go-round on editing, I'm thinking about using a tab-based approach, with separate tabs for names, events, sources, biography, etc. I'm hoping that approach gives us more room. I'd love to get your feedback when I start working on it later in the year.--Dallan 22:18, 28 April 2009 (EDT)

Not to be a negative ninny before you start, but do you mean a layout where you can't see dates and their sources and the narrative at the same time? My software uses tabs, and I've spent a fair amount of time playing with the layouts to get as much information on one view as possible. The moving between the tabs drives me nuts. Flexible, yes, easy or pretty, no.--Amelia 23:55, 28 April 2009 (EDT)

Hmmm. Yeah, there are problems with tabs. I too would want to be able to see the text box (which is where I put census transcriptions, for instance) and the source citations together. Probably it would work to have the upper part of the screen be tabbed, with the lower part of the screen always displaying the text box. Something like that. --Mike (mksmith) 17:00, 29 April 2009 (EDT)

I'm not planning to do this for awhile, but let's talk about it now. I'm thinking about the following:

• Make each event two lines long so we have room to show places as user-entered text and matching Place title.
• Allow for three types of source citations, which will mean that some source citations will require more room:
  • Traditional: what we have now, except that as an alternative to referencing a wiki Source page you can include bibliographic information directly in the source citation. I'd like to phase out MySources, especially ones that are created during GEDCOM uploads. Ultimately I want to support and encourage matching sources during GEDCOM upload, and if you don't match your GEDCOM sources to Source pages, then we'll include whatever bibliographic information you have directly in the citation instead of creating a MySource page. Phasing out the MySource namespace will remove something that I think causes confusion more than it helps.
  • Transcript: This will be a new namespace, and it will essentially replace the MySource namespace, except that pages won't be created in this namespace automatically during GEDCOM uploads. If you have a lot of information to add about a source, you can create a page in the Transcript namespace (the page title will start with your user name just like in the MySource namespace) and reference it from the source citation.
  • Image: Long-term I want to make it easy for people to upload reduced-resolution screenshots of the records they find as Images. I'll need to add the ability to link Image pages to Source pages and/or add bibliographic information to them. I think that the ease of pressing a button in your browser, highlighting a portion of the screen, and then having a window pop up where you can enter details and specify which page in your tree to attach the image as a citation will encourage more people to create source citations.
• Images attached to events or sources would become "Image citations". Other images would be considered part of a "Photo gallery".
• Put notes directly under each name and event on the edit page rather than in their own section. The note field would be hidden unless it contained something, and there would be an "Add note" link to add a new note, which would open up a text box directly under the name or event.

This results in the following sections:

• Name/gender
• Family relationships
• Events & facts
• Research (citations)
• Photo gallery
• Biography

I was thinking of putting each section into a separate tab, but I could put the Bibliography section (the big text box) in the bottom half of the screen under the tabbed section instead. Also, it might be better to put source citations directly under the names and events that they reference, with a "Add citation" link under each name/event to add a new citation, rather than putting all of the citations together in one section.--Dallan 11:42, 1 May 2009 (EDT)

Could you provide us with a mockup display of how this might appear? Since most of my work on Werelate is focused on the narrative section of the page, I'm interested in seeing how the changes you are considering might affect layout of that section. Q 08:13, 12 June 2009 (EDT)

Some thoughts on this.

1. I don't like the idea of tabs. The problem is that it is so hard to see all your data. Most browsers already have tabs, so if tabs are desired it would be better to leverage their capability, such as adding a link to the same page, so one can use the right click menu to get a copy of the same page up in a different tab or different window (Different window allows overlapping windows so you can try to see the fields you want all at one time.)

---The reality of this, unfortuntely, is compromise. It's impossible to see everything on the screen at one time, even if you use 1-point type. I often have three or four applications open at one time when I'm working on almost anything (not just online), plus several tabs in Firefox, and I'm used to having to switch back and forth, copying from one window or tab and pasting into another, or just reading my notes in one and comparing with what I see in another. That's just the way it is. You simply can't see everything at once.

The problem with tabs however, is that the current tab is visible, and all the other tabs are not, even if the current tab is mostly empty. Yes, you can never fit everything on the screen. I would prefer an abbreviated summary at the top of the page with links to the different sections below that contain the fuller descriptions. And I don't see having Dallan spend a bunch of time implementing tabs being all that useful, when I can effectively do the same thing by browsing the same page multiple times, each scrolled to a different section, with the added benefit that if I use different windows instead of different tabs, I may be able to overlap my windows so I can see everything I need at once. Tabs are more useful for a process, where you do one step at a time, like the GEDCOM upload. I don't think editing a person page is a step by step process. You need to consider the life as a whole.

• Perhaps the same idea could be handled by links at the top that scroll to different sections of a potentially really long web page. I always liked that web pages are basically endless in length. Anyway, such a link would play into the above point as well.

• If anything, I would like to split my window and display multiple pages at once, not to split a page and need multiple windows to see the whole thing.

1. For editing, making items longer is fine, but for display it means less data is visible on the screen at one time. Wonder if display could use shortened fields for each fact, and add a ">>" symbol that creates a popup that gives the fully expanded version.

---If you mean my suggestion for longer text-entry boxes under Sources, how does a shorter box make more info visible? If you introduce additional visible data, it isn't going to be presented in additional vertical columns but in additional horizontal lines. Which means other lines are going to scroll down the screen out of sight.

I was referring to Dallan's proposal to make events take 2 lines.

Obviously for editing data you need access to everything. But for display, a summary or abbreviated form might be adequate most of the time. So it could take less room. Then if you are curious about a value, mouse over the ">>" and get a popup giving the expanded entry. Or in the above case, scroll down to the section with the fully expanded entries. The goal would be to get an overview of a whole person, mostly on one screen.

• The Place: aliases are somewhat annoying. In merging, I find that people use an alias of "Yarmouth, MA", and it hides the fact that the formal name is actually Yarmouth in England or similar things that are not only errors, but hiding that they are errors. It creates some names that display long and some that display short. It also encourages people to use their pet names which then don't communicate well to the reader who has different pet names. Once linked to a place, the formal name should be used consistently, in my opinion. If wanted, add an "official" alias to enable shorter displays, but having every user create their own preferred name doesn't necessarily make it easier to collaboration.

---Personally, I dislike the appearance of "Evansville, Vanderburgh, Indiana, United States." I'd rather see a "normal" listing, like "Evansville, Indiana," or even that with the county name added. But since that's only what's displayed, anyone can phrase the visible, right-of-the-pipe section however they like and it won't disturb searching or anything else. And all you have to do to see which "Yarmouth" is being referenced is to hover the mouse cursor over the phrase and glance down at the bottom of the browser. I can live with that.

I dislike it too, but I dislike multiple styles even more. When I look at a family page, different children are often done differently. It makes things like scanning for missing data harder, etc., because some entries are long, some are short. Since everybody basically gets pushed to the formal name by the pulldown, everybody is aware of that style, so I say use that form consistently. I don't think it helps to have everybody doing whatever they want in a collaborative system. (And regarding the Yarmouth example, of course I can see how the link is set up, but if the link is blue and I see "Yarmouth, MA" which I agree with, why would I bother looking at the formal name which happens to be "Yarmouth, England" which is wrong? It is not that one can't tell, but that the error is hidden, so one would never look.)

• "Alt" events need to be true alternates. During merging, I have deleted all of the preferred events and the alternate doesn't get promoted. They are displayed too remotely from the preferred event and easy to miss. Can we have multiple instances of an event, differentiated with an sequence number, lowest being preferred, rather than two different event types?

---I agree with you here. Except that I have occasional people who imported with, for instance, two or three alternate names or birthdates. Which alternate should be the candidate for promotion? I can live with having to expressly identify the primary name or event.

I imagine (without looking at the rules) that the preferred BIRTH is known in a GEDCOM somehow, so that would become sequence number 1, and the others numbered from there. Then if one is deleted by another user giving proof that it is not valid, then the next lowest alternate becomes the preferred BIRTH instead of staying as ALT BIRTH like it does now.

• I would like to see a fuller description of marriages on the person page.

---Absolutely. I've never quite understood the point of Family pages anyway, and I dislike having to switch to that page for marriage dates and names of children. TMG has a thing called "witnessing," where any event can be made visible on the page/screen of anyone else who had anything to do with it -- children, legal witnesses to a deed, persons mentioned in an obit, whatever. You can accomplish some of that here by inserting explicit wiki links, but the more obvious bits, like children being visible on each of the parents' pages, should be automated.

Having done data design, I understand it. If there is data about it (marriage date and children attached in this case) you need to create an object where you can store that data. But like you, I would prefer to see it incorporated into the Person pages at display time, so you can see the interrelationship between the different marriages and which child is placed in which marriage etc. Not to mention making it easier to go from parent to child without the extra page in between.

1. I am afraid I think using user's bibliographic citations will create multiple citations that are unrecognizable as pointing to the same source, unless I don't understand what is being proposed here. I think the current system of forcing them to either match an existing source page, or create one, (except for searching :-)) is pretty good, but my guess is some people would like to see the display version of a page follow a more standard bibliographical format.

• Some source transcriptions often give information about many events. For example a birth record often identifies that the parents were married and constrains their marriage date. A will often names the children and their spouses, and gives useful indications on their living/deceased status. A deed has a grantor and a grantee. Is there any value in thinking about whether such source citations could be entered once and linked to multiple events on multiple pages?

• Regarding putting notes (and sources?) close to the event they reference: Often a single note or source may discuss multiple events, such as the age at death in a death record being the source of estimated birth. In a note, it is often difficult to discuss the events in isolation. Is this going to lead to a lot of redundant source citations and notes?--Jrich 16:16, 1 May 2009 (EDT)

---I've been struggling with these related issues, too, trying to think of some method halfway between a universal set of Sources and hiring a thesis advisor to police individual researchers' attempts at citations. I personally have a strong background in academe generally and in bibliography in particular, and I can write standard citations of almost any kind in my sleep. But that's not true of most people, and it's certainly not true of the FHL. (But I won't jump on that hobby-horse again.) Nevertheless, we do already have several fonts of standard source citations out there -- Library of Congress, the CSM, Elizabeth Mills -- so we really don't have to invent a method from scratch.

The advantages of matching source pages should be that the system can generate a citation on the display so all the users don't need to know how to. During editing, they just match the Source page and fill in the fields of the source citation. But then when it is displayed, the elements of the Source page, and the elements of the citation are used by the software to generate a more correct bibliography entry.

---And having a standard Source-description page to which one may link multiple times should not really be a problem. A web page really isn't the same as a page in a paper book. There's no "ibid" or "op cit" in a wiki. I don't think the fact that a short title repeats several times in a series of source citations to different people or events is that big a deal, frankly. --Mike (mksmith) 09:18, 2 May 2009 (EDT)

My typical source citation includes the link to the source page, a page number, and an abstract of what is said. It is using this citation multiple times that I was referring to, not just linking to the same source page. I think this ties into the transcript idea of Dallan's in some way that I haven't thought out yet. But, ideally, such abstracts in a source citation, or transcripts of wills and deeds would be linked to by every person therein named since they provide evidence of living or deceased, etc. It would be nice to display a timeline of a Person that includes all these references so you see all the person's activities laid out. This might make it easier to spot anomalies. --Jrich 09:52, 2 May 2009 (EDT)

A few reponses

• The tabs would be used only for editing, not for display. I'm thinking of using this tab library if we use tabs.
• We could drop "United States" when displaying places, although it would still need to be in the place titles.
• I was hoping through the use of tabs to eliminate the need for links to different sections of a long page, that the tabs would display each section so you wouldn't have to scroll as much. But we can do long pages if that suits people better.
• We could also use pop-up windows for entering/editing events, sources, etc.
• The goal of including bibliographic information directly in the Person/Family source citation is to eliminate the need (or at least the typical need) for MySource pages. We have them so that citation information can be shared among multiple pages, but most MySource pages contain very little information and they're linked to only one Person or Family. MySource pages can make sourcing easier for advanced users because you can put information like page number on a MySource that you can't put on a source, but I think they deter sourcing for new users because of the extra complexity. If we encourage people to cite Source pages and to link their gedcom sources to Source pages during gedcom import, then MySource pages will be used less frequently. Since MySources are currently a point of confusion, I'm hoping that we can come up with something different, especially for gedcom import.

I don't understand how points 1 and 3 work together. If you're only using tabs for editing, then how does that eliminate links for different sections of a long page?--Amelia 13:37, 2 May 2009 (EDT)

I was thinking that on the Edit screen, we could either list the data-entry fields for each section in a separate tab (like we do now for editing your preferences in the MyRelate menu) or we could list the data-entry fields one after another on an untabbed long page (like we do now for editing people and families).--Dallan 13:17, 4 May 2009 (EDT)

Suggested goal for this discussion [23 June 2009]

I've moved the design discussion started on User talk:Dallan to this page in the hope that people will continue to give their comments and that we will get more people involved. I don't have a particular talent for UI design, and I'm hoping that people expertise and experience with genealogical data-entry interfaces can come up with ideas that will lead to concrete implementations (ultimately screen-shots?) that everyone generally agrees with. I'm hoping that people will take on this challenge; I'd like to add comments only periodically. I don't plan to re-work the edit pages until Fall, so there is time for discussion beforehand.--Dallan 11:48, 2 May 2009 (EDT)

Here are the things I would like to accomplish with the new design:

• Make editing pages easier for new users
• Remove the confusion between Source and MySource for new users.
  • Can we stop creating MySource pages during GEDCOM imports, or altogether, by adding information from the GEDCOM source directly to the source citation?
  • When are MySources really useful? Should we rename the MySource namespace to better reflect their recommended use?
• Add a new Image-based citation, which encourages people to upload images that can include citation details and that they can tie to sources and to events on Person and Family pages.

As long as we're talking about design changes, here are the changes I would like to consider for displaying Person and Family pages

• Add a mini-FTE window displaying the person's spouse(s), children, parents, and grandparents, along with birth, marriage, and death information for these individuals. The mini-FTE window should contain buttons to make it easy to add spouses, children, and parents without editing the Person page. This FTE window could also be shown on the Family page.
• Add a mini map and timeline showing events in the person's life. The map and timeline could also be shown on Family pages.
• Possibly display the mini FTE, map, and timeline windows down the left-hand side, and list name and event information in an info-box across the top. (I'm open to ideas for how this should look.)
• Citations linked to Sources should eventually pull bibliographic information from the Source page to generate bibliographic-style references on the Person and Family pages.

I much agree with what Jrich said above, but a few specific comments on Dallan's questions:

• Complexity is the enemy of new user ease of use. But I don't think we want to sacrifice too many of the existing functions or goals. I'm thinking specifically of source citations, where "easy" would ignore the wiki and things like MySource that let you recite and convey additional information.
• I was okay in theory with stopping MySources in gedcom uploads...until I thought about the upload I just did. I have a dozen citations to a single family bible. The MySource lets me keep that citation, fix its name globally, add information about that bible globally, etc. Repeat that experience for a dozen other sources in that gedcom that don't have sufficient titles for me to figure out if they are in our (now completely broken, but I assume that's temporary) source database. When I figure out what I meant by "Greene County Will Books", I want to be able to fix it. So some form of reusable source citation makes things much easier for users with even a little bit of web/wiki knowledge.
• Does "image based citation" need to be a separate type? Can't we just add images to source pages? (like this). I assume you mean images that include the information in the source, by the way, and not the "citation details" like author and page.
• Whatever editing format we use, I would strongly encourage you to keep all the source fields visible at all times. The point of having the sources that way is to reuse them, so it would be nice not to make using them difficult.
• I'm not excited about the map idea. It only works when you have 1) a person with good places; 2) places that the mapping system recognizes; and 3) places that aren't so far apart as to make the map meaningless. Which isn't true of most pages as far as I can tell. It also seems like the kind of thing that's going to further increase load times and browser compatibility problems. If there is a good map, maybe do a template that allows a user to insert it instead of having it show up by default?
• I'm intrigued by the mini-FTE window (But you're going to show three generations, with three sets of dates and places each in a little window?? Good luck.) It would be especially nice if this functionality could let you see from a family page all the children's families.

And, as a separate thought, changes I would most like in the edit page (as perhaps the opposite of your new user audience):

1. Longer source title field. Longer source title field. Longer source title field. (Just to make the point. The rest of the list is far less of an issue.)
2. Longer place name fields.
3. A button that does ref tags and the references tag.
4. Automatically populating the image name I upload in the add field.
5. Remove the reminder that I'm going to lose my edits if I leave.

item 4 is fixed.--Dallan 17:42, 23 June 2009 (EDT)

--Amelia 13:37, 2 May 2009 (EDT)

Link to sample tabbed page on Familypedia [2 May 2009]

[1]--Beth 19:31, 2 May 2009 (EDT)

Just to be clear, the tabs in this example are for displaying the page, not for editing. We could also consider using tabs for displaying the information on page, but I'm sure it's that helpful.--Dallan 13:17, 4 May 2009 (EDT)

MySource [11 June 2009]

Dallans points concerning my space included:

• Remove the confusion between Source and MySource for new users.
• When are MySources really useful? Should we rename the MySource namespace to better reflect their recommended use?

Yes, MySource items could be a really useful category. Right now it is a cats and dogs kind of thing. Hard to use effectively because its hard to see what belongs there.

I would recommend

Defining Sources as "bibliographic" references to specific documents.

Returning to the original definition of MySource as a grab-bag for things like GedCom's, personal notes, and the like.

Creating a namespace "Documents", to house images or transcriptions of family bibles, court records, patents and the like

There's a huge difference between a bible transcript and someone's GedCom. The two things simply don't belong in the same area. That's probably the reason for the confusion.

Q 16:13, 11 June 2009 (EDT)

Simplifying for New Users [12 June 2009]

Dallan's point was

• Make editing pages easier for new users

There are several elements to this. People come to genealogy with all levels of technical sophistication, in both computer use, and in genealogical experience. A genealogy wiki places great demand on the user's abilities. Here's an example of a comment from one user:

This is the most confusing and unfriendly family tree website I've ever encountered!! I think I'm going to give up!!

While the GedCom import makes getting your family tree into WeRelate fairly easy (much easier than on some of the other Genealogy Wiki's) contnueing to work on WeRelate places great demands on a user's technical abilities. As it stands, the entrance bar to active use is too high for most folks to hurdle. Making manual input easier would help. Simpler design would leave fewer places where people can go wrong, demand less of them, and result in less frustration. On the otherhand, experienced users, the computer literate, and especially the genealogically literate, do need some of those capabilities. Would it be possible to set a switch in preferences so that new users would receive a simplified input screen? Then when they became more accustomed to using WeRelate they could flick the switch and get the full package of editing features?

I believe part of the problem with transitioning new users into active users is that the basic input page is looks very intimidating.

Just entering the name for a person has an intimidating feel. The following gives some possible alternatives to input page layout, designed to simplify input, and make the process a) less intimidating, b) more streamlined, c) more familiar, and d) minimize disruption to the existing system.

Name Input

Something simpler might be more effective for a new user.

Less stuff to deal with means less intimidating. Then when they are comfortable with driving the car, they can flip the switch to get full access.

Family Input In the next section of the input page you deal with parents and family

This puts a fair bit of demand on a Newcomer, as most genealogy programs put all of the data onto a single page, not creating individual pages for person, and a separate page for parents, and spouse. Given the expectations established by desktop genealogy programs, most folks will not come to this site with a built in understanding of what's going on. That creates another barrier that makes the site difficult to use for some. The solution here is to make it LOOK like what they expect. Let them input what they expect to be asked about, and then rearrange the information creating the husband-wife page behind the scenes.

This would give people something like what they expect to see, reducing barriers to working with the system.

Events Input

This layout is similar to the basic name input layout. There's a lot here that the new user has to come to grips with to figure out what they need to do. The fact that they can ignore (if they wish) most of these input boxes is not obvious, and looks intimidating. Hence looks hard to use. The solution is to simplify the layout for new users, and allow experienced users that want the full capabilities to turn those on when needed.

Note that the "Citation" field has been retained in the Simplified input approach. The "citation" is fairly intuitive even for folks who DON't keep track. By including it in the simple layout you don't adversely affect user friendliness, but still emphasize to all the importance of sourcing. The fields that have been temporarily excluded are the ones that create the questions for people, and make the input process less user friendly. Note that I've slid citations to the left adjacent to the basic input boxes. This is important to do, as the citation field is probably more important than the Notes and images fields. Those later are useful, to be sure, but most users won't ever touch them anyway. So elminating them from the simplified input field does no harm. Q 09:14, 12 June 2009 (EDT)

Unfortunately less fields means less functionality. For example, the title prefix and title suffix are very helpful when differentiating people of the same name. While it may be possible to work without them, people that have been using WeRelate would probably complain. And some of these field probably need to be there to have a place for even basic GEDCOM input.

Perhaps compound fields like name, birth and date could be displayed, with a "Edit" button, nearby that popups a small popup or wizard just for the components of that particular field. Then there might be an opportunity to provide more guidance on how to do input. I am sure that would be slower and I am sure experienced users would request an expert mode that was more like the current screen, requiring less round trips back to the server which could get slow when more users are working.

Many people have complained about the need for both Person and Family pages. For example if you are looking at children, you no longer can see things like alternate names and other wives, and it is difficult to move children from one wife to another, and two screens to go from child's screen to father's screen, etc., etc. But while there may be better ways to have this work (I don't have one), I don't think it is conceptually confusing.

My impression is that the confusion has more to do with what form the data goes in, and all the ways it gets used, not with the method of the input. In other words, how do I do represent this situation, as opposed to what is this field for? Do I need to specify Plymouth Colony differently than Plymouth, MA, as opposed to where does the place of birth go? In a personal genealogy program, you can do whatever you want if the program will let you, but here you have to worry about all the other people using WeRelate as well.

--Jrich 09:06, 12 June 2009 (EDT)

There's no loss in fucntionality. The full set of fields would remain available by turning a switch. Either in the user's preference page, or (as shown in the last "Events" field, as a switch on the page itself. If the problem is accessibility, you do not want to make the system more complicated. Things need to be kept simple, and multiplying the input fields simply becomes more intimidating. Q

I very much agree with father, mother, spouse fields being more usable... but that assumes that every couple is unique, and we can't assume that. There'd still have to be a mechanism to choose which John Smith and Mary Unknown family we're talking about. I also think that if I came here new and saw a name entry format that didn't have prefix/suffix, I would either 1) leave because this is bush league that indicates the people running the site are not actually familiar with genealogy; or 2) totally gum up the works by putting titles in the name field (where else would they go?) and make a bunch of "Lt. Smith (1)" and "John Smith Jr. (2)".

I also agree with Jrich that the most confusing things about the data entry are the page relationship issues, how places are entered, and how sources are entered. Larger place and source fields would go miles toward the latter I think.--Amelia 20:06, 12 June 2009 (EDT)

If what I'm suggsting were to be implemented, there would be a need to find the "right" couple in the existing database. That could be done by finding matching cards for the husband and for the wife; which of the sometimes many cards for the same person name would need to be selected would depend on matching up vita---this would be handled by machine search behind the scenes. The main problem would come where vita data for individuals was not available. In that case, if a matching pair could not be found, the submitter would need to be presented with a suite of choices to chose from.

Personally, I don't place much value on attaching titles---prefixes or suffix's, to names. Captains become generals, Juniors become Seniors, and all are dependant on when in a person's life you are applying them. Such designations are sometimes useful as "bynames", but I suspect they cause more confusion than not. Nonetheless, what I've proposed is not to eliminate such, but to simplify the data initial data entry page so it is easier to use, and less intimidating. For those wishing to add prefixes and suffixes the capability is still there. This could be highlighted in the help file/introduction to new users. IN fact, it would have to be discussed since a key issue is whether you turn the extra fields on-or off. If this is done with a user preference, it might not be very obvious. However, if its done with a switch on the input page itself, it would be pretty clear what needed to be done. ANyone unpleased with the selection of fields would probably trigger that switch to see what it would reveal.

I suppose one could add separate fields for things like Nation, State, County in whatever order was appropriate, and the system would arrange the individual name elements in the most appropriate way. However, that does go against simplifying the appearance. And would probably give an unappealing appearance in the "expert" setting. (Just too many fields, not to mention making the fields longer.) If the object is to attract and retain more users, this would probably work against that purpose. Genealogy is a complex subject. There is a constant urge to add more bell's and whistles until you reach the point where the program is only useful to experts. If the expert is the audience, then add more bells and whistles to please them. The cost of that comes in the form of excluding less than expert users. If the user community that is sought includes only expert users there may not be any need for change since they are being largely excluded now. Q 21:02, 12 June 2009 (EDT)

Do away with family pages? [18 November 2009]

I don't know if this is feasible, but it is probably one of the least liked features of WeRelate for me. Perhaps it can only be eliminated at the display level, without changing any underlying data? I was wondering if a marriage (Family Page) could be like an include file that gets displayed as a section embedded within the person page, instead of just a link? That way a single Person page would be more of a linear, coherent presentation of a person's life. I don't know if editing would still require some kind of popup-edit of the family page within the process of editing the person page?

Many reasons have already been discussed, but I was just neatening up some pages and adding a vital record for the death of a wife. Of course, this record is using the surname of her husband, so on the page of a Jane Doe, you stick a death record for a Jane Smith. All the while, the proof and details about the marriage of Jane Doe and John Smith is on another page, so the reader just has to take it on faith that match has been made correctly, or go read another page and come back. So many GEDCOMs just bother to enter the marriage they are descended from, that if fuller examination shows the person died under a different name after remarrying, will they recognize it as the same person?

Similar issues arise when discussing other issues involving multiple marriages, i.e., which child belongs to which spouse, when the first spouse died versus when the second marriage took place, etc. The proof ends up being scattered over multiple pages, or else redundantly copied everywhere, or you refer the reader to a different page to find the explanation.

Ideally, I would actually prefer to see marriage and the births of children as individual events on a par with birth and death, so everything about a person can be laid out in chronological order, but I suspect that would involve a massive change in how data is stored, and so not even close to being feasible.

--Jrich 12:18, 13 June 2009 (EDT) ____ The "family page" is definitely an idiosyncratic feature, at least combined with individual husband and spouse pages. (Several genealogy programs use something similar, but don't have separate husband and wife cards.) I'm sure Dallan had very specific reasons for going this route. I'm guessing that this is related to the issues that surrounding multiple marriages, and associating children with a specific couple. This is a difficult problem to solve effectively. Dallan's approach has the advantage of allowing you to easily distinguish information about the individual from information about his/her marriage. Multiple marriages just get multiple cards, without having to do anything with person page. this way you don't have to store the child information from each marriage on the person card, and then fill it up with information to make it clear by which wife/husband the children were by. I personally solve the problem on my pages by basically ignoring the wife and combining the children from multiple marriages in a separate section of the "Personal data table" placed in the Narrative area. That's not a good solution either, but it works for me because my focus is on such a narrow time period, and its difficult to get enough information about the wives for my purposes to make a decent article.

That works for me, but wouldn't work for Dallan or WeRelate in general. There would be a definite problem captureing all of the family information on a individual's page, and even then you'd have to duplicate it for the other spouse. I'm pretty sure the complexities of display that this would entail ---especially given the limited space in the left hand side bar, is why Dallan used this approach. I've spent a fair bit of time in the past thinking about alternatives to this, and I don't have a better answer for this at the moment. Q 12:58, 13 June 2009 (EDT) Some genealogy packages use a similar feature, combining husband and wife on a single card.

(After I replied, I realized that this topic should be moved to a different discussion forum. This page is discussing data entry design, not page design.)

An alternative would be that a family page look more like a typical family registry page. I like how the Germans did it in their old evangelische church records:

Across the top: two primary boxes separated by a vertically narrow column. Husband in the left box, first wife placed in upper half of the right box. (One drawback of this is that the format is male-centric; if the wife remarries after his death, she "moves" to the register of her second husband.) For each of husband and wife you have:

Firstname Lastname b: dd Month year place d: dd Month year place occupation

Parents: [click the word parents to go to their registry page] Father: Firstname Lastname Mother: Firstname Lastname

In the column between the husband and wife you place their marriage date and place.

Below this upper section of three columns, you list the children

1. Firstname bdate, married who, when; death

Clicking on an individual's name would take them to their individual narrative page-- what currently looks like their person page.

I would find such a family registry page much more useful than the current family page.

My $.02

jillaine 15:23, 13 June 2009 (EDT)

Jillaine,

I didn't think Jrich's concern with the Family page as a design element was particularly out of place since the subject of the discussion was "re-working the "Edit" pages for Person and Family pages. You are invited to give your comments on the design."

Perhaps a discussion of killing the family page is a reasonable part of that. I just don't think that this is doable within the time between now and when the site will go public. I suspect this is a fixed element of WeRelate. Possibly something could be built that would allow the importation of family data in the form of a register from the family page onto a person page, That's about the most one could expect to happen. Q 16:48, 13 June 2009 (EDT)

But on the otherhand, I see you weren't really suggesting killing the Family page, but incorporating a register into the narrative section. That would seem to be doable. Easier to follow at anyrate. There's been some discussion in the past (mostly by me) that the left hand sidebar was really overwhealmed with information. So much so that its hard to find anything in the cramped space. Dallan has noted that as an issue as well. Perhaps part of the plan is to do something like what you suggest. Its not too dissimilar from what I've manually implemented in various forms on some of the pages of the Southwest Virginia Project.Q 18:24, 13 June 2009 (EDT)

What's needed is not necessarily doing away with the Family page but rather allowing you to input parents/children directly from the person page. AndrewRT 19:25, 17 November 2009 (EST)

I agree. I think that's the number one issue.--Dallan 12:45, 29 November 2009 (EST)

A proposal [20 June 2009]

I spent today reading through the comments on this page and thinking a bit about how to make the page entry simpler without losing functionality. Doing away with family pages isn't really an option. It would take a lot of work at this point, and there are some benefits to having family pages: you have a place for events tied to the couple: engagement, marriage, divorce, etc. The genealogy programs that I've seen have a family data-entry screen where you add a father, mother, and children. I think an issue with WeRelate is that you have to add family pages separately from adding individuals, and information related to the family (like marriage) doesn't show up on the spouses' pages. I'd like to fix these two issues.

Editing people [23 June 2009]

Here's a proposed version of an edit screen for a person. (I don't have a picture for a family, but it would be similar.)

The proposed changes are:

1. The information is presented in editable tables. I'm thinking of using something like jqGrid. To see what I mean, click on the jqGrid link, then click on Row Editing, then Using Events, then click on a row of the table. The table cells are editable. Not much of a change really, but I think it makes the UI look "prettier", which makes it appear less intimidating.
2. You'll notice that there are no tabs, although if people want they can collapse the jqGrid tables using the button in the upper right corner.
3. You can drag the border between table columns left and right to make the columns larger/smaller.
4. The last row of each table is empty, so if you want to add a new name or event, you just start filling in the last row of the table. When you do, a new empty last row is added to the table.
5. A button in the Cite column lets you add a citation for the name/event just like the current + link (more on citations below).
6. Alternatively, you can click on an existing citation in the citation table and drag it onto a name or event to link it to the name or event.
7. I've separated the place that you enter from the "standardized" place that is the title of the matching Place page.
8. I merged the citation, image, and note fields together into one field as suggested earlier. I think this is a good idea for simplifying the UI, and it allows us to give more room to the place fields.
9. Citations initially show just the title (or first line of the note) in a row of the citations table. If you click on the plus sign to the left of a citation it expands the citation so that you see all fields. Multiple citations can be expanded at the same time; you could expand all citations if you wanted.
10. There are three types of citations: Source, MySource, and Note. A Note citation is what we currently call a note. In the interests of making just one set of changes at a time, I won't try to introduce an image-based citation. You'll be able to attach an image to your Source or MySource citation like you can now. Also, let's keep the MySource namespace, continue to use it for GEDCOM upload, and tell people to use it whenever a community Source isn't appropriate. We may introduce a Document or Transcription namespace in the future, but let's not worry about it now. I think we need to get the Source pages fixed first.
11. The Source and MySource citations have two fields for entering paragraphs of text: Text and Notes. I noticed when doing GEDCOM export that a lot of desktop programs have both of these fields, so we will here as well.
12. With the Image field and the Notes tab in the citation you can attach up to one image and one note per citation. The current interface allows you to attach multiple notes and images to each citation, but restricting it to one each makes the interface simpler.
13. A photo gallery contains images that are not attached to particular citations. These images will be displayed toward the end of the page using a gallery tag.
14. I'll add a few buttons to the button bar for ref, references, etc. tags.
15. The parents and spouse family tables have one row per family. But the rows are not editable. Instead, you need to click on the Add new or Select existing buttons.

(Dallan's proposal stops)

Overall, I think this is a definite improvement. I like the jqGrid idea. I wonder if that would work as a user tool, so that they could create tables wherever needed, on the fly, rather than spend the time with HTML or Wikitable formating. Wikitables really look nice, but I find them much harder to create. Plus both HTML tables and Wiki tables are VERY hard to edit.

It's a good idea, but I'm not sure how it would be done. I think for general table editing we're better off waiting until FCKEditor, a rich-text wiki editor, is a little further along.

Eliminating the Note and image field in the initial display. I think this helps improve clarity. Clicking the plus button has the same effect (and probably a lot less cumbersome prgramming, than have a switch in the user preferences. Q 10:05, 19 June 2009 (EDT)

I like it a lot. I'm wondering how the places are going to work, though. Are we still going to have drop downs? Is the "official place" going to populate automatically? Can we just have the "official place" if we want?--Amelia 11:02, 19 June 2009 (EDT)

I was thinking that the Place field would still have the drop-down list. The "Standardized Place" field would not be directly editable. If you picked a place from the drop-down list then the "Standardized Place" field would be empty. Since the standardized place would be the same as the value you chose, I'm not sure it's necessary to show it. But if you entered something, say "Chicago, IL", into the Place field, then the "Standardized Place" field would be filled in a few seconds later with "Chicago, Cook, Illinois, United States". How does that sound?--Dallan 16:37, 20 June 2009 (EDT)

Ideally, great. But what if it picks wrong? I've seen that happen a fair amount with the auto-matching in the gedcom uploads.--Amelia 20:03, 21 June 2009 (EDT)

I'm not sure quite what to do about that. I don't want to make the standardized place an editable cell because I don't want people to feel like they have to fill it in, since most of the time it will get filled in correctly automatically within a couple of seconds. If the system guesses wrong they could select a place from the drop-down list, which ensures that the standardized place is what they intended. I'm open to other ideas as well.--Dallan 14:19, 22 June 2009 (EDT)

I wonder how often it will mistmatch? For example, I entered a person in Greenfield, PA not knowing there were multiple Greenfield, PA, requiring a county to differentiate them (and mine was called Little Hope in the place list using modern names anyway). I don't imagine it could have possibly have handled that right. Would Erie, PA match Erie, PA, or would its preference be the same as the drop down list, which lists Erie Junction, PA nearer the top than Erie, PA? Why not allow editing of the standardized field? If an illegal value is entered (i.e., red link), then it could be automatically erased by a periodic batch job (easy for me to say, I don't have to write it or provide computing power to run it) and in that case the computer's best guess probably would be more valid than an obvious wrong link. But without the flexibility to edit this, if the computer is wrong, the only way to fix it is to give up what ever non-standardized name was trying to be entered. As we have seen by recent discussions, some people want to enter the historically appropriate name. To do that, they need to be able to set the standardized name or how can they link to a Place page? --Jrich 15:04, 22 June 2009 (EDT)

I hadn't thought about the historical place name issue. Good point. I'll let people edit the standandized place and mention in the help that often they won't have to.--Dallan 10:53, 23 June 2009 (EDT)

Actually you probably wouldn't need a batch job as I mentioned above, and which you probably know well. Checking places would probably all be done when a Save is executed. Basically, if standardized field has data in it and it matches a Place, the check is done. Leave whatever is in the other field untouched. If standardized name doesn't match a Place, erase the standardized field and look at the (non-standardized, historical, colloquial, freeform) field. If the name is empty, the check is done. If the name is not empty, but matches a Place the check is done, leaving the standardized field empty. Otherwise, use the Place matching algorithm to have the computer find the most likely standardized name based on the data entered non-standardized field. --Jrich 11:13, 23 June 2009 (EDT)

I thought I would write something that would try to fill in the standardized place by matching the user-entered place as soon as the user "tabs out" of the place field as long as the stndardized place field was empty. So the standardized place would be populated within a couple of seconds if the user hadn't already started entering something. In case the page is saved before that, then it would be populated during the save.--Dallan 12:37, 23 June 2009 (EDT)

Adding parents and spouses [19 June 2009]

In the proposed approach, the spouse person page and spouse family page are added at the same time when adding a spouse.

Very good. that fixes an significant problem. Q 10:08, 19 June 2009 (EDT)

Also, the father (if known), mother (if known), and parent family page are added at the same time when adding parents. I'm hoping this will reduce the confusion with family pages.

• If you click on Select existing when adding parents or spouse, the following window pops up. This gives you a text box where you can enter a title, shows up to 10 pages whose titles start with the text you've entered. Prev and Next buttons let you browse through the list.

If you click on Add new spouse the following window pops up, where you enter information about the spouse:

After you click Find/Add you're presented with a pop-up list of possibly-matching people:

If you click on one of the people in the list, a Family page is created with that person as the spouse. If you click on Add, a Person page is created for the spouse and a Family page is also created with that person as the spouse.

Excellent. This would be a much more effective display of the data. Much easier to work with. Q 08:33, 19 June 2009 (EDT)

• Alternatively, if you click on Add new parents the following window pops up:

After you click Find/Add you're presented with a list of possibly-matching families. If you click on Add to add a new family, you're then presented with a list of possibly-matching people for the husband, where you select an existing husband or click Add to create a new Person page for the husband, and then a list of possibly-matching people for the wife, where you select an existing wife or click Add to create a new Person page for the wife. Finally the new Family page is created with both people as spouses.

Person and Family page layout [19 June 2009]

I know this is off-topic, but the proposed person and family page layout has an impact on adding parents and spouses.

I'm not sure whether the infobox should be horizontal or vertical. Maybe it should be horizontal for families and vertical for people? A horizontal infobox for families would allow us to put the husband on the left and the wife on the right as suggested. We could list the marriage event between them, although we'd have to list other family events below.

• All events would be listed in the infobox in date order
• Citations would be listed at the bottom of the page along with other references (we'd integrate citations and ref's) in a References section

This sounds more confusing than refs already are - that is to say, they are easy if you know what you are doing, but not many people do. What do you mean you're going to combine them?

Also, right now the logical place for what I'll call "group boxes" (i.e. U.S. Presidents) is below everything through use of <show_sources_images_notes/> tag. Is that going to break or look weird?--Amelia 11:41, 19 June 2009 (EDT)

I'm thinking that the citations would be listed just as if you had written <ref name="Citation ID"> followed by the citation information in bibliographic form in the text, and that the <show_sources_images_notes> tag would function just as if you had entered a <gallery> tag followed by a <references> tag at the bottom of the page, unless you had explicitly included those tags earlier in the text. So refs that you list in the text would be listed together with the citations at the point where you put the <references> tag, or if you didn't explicitly include a references tag they would all be listed at the bottom of the page.--Dallan 16:37, 20 June 2009 (EDT)

• Should we list family events in the person infobox?

Such as the DOM, etc? In my trial examples of a family register I've included marriage data, but the register seems to get overwhealmed if there are more than two spouses---at least if you try to include spouse vita in the same box. Perhaps just the identities and DOM for the spouses would work better. Q 09:06, 19 June 2009 (EDT)

I'm ok with just listing spouse and marriage date. Any objections?--Dallan 16:37, 20 June 2009 (EDT)

• Should we list the children in the family infobox?

Yes, but it may end up dominating the page. If someone is using the family page to record information, or to write a family narrative that could be a problem.

Another approach would be to create subpages to display basic infobox information about the person or family. Q 09:06, 19 June 2009 (EDT)

Where else would you put them? One line per child below the parents seems like the logical place. Leaving them in the left sidebar, which otherwise no longer has that information, would be weird.--Amelia 11:41, 19 June 2009 (EDT)

The children would appear in the "mini-family-tree" window in the upper left corner, but the boxes would be so small that you'd have to hover over them to see their information. So maybe also listing them below the parents, one line per child, is the best approach.--Dallan 16:37, 20 June 2009 (EDT)

There are four boxes down the left-hand side:

1. A mini family tree box, (described below)
2. A map box, initially collapsed so that it doesn't slow down page loads
3. A timeline box, initially collapsed so that it doesn't slow down page loads
4. A watchers box

I'm very glad to see your thinking on this. I agree something like this is needed. The left hand sidebar tended to get overwhealmed with information, to the point that it was hard to find.Q 09:06, 19 June 2009 (EDT)

The vertical approach would create a very significant problem in that it would reduce the amount of space available for the narrative. Perhaps something could be created that would allow the user community to select from different arrangements depending on the need? Q 08:39, 19 June 2009 (EDT)

An alternative would be to abandon placing signficant narrative on the "infobox pages", and transfer existing and future narrative to separate subpages, or separate article pages. That would create a lot of work for me, since most of my activity on the site is person article narrative. But perhaps separate articles for the narrative would be a good way to go. Q 09:06, 19 June 2009 (EDT)

Another point along this same line: One of the things I like best is that I can create "Notebook" articles for storing information. I've tried lots of different approches, including storing the data in the narrative section, on the Talk page, etc. But separate article pages seems to work best. (e.g., see: Notebook:Porter Family in Southwest Virginia for a data capture example). But I notice that many others use the narrative section for this same purpose. Sometimes storing considerable information on a person page. I do that to, but eventually, this overwhealms the page---so it goes to a notebook. I think this is a useful approach, and one that I think would benefit other users. Perhaps a long term addition would be something like this formalized. That is, make it standard to attach information to person articles via something like a Notebook page. Q 10:25, 19 June 2009 (EDT)

Other thoughts on this? I have the same concern as Q that a vertical infobox might not leave enough space for the narrative. However, I see them used very effectively on Wikipedia and Familypedia. I don't think creating sub-pages is the way to go because of the challenges subpages would bring to merging, but I like the idea of creating a separate article if you have so much to say that it doesn't comfortably fit on one page. Perhaps we could make the person infoboxes fairly narrow? A horizontal infobox for families would be a natural way to represent husband and wife information side-by-side, but it would mean that the family narrative would fall below the infobox.--Dallan 16:37, 20 June 2009 (EDT)

Mini family tree [19 June 2009]

The mini family tree box has add buttons (plus signs), for adding parents, spouses, and children. It also allows you to navigate to a parent, spouse, or child page by clicking on one of the items in the box. Hovering over a person or over a marriage event displays more information about the person or family.

mini family tree for a Person page

mini family tree for a Family page

I'm not sure this captures everything discussed. If I've missed something, would you please bring it up again?--Dallan 23:25, 18 June 2009 (EDT)

This would be a very nice addition.

Responses to proposal [19 June 2009]

Hopefully, I am responding to the proposal and not embedded comments.

The general approach looks excellent to me.

I think there are a few general features I like to suggest:

In the spouse list on the person page, can the marriage date as well as the name of the spouse/family be displayed?

Alternately, perhaps the +-to-expand feature could be added next to spouse names, if this is not desired by all, so that a person can choose to get a longer display and see more information about the marriages.

How about if we just list the marriage date and spouse's name on the Person page, make the marriage date a link that takes you to the Family page, and make the spouse's name a link that takes you to the spouse's Person page?

When you popup screens to add spouses, mothers, and fathers, it shows birth date and death date and place. Can you add a plus there so one can add a source citation at the same time. Otherwise, you are still adding a page and then going there to edit it and add your sources, and it implies sources aren't important versus making it appear to be an expected part of adding new information, which it should be. (I would almost argue that people should be warned if they add a fact without a source citation.)

I like this idea. At this point I'm wondering though if I should just bring up the Person edit page as a pop-up window where people could add this information (and any other information they wanted to add) directly onto the Person page and save it when they're finished.

On the source citations, I don't like having text and notes as tabs. I am assuming text is meant for a transcription/abstract of the source, and notes are meant as a discussion of that material. Tabs means you can't see them at the same time, and since the notes will often refer to the text as part of its discussion, you will probably want to inspect both at the same time and end up flipping back and forth. Faced with that, I would probably be tempted to add notes at the end of the text using square brackets rather than putting it in a note that can't be seen at the same time.

Another possibility is I could make the text and notes areas each half-width and list them side by side. What do people think about this?

Listing children in the infobox? I think listing them in the timeline is sufficient.

That's an interesting idea. If we expanded the timeline initially, we could list the children there without having to repeat them in the infobox.--Dallan 16:37, 20 June 2009 (EDT)

--Jrich 10:56, 19 June 2009 (EDT)

Source-less citations [7 July 2009]

Currently when you add a source citation it's possible to not select a "Namespace", in which case the citation doesn't link to a Source or a MySource page. This can be useful in cases where you don't have enough information to make it worth linking to a separate Source or MySource page. Let's call these citations "source-less" citations. In the proposal, I've been thinking about converting source-less citations to notes. When adding a new citation you'd select from "Community Source", "Personal MySource", or "Note". But is this a good idea? Should I add a 4th option to the citation type: "Source-less citation" or "One-time citation" or something similar?--Dallan 14:27, 22 June 2009 (EDT)

Could you give a specific example of this. I really haven't a clue as to what would merit "a sourceless citation", yet not have enough information attached to it that it wouldn't be worthwhile to place it in a MySource page, What is it that you want to accomplish with such a critter? Q 19:00, 25 June 2009 (EDT)

Anything that you only have a title of, or only cite once or twice, it isn't worth the trouble of creating a MySource page. (Yes, in a perfect world, you always have a complete citation, but turns out people aren't perfect.) "Vital Records of X town" when it turns out there are three sets and you never wrote down any other information. So and so's birth or death or marriage certificate (which is not scanned, so you don't have a copy.) Newspaper article that you took notes from 10 years ago. It's not "sourceless", it's Source Page-less.--Amelia 00:21, 26 June 2009 (EDT)

In otherwords, these are "Notes". There's definitely a need for having a capability to record things like this. I've seen others trying to do something similar, using various approaches. Putting something like this in "Notes" seems like an intuitively obvious approach; putting it in something called "MySource" is problematic because of the current ambiguitites of "MySource". Creating something called "Sourceless" seems to create its own set of ambiguities. This point speak some of the unmet needs of WeRelate; needs which various people have attempted to fill by applying existing features to different problems than they were intended. Having the ability to include some sort of commentary/note-taking, analysis to go along with the data seems needful. One could create "namespace" ad infinitum to take care of every new problem that came up, but there are probably too many "namespaces" as it is. Adding to the confusion. If its too much trouble to create a separate article (in whatever space you like), than probably just placeing it in something called "Notes" would be the better approach. Of course, you have to have "Notes" as a pulldown somewhere in the scheme to do that. Q 10:31, 26 June 2009 (EDT)

That's what I was arguing below -- having another namespace is completely unnecessary and they can share space with the notes -- but that I'd prefer not to have them called "notes", because they are not notes, they're citations. It's not obvious to put your sources in a "notes" field, and making that the option will make things more complicated rather than less. This is not an unmet need - it's a need currently met well and about as intuitively as it can be, and I'd rather it not disappear.--Amelia 10:58, 26 June 2009 (EDT)

It would seem that we probably have different perspectives on this. If you don't have enough information to call out a legitimate source, and don't want to take the time to create a "MySource", it would seem all you have would be notes. This seems more like a memory prompt so that you personally can get back to an unresolved problem. NO problem with that, except it seems well covered as a "Note". Q 11:24, 26 June 2009 (EDT)

I've gotten way behind in this particular discussion, but I'd like to say that "Notes," to me, means something entirely different from "unsourced." Notes are just your "regular" research work in a preliminary, more or less raw form. Using the same term to refer to a "sourceless source" is just going to confuse things. I have several MySource-type sources which are truthfully just placeholders, until I can find a better source to cite. Several of them cite websites where I have no idea what the original, "real" sources were (but I intend to find out, eventually), or have names like "Jacqueline R. Tevault research notes," where I'm simply accepting someone else's unsourced (but probably reasonably accurate) research until such time as I can re-do some of it. All the miscellaneous unsourced letters received from correspondents in the old days, and emails received these days are cited by "Correspondence with various other researchers." I'm not particular proud of those, of course, but you work with what you have. The point is, these are all MySources. It takes maybe thirty seconds to create one, since I don't really have search for a perhaps differently formed "public" source before creating them, and because no one else is ever going to use them but me. They work just fine for what they are. I don't see the need for an additional category of source -- or "source." --Mike (mksmith) 09:06, 7 July 2009 (EDT)

I'll agree with that. Overall, my primary concern is making the system easier to use. Easier to use means more people using it. More people using it means more ancestors being added. More ancestors added means more ancestors I can choose from in order to advance my own work. I'm being totally mercenary here, but easier to use is what's needed for the site to thrive. There are lots of features experienced users, and experienced genealogists might want to have available. They may be perfectly useful ideas, but if they make the site harder to use, then its counter-productive to add such features. Its a KISS problem, and KISS is almost always the best solution. Q 09:37, 7 July 2009 (EDT)

Sounds like an over complication to me. If there's a choice to be made from a set of terms, those terms should have intuitively obvious meanings that the end user (not a newbie end user) would not need to do a look up to figure it out. Somehow there needs to be a clean demarcation between things that are being cited as "sources" and things that are of the "this is why I think what I think" (ie, notes) sort of thing. In the current set up, Source and Notes are fairly distinctive. Images makes a sort of sense, though I suspect its little used. Its the "Description" that doesn't seem obvious to me. And if an "Image" is intended to display an image of an original document, how is it different from a source? Overall, I think there are too many choices to be made. Less is more.

I'm sorry, I'm not able to follow you. What is the "Description" field that you're talking about? Also, I dropped the "Image" source type; currently what we have for images is an Image page title field in the Source citation fields.

Perhaps were talking different subjects, but:

I see what you're talking about now. In this section I've been talking about the Citations table. i hadn't been thinking about the Events table. The Description field is needed for certain types of events like Graduation or AFN for a place to enter the degree name or Ancestral File #. But those types of events aren't used very often, and it might be just as easy to attach a Note to those types of events to hold that information. So maybe we should drop the Description field from the Events table.--Dallan 18:01, 25 June 2009 (EDT)

OK, but there does not seem to be a meaningful distinction between "Note" and "Description". If the Description is intended to hold something like a degree name, (ie., a "fact"), then perhaps there's a need for more events to chose from. As it is this seems to be an elaboration that just gives the user one more thing to figure out---hence, makes the system less accessible, and gains little. If things in this class are rarely used, devoting a big chunk of space to them in every page seems unnecessary. And if they are that rare perhaps just putting them into Notes is the easier approach. The rare individual with a need for this will figure something out anyway. Q 19:34, 25 June 2009 (EDT)

Please don't drop description. Otherwise everything that you want to say about an event that's not a proper place has to be a "red link." Like "Civil War", Battle of X, "died at sea", "Alabama or North Carolina", church names, cemetery names, AFN numbers, "formerly X county", etc. Putting that in notes just trades one allegedly complicated thing for another.--Amelia 00:21, 26 June 2009 (EDT)

Ok.--Dallan 16:17, 29 June 2009 (EDT)

My personal choice would be a system that allowed you to identify a source plus (if you needed it) a note. But sources are of many different flavors, and qualities. However, when it comes down to it, I believe that the basic choices are:

• Nothing (for shame)
• an ephemeral source of some description (e.g., a GedCom, John Smith's Groupsheet, etc)--bad
• a secondary source such as Source:Draper, 1881 --Good
• a primary/original source such as a specific letter in the Source:Draper MSC-- Best

Ignoring "Nothing", that's three choices: MySource, Source, and Document. The latter item, Document, could be a link to an image, transcription, abstract on WeRelate, or the Digital Library, or perhaps an electronic repository. Those options could come in the form of a pull down menu. I believe most "sources" that anyone is likely to use can be accomodated in this tripartite scheme, and the boundaries between these three types of sources is fairly distinct.

Eventually I'll probably add a Document option for transcriptions, but in the interest of trying not to make too many changes at once, I'd rather not add it right now. A Note simply provides a place for people to enter text; it doesn't link to anything else. Most desktop genealogy programs allow notes; I think we have to as well.

Believe it or not, I do understand your game plan here. Fine with me. The issue will probably continue to come up, because this element of "Sources" is really central, and I might add, unique to WeRelate. (Yes, I know, many desktop programs allow you to indicate sources. But those I worked with in the past (before I gave up on them), didn't really solve this problem in my opinion.) Werelate, on the otherhand, gives the promise of much greater precision in the way sources are handled. I see that as a central problem that needs to be resolved.

There is, however, yet another way the problem can be solved, and its already in place: The Digital Library. I know your longterm objective here is to use it for organizations, but it also has the capacity for storing document images, transcripts, extracts, etc. Initially that's what I used it for. I stopped using it in this way mostly because I found storing something there was much too time consumeing. too many fields to fill in, too many steps to be taken. And the worst problem (for me) was the need to cast the material into an HTML format so I could display things the way I wanted them displayed. Each item added took an inordinate amount of time. once added, it worked beautifully. Just too time consuming. That will probably change once you begin working on it again, (a simple(r) data entry system is needed. If you can ask for it on one page, you're probably asking for too much.) But at the moment, much too complicated. But if you solve those problems, it would be a good place to put transcripts and the like. Q 19:34, 25 June 2009 (EDT)

Oh, yes. By all means keep Notes. They are quite useful, and what they are is easily understood. (Comes under the heading of "what ever you want them to be".

The critical items that need to be retained are Sources (in whatever flavors you choose, but housed in a selection menu), and Notes

You might want to consider using some distinctive font appearance with these choices. That is, place MySource in "grey", Source and Document in black. (You could even reserve "black" for actual document's, and make secondary sources as "Darkgrey") That way, people looking over the information would have a visual cue as to the quality of sourcing. Easy to spot where improvement is needed, without resorting to banners and flags. Best, such an approach could be handled by the system automatically---with no complicated conditional programing---just the simple "is it MySource, Source, or Document.

An issue that should be spoken to somewhere is the distinction between an original source, and a transcription of an original source. Most of us are NOT going to see many original sources sensu strictu What we will have will be some's transcription, or an image. Personally, I don't think seeing an image of a census record, is much different from seeing the actual record (though they are not the same; there are cases where this subtle difference is important.) More critical is the difference between a transcription and the original. Ancstry's transcriptions of census records are a tremendous resource, but sometimes errors or wrong personal interpretations, creep in. So seeing Ancestry's transcription of a census is NOT the same as seeing Ancestry's images of the census, nor is it the same as seeing the original census report (probably no longer exists anyway--many of the census records that were microfilmed are copies of copies. Originals held in the hands of the census taker are I suspect, long gone.) These, however, are very very fine distinctions, and most folks are not going to see the point. So this is an issue that I wouldn't try to fold into the system, except as a caveat somewhere in the description of what these things mean. Q 17:00, 22 June 2009 (EDT)

I largely agree with Q (!), but I think there's a fair amount of system built around the current definition of source, which includes primary sources (even real primary sources, in addition to transcriptions, etc.) and secondary sources in the same system. Not to say we shouldn't allow document attachments, just that promoting them as better than citing source pages doesn't seem necessary.

The problem lies with the confusion in "MySource". Currently things that are very not good sources (GedCom's etc.) go into "MySource". So do things that are very good sources such as images of bible records, which supposedly, "are of interest to just a few people". I think this is not a very good situation, (or in the words of a fictional sage of my youth "double plus ungood") and makes things confusing for new users. (It also makes things confusing to me!).

The tripartite scheme was designed to eliminate that issue. In point of fact, I suspect that most new users will use only "Nothing", or Gedcom etc sources. Some will use Secondary sources. Very few will use Document or "Original Source" if you prefer. But it gives a place to put these things and does not create an artificial discrimination between things that are "of interest only to a few". Yes, there's a fair bit of stuff that's been built up around the current arrangement. But the current arrangement of MySource is less than a year old, and its not impossible to back this out. I think this needs to be done (or some other solution to the same problem put in place) as part of the process of making the site more user friendly. Its not at all like the concept of "family page" which is so embedded in the structure of the site that it can't be undone. (No reason to undo it either. Its different, causes some confusion, but it is an effective solution to a real problem.) The key to simiplification is, I think, making everything intuitively obvious. Q 07:59, 23 June 2009 (EDT)

The main reason for MySource is to support GEDCOM uploads. We have to have some place to put the sources in GEDCOM files. Even when we support matching GEDCOM sources to community sources, we still have to have some place to put unmatched GEDCOM sources. As I see it, we have two choices: use the MySource namespace, or don't create MySource pages during GEDCOM upload but instead replicate the information found in the GEDCOM source on every Person and Family page where the GEDCOM source is referenced. I was about to go with the latter option, but others convinced me that the ability to reference (unmatched) GEDCOM sources from multiple Person and Family pages without needing to re-type it is a good idea.

I realize that was the original intent, but WeRelate seems to have gotten away from that, including some perfectly sound sources, like images of bible records, in a namespace that's original devoted to tertiary/ephemeral sources that should never be used in the first place, but are. I think the site would be much better served to return to that original definition, though not strictly limited to GedComs. Family Tree's, personal websites, etc, also seem fair game for MySource. I think the name really says it all "MY SOURCE"---"this is where I happened to get this bit of data, and like it or not, even if its a really bad source, its all I've got"

While we're on the subject, one of the most novel and interesting uses of MySource that I've seen is in the work of one user who used "MySource" as a place to explain why they believed whatever they believed about this individual. Sort of an expanded "Note". I don't think that's the way MySource should be used, but it suggests that there's a need to be filled for some users. That is, a way to explain the "logic train" underlying their analysis. (Of course, since most genealogists don't seem to do much analysis, there aren't many who'd make use of this, but for those who do, its a need that should be filled.) Q 18:23, 23 June 2009 (EDT)

The MySources that are not tertiary/ephemeral (e.g., bible images) are probably the result of people creating them online, not as a result of GEDCOM uploads. So I think we can continue to create MySource's during GEDCOM uploads for gedcom sources that didn't get matched to Source pages during the upload process. Eventually I can create another namespace for documents/transcriptions; I just want to hold off on doing that right now so that I'm not making too many changes at once.--Dallan 18:01, 25 June 2009 (EDT)

To return to Dallan's question, Don't add a fourth option - it's way too complicated. Just leave us the option to have a plain text field and call it something generic like "plain text." Sourceless citations aren't actually sourceless - they are sources without pages. And notes aren't sources, but it's useful to have a place to put "children married by 1840" next to an estimated birthdate. But they both need the same fields, and we need that distinction less than we need more choices.--Amelia 01:31, 23 June 2009 (EDT)

Are you suggesting to have 3 types of source citations: Source, MySource, and Plain Text? I think I prefer Note to Plain Text; since most desktop genealogy programs support Sources and Notes, we'd be similar to them except that we'd be splitting sources into community sources and personal mysources. We currently have separate tables for entering source citations and notes. I definitely want to combine these tables into a single table.--Dallan 10:53, 23 June 2009 (EDT)

I'm going to jump in here. I think we have basically two different 'things': sources which are described on their own page (source and mysource) and sources which are just one-time cites which are self-contained.

It could be debated whether we need both sources and mysources in separate namespaces. But I like having the one-time source or self-contained source for those times where it's not worth creating a page. Calling it a "note" is terribly misleading. Calling it a document is confusing, since most of my documents have a perfectly good source attached. A "sourceless citation" seems a contradiction in terms - to me the def of citation is a reference to a source. It is really, really sourced, just without all the trappings of a wiki page attached - what you see is all there is.

Re Q's comment about seeing original use of MySources, this relates to a problem I ran into on the first person I ever entered...there is no way to have a sub-page for a person page. Thus the only avenue for breaking things up or discussing side issues is a mysource page. (articles aren't very satisfactory for this use) Subpages would be a veeery nice feature, but I suspect that's a whole nother ball game. Mysources make a nice substitute for us pragmatic types who don't worry too much about the original intent or the name attached - it works.

In truth, there are other options for what you are doing. For example, you can create a discussion in "article space", that explains your rationale. I do this frequently. Sometimes the "analysis" is just thinking out loud as I work through some issue. This, like MySource, requires some effort at backlinking, but it another way to handle the same problem. What you discovered is that there's a need in WeRelate to accomodate research. That's not really available anywhere else, but it can be done on a Wiki, and Werelate is particularly well suited for that because of the emphasis on sources.

With regard to "subpages" I've seen Dallans answer to this enough times now to know that "its never going to happen". The problem here lies, I suspect, in the technical issues involved in linking person pages.

Well, I wouldn't say never :-), it just complicates renaming, merging, and unmerging. So if MySources can fill the need at least for awhile, that lets me focus on other things.--Dallan 18:01, 25 June 2009 (EDT)

But the point of the discussion of MySpace (and why I keep returning to it) is that its a stumbling block for people trying to grasp how the system works. Most genealogists are not technically sophisticated. They need something fairly straight forward and intuitively obvious. For that, there's a need to keep distractions to a minimum. Having too many options is a distraction. Having unclear options is really really a distraction. Q 22:09, 23 June 2009 (EDT)

I think that the way mysources were created for everything in a gedcom is what made them so confusing. Very real sources were stuck into mysources with no way to link them back to a real source page. Who wouldn't be confused? The new gedcom import and the cleanup of sources should eliminate the need for many of the mysources. It would be nice to have a utility to move mysource references to the source it should have been without having to run down every page where it's used.

The term "source" is used in two very different ways. Sometimes its used to mean "this is where I got my information from citing a compilation of marriage rocords, for example. But the term is also used to refer back to the original document---ie, the minister's records that the compilation was based on. Its the tension between these two uses that creates the confusion. Q 22:09, 23 June 2009 (EDT)

We still need someplace for limited-use sources. I wouldn't oppose having "user sources" or mysources stuffed into the source namespace if they are still prefaced with someone's user id. But if gedcom import still needs to create them, I suspect it's still easier to retain the separate namespace.

My "thing" is for having a literal transcript. The benefit of having a site like this for collaboration is to let everyone bring what they found to the table and share. The ideal would be to have an image and a literal transcript. I want to know what it really said, not what everyone assumed.

So I like the idea of separating images of documents from the family pictures. But I don't think the image stands alone. It needs to be attached to a citation. I would like to see the image displayed on screen next to the citation. Sometimes it takes two or more images, so we need to allow for multiple attachments.

WRT notes. The note area we have today has mixed together source notes, event notes and general person notes. It would be really nice to have these sorted out. Currently information is widely separated on the page for one little fact: the event is wedged into the left column, the source citation is somewhere in the middle, then the notes are mixed in below the pictures. For a person with 20 or so events and sources that's a lot of scrolling. I understand the problem with trying to display sources with the events (where a source is used for several events.) But any effort to get things grouped more logically is to be encouraged. I could live with having the source repeated on the page if it helps. If there have to be tabs - so be it. It would be nice if the notes could be opened and viewed with the event facts.

re gedcom. I suspect every program does something different with the information it receives. While it is nice in theory to have designated places for citation information (page, record name, etc); for transcripts (literal transcripts or abstracts); comments (your inferences or thoughts) and extra information (links to web sites, etc) I suspect that it would get totally muddled on transfer. Even today I can't seem to find a way to have data appear into the text/transcript box - it always gets shuffled off to notes. So I could live with having a single place for "stuff", whatever it may be. The user would have to make it clear what the "stuff" is. Having more places just increases the chance that things are in the wrong place.--Judy (jlanoux) 21:08, 23 June 2009 (EDT)

I'll add a way to attach multiple images to a single citation.

If other agree that it's ok to have just a Text field in the source citation and not have a Notes field in the source citation, I'll drop the Notes field from the source citation. That will simplify the interface.

There is a definite need for a "Notes" capability. It doesn't have to be associated with sources, (and "Notes" should never be confused with sources) but I know some folks who are using Notes in preference to MySource or Source to insert extracts, by way of supporting a particular value for a data element. I suspect the reason for that is that the use of MySource is ambiguous, and what they have is definitely not a "source". (they're using Notes to surround a text extract with annotations. Novel, and probably better off in MySource, but it works for them. The main thing about Notes is that it gives you someplace to explain why you think whatever you think, or at least to condition the data you've entered. ie, DOB: cApril 1732, Note: Will written 30 March 1832 Probate date was 1 May 1832). It would be really nice if you could point to a primary source for something like this, but usually you there's some needed explanation---that's handled well with Notes. I myself tend to go with something more elaborate (using supporting articles and the person page narrative for this purpose), but after seeing some of the nice work others have done (particular Beth and Amelia) using the built in Sources and Notes, I'm warming to using them more extensively. Q 19:46, 25 June 2009 (EDT)

Regarding notes, I'm thinking that we would list note-type citations along with other citations in a Bibliography/References/Footnotes section at the bottom of the page. If a citation references image(s), I was thinking to include thumbnails of the image(s) indented under the citation.

Let's talk about a Document namespace later. Originally I was thinking of modifying the Image namespace to add an optional link to the Source that the image came from. But it sounds like a new Document namespace, where you could attach possibly multiple images along with a text transcription and an optional link to a Source, would be better.

We need to settle on a name for what I've been calling source-less citations. Is One-time citation ok?--Dallan 18:01, 25 June 2009 (EDT)

How about "text citations" or "non-linked citation" or "pageless citations"? They're not necessarily one-time.--Amelia 00:21, 26 June 2009 (EDT)

I like "one-time citations" because that is what they are. The other terms that have been tossed around are confusing.

Of the proposals so far, I think "One-time citation" or maybe "Simple citation"? are the ones I like best so far. (I've been convinced that we need something here in addition to Note.)--Dallan 16:17, 29 June 2009 (EDT)

Also, I agree that we need notes, but we need notes for sources and we need notes for events and then we need just plain notes not attached to either of those. I really dislike having the single note area with all of the notes jumbled together. A place for text that sticks with the event or the source would be much easier to use and understand.

I'm ok with merging the description field with the notes as long as the notes are going to display with the event. Right now they are too far away visually for warning type phrases such as "estimated date" that I have been sticking in the description in hope that someone would notice.

I think the citation area has too many different fields. It is confusing for many of the less experienced people. Many of them seldom get used. And each program handles them differently - often lumping them into a single field. Can't we consolidate some of these? In my testing, I was only able to force imported data into the page field and the notes. The text/transcript box currently displayed with the source always remained empty. I would like to see a single text box instead of two. Each new box is an obstacle requiring one to stop and decide which one to use.

In sum, I'd like to see a text box for event notes - stuck to the event; a text box for source notes - stuck to the citation; general notes like we have today for everything else. I'm don't understand what a document namespace would gain us. It sounds like things would be further scattered. But I do like the idea of being able to stick images to the sources and have a thumbnail display next to the citation.--Judy (jlanoux) 23:03, 25 June 2009 (EDT)

A Document namespace could be used to hold document transcriptions. But I don't want to worry about this right now.--Dallan 16:17, 29 June 2009 (EDT)

The problem is if we list events in an infobox on the right-hand side of the screen, which is what I'm currently thinking, long source citations and notes appearing in the same infobox would cause the same problem for the infobox that we currently have in the left-hand panel: it would make it too long. I think I'd rather have footnote superscripts linking to a separate bibliography section. (I could try bolding the citation in the bibliography section when you hovered your mouse over the footnote superscript, or I could display the footnote in a little "tooltip" window when you clicked on the footnote superscript, if you thought either of these ideas would help.)--Dallan 16:17, 29 June 2009 (EDT)

I think the one thing in this dicussion that I whole-heartedly agree with is that sources are one of the things that make WeRelate special. So I think, personally, it is worth effort to make it easy and effective to encouraging people to provide and share sources.

There are lots of ideas about how to make sources effective. I can live with many of these ideas, but I do think the current differentiation between Source being generally accessible to a competent genealogist (like a book in a library or even a resource at a for-pay website), and MySource being a source that is not generally accessible (like a family Bible that requires cooperation of the owner to view), that this dichotomy makes some sense. In one case you can track down the source and verify, and in the other, probably it will be difficult at best. Ideally, MySource type of sources should eventually include a transcript so that it can be a useful source to everybody.

So if there is a problem with the WeRelate handling of MySources, I would say it is in classifying all GEDCOM sources as MySource, causing MySource sources to gain a bad reputation. For that reason, I would gladly welcome a "Document" type of source to take on the role of transcripted/photocopied MySources, leaving MySource for unproven/unsharable sources. With this extra type, you could easily communicate to people that MySources are not desirable in the long term, and they should be working to convert them to one of the other types.

Hopefully before the end of the year we'll support Source matching during GEDCOM upload, and suggest probably-matching sources, just like we currently do for matching families. There's a fair bit of work to do before that happens, but it seems do-able.--Dallan 16:17, 29 June 2009 (EDT)

Just sharing data does not represent an advance in genealogy. It is sharing sources and improving knowledge of known sources that hold the potential to make WeRelate better than other genealogy websites.

Regarding Notes, there are many uses for notes. Genealogy is not just collecting sources, there is an element of integration and interpretation of those sources. This is different than the narrative describing the person or family. So to communicate what an estimate is based on, why you do or don't believe a source, the disputed lineage that is disproved by this source, etc., etc., notes are needed. I am a linear person, and I like the note to go with the item that references it, but the current system is like footnotes in a book, which is a system I am used to, as well. So as long as Notes remain, I have no major opinion. --Jrich 00:11, 26 June 2009 (EDT)

Removing citation fields? [7 July 2009]

One of the questions raised above was whether we could remove some of the fields from the current source citations. The Notes field is going away because we're going to merge notes into the Text field. We could also remove Record name and move that into the Text field as well. What do people think about this?

That leaves Page, Date, Quality, and Image. We don't want to remove images. The other three fields are part of the GEDCOM standard and people do use them. I've never been very fond of Quality because I don't think a simple drop-down is enough to convey the quality of a source, so I'd be open to removing that field if people don't like it, but I think I'd prefer to keep it just because it's part of the standard.--Dallan 16:17, 29 June 2009 (EDT)

I agree with your comment about Quality being suspect.

First, no source is homogeneous in quality, so each use of a source basically requires its own rating. But it is apparent some people's idea of quality vary widely (a GEDCOM is good quality?). So leaving it to the user to enter a quality rating each time is asking for meaningless data. My preference would be to assess the general quality of the source as a whole, i.e. on the source page, with the caveat that it doesn't guarantee its applicability in any specific use.

Second, what are we using this datum for? If there is not going to be some mechanism to flagging under-sourced pages based on this, why keep it? Since blank is allowed, what's the difference if you don't ask for quality and pretend blank was entered every time? If we are going to use this, then I think a decision tree should be developed that helps generate the rating value to assign to a source. --Jrich 16:58, 29 June 2009 (EDT)

I use Record Name all the time. For article titles when citing NEHGR or Wikipedia and for the name of the entry in something like Great Migration or Savage, primarily, though that accounts for the vast majority of records I've been playing with lately. If I remember correctly, we added it as a field because it served a useful purpose, and it was a welcome change at the time. I use page number as well, but I don't use date unless it's an article (and it could easily go in vol/page) - the pub date is already on the source page. I hate quality for the reasons described above. Can't remember the last time I've used an image, actually, since if I had an image of the source it would go on the source or mysource page (a reason to create a mysource page).--Amelia 00:22, 30 June 2009 (EDT)

I too dislike 'quality' because it is simply one person's assessment and we are striving for consensus information on the wiki page. That's not what gedcon was designed for. One problem with having more separate fields is the "entry barrier". It's intimidating to encounter so many blanks. Perhaps the text prompts could indicate that they all don't have to be filled in? (We got another question on that today)

I also use the Record Name field. It helps to get a display that looks more like a citation when using an article or citing a record that doesn't "belong" to the subject person (example: someone else's probate or obit) While I use the page field often and date sometimes, I don't trust that they won't get lost in gedcom and tend to repeat all the information in the text box. Basically I'm aiming for a decent looking citation and use whatever produces the best looking results. But that's only on the pages I fuss with by hand.

While many programs use some of the gedcom fields, the question I have is "do they use them consistently?". I find that things wind up in totally unexpected places. Cleanup after gedcom has become a mounting burden. And so few people want to spend time in such "not fun" tasks. Another problem I have been seeing is that event notes sometimes wind up in the description field and thus are strung down the side of the page. But there are other cases where a non-supported tag was imported as "Other" and the description field was really handy to show the original tag name.

Bottom line: all of the fields are useful at times. But the side-effects of inconsistent use can offset the value. I can live with either decision.--Judy (jlanoux) 00:49, 30 June 2009 (EDT)

Source data fields

Quality The problem with "quality" is that there's no criteria given. One person's idea of a source of "Good Quality" might be an original document contemporary with the event. Another person might see a transcription of such a document (a secondary source) as "good Quality", while another person might see an email giving the information, but not citing the source, as "good Quality". Absent criteria that are clearly laid out, this is not a particularly useful field. Sounds good, but in practice, without clear and obvious criteria, conveys nothing useful. Q 08:36, 30 June 2009 (EDT)

Description The note associated with this field says "Type any descriptive information you wish to include". That basically means type anything you want. How does this differ from "Note"? Given a choice between the two, "Note" is a lot more intuitive than "description". The former term just says "I've got something to say about this particular thing". "Description" on the other hand, leads to questions such as "Descriptive of the source?" Descriptive of the Date? Where I found this? What color book is this?, Avoiding problems is often a matter of avoiding setting things up in such a way that the naive user will not find intuitively obvious. Q 08:36, 30 June 2009 (EDT)

Because the text of the description field prints out on the left side of the page, I have gotten used to using Description to provide very brief additional information that helps define the event. I do this when I think appreciation of the event would suffer if the extra information was buried in the text of a source citation or in a note way down at the bottom of the page. For example, churches were the baptism occurred. (Perhaps this should be a place, but in general it is not, and to avoid red links, I put it in the description field.) Another thing I like is to add a notation when a child is a twin. No discussion, but an additional fact that some people may find useful or consider important. In some of the fact types, like military, the name of the unit, etc. --Jrich 09:58, 30 June 2009 (EDT)

Note If the proposal is to move Notes into Text, that's reasonable. I think "Notes is the better term for it, but the two things are largely redundant. If it simplifies the design, by all means put notes into Text. Also put "Description" into Text. Q 08:36, 30 June 2009 (EDT)

I have developed two separate uses of notes that are distinct from the text box of sources, so I don't feel they are redundant.

1. First, I try to explain estimates which I have entered in the page. These notes often include a [[Source:]] citation (I want people to know what the basis is) but they are usually represent analysis that may go away (no sense explaining how I estimated the birth date if somebody later finds a record of the exact thing). This use could easily be done using the text box of a source citation since a source citation can be removed as easily as a note can, but notes seem appropriate because the fact isn't complete, just a guideline to help future research, hence doesn't seem to need a formal bibliographic entry.
2. Second, a discussion that attempts to analyze, balance, and integrate multiple sources. This doesn't seem appropriate for the text box of a source citation because it does not want to be subservient to any given source. It wants to be the impartial judge rendering the verdict. If notes went away, the only place I can see where this type of material would fit would be to clutter up the narrative section, which I feel is properly used to present a history. (Of course, as people have pointed out, the size of the note boxes being a little small and lacking full formatting features, I do end up moving very extensive analysis into the narrative area.)

If Dallan combines text and notes as two components of a single source citation, then this implies they both pertain to the cited source. I guess analysis discussions that attempt to integrate multiple sources will have to go into the narrative. In that case, intuitively, looking at a source citation input area that gives me both a text box and a note box, I would assume the text box was meant to hold what the source said (transcript or abstract of the material) and the note box was meant to hold any discussion or analysis of that material, like providing the explanative comment that somebody is called son-in-law because they married the daughter versus they were son of his second wife by a previous marriage, etc. But I agree, it is a fine distinction, and would probably be blurred often in practice, making them seem redundant. --Jrich 09:58, 30 June 2009 (EDT)

There's no question that there's a need here to be met. Something is needed to give a simple way to discuss a certain fact. That discussion may be related to laying out a logic train why this particular value is the right one, and not one of several others, or at least why this value was chosen. It may relate to an amplification of the data, context perhaps, such as the name of the church, etc, or other data element for which there is no convenient way to enter the information. The issue here is, I think, how elaborate should this be made? I tend to opt for keeping it as simple as possible. Q 10:35, 30 June 2009 (EDT)

Citation ID Place this item third in the sequence across the page. ie, Date, Place, Citation. This is the most important field afer the data elements and deserves priority over the remaining fields. But simplify by calling it "Source ID". Less to think about, fewer problems, little if any advantage by referring to this as a "citation". Q 08:36, 30 June 2009 (EDT)

Image IDLargely redundant when you add the "Documents" type of source. Makes for an untidy page if you are writing narrative. Q 08:36, 30 June 2009 (EDT)

Name Data.

Name Field Why is there a "Citation ID" for name? What is it that you would lead you to want a source for this? That the person existed? Perhaps if you include a "title" with the name you might want to cite a source, but this seems overall an entry with little need to exist---especially since the spouse and parental entries include no source element. Q 08:36, 30 June 2009 (EDT)

How else would you indicate where you got the name from? If I track a person in the censuses from their earlier appearance in the parents' household to their first appearance in a family of their own, with a spouse and a couple of kids, then that latter census is my source for the existence of their children. Likewise previously unknown siblings who are mentioned in an obituary; the obit becomes the source attached to their names. --Mike (mksmith) 09:27, 7 July 2009 (EDT)

Was there a proposal to do away with notes altogether? I missed that. I agree that we definitely need notes. My beef was that source-attached notes, event-attached notes and just plain notes were all mixed together way at the bottom of the page. I'd like to see source notes stay near the source and event notes stay with the event. The 'just plain notes' can still have their own section. As has been stated, we need them for commentary and explanation. I thought we were debating whether sources needed one text box or two (separate information from the comments). I find that the comments often are intermixed with the information (in square brackets) and I often write a short explanatory note at the bottom of a transcript.

The real problem is caused by gedcom. Different programs direct information to different codes and then WR has to decide where to put it. If there's only one place, it's less likely to be in the 'wrong' place. --Judy (jlanoux) 10:50, 30 June 2009 (EDT)

Dallan mentioned that he was thinking of merging Notes and text. Q 13:04, 30 June 2009 (EDT)

I'll try to summarize the above discussion. If you disagree with the following, please say so. Otherwise I plan to make the following changes.

For source citations we'll keep "record name" and drop "quality". Also, we'll combine the citation text and citation notes into a single text field. The citations table will include source citations, mysource citation, "one-time"/"simple" citations, and notes.

For the events table we'll have date, place, citation(s), and description. (I prefer using "citations" as a column header to "source id" because I'd like the citations table to include both source citations as well as notes.

For display we'll show the source citation text field in with the source citation. Showing the event citations/notes next to the events is more problematic because I'd like to put the events in an infobox, and adding the citations would make the infobox really large in some cases. But I could do something with javascript to include a citation superscript next to the event that pops open a window or highlights that citation in the citation list when you hover over the superscript, etc.

--Dallan 23:21, 3 July 2009 (EDT)

Child Source [3 July 2009]

Here's the current layout for entering child data for a couple.

--Q 15:22, 26 June 2009 (EDT)

This seems to be missing a source citation entry box. I would think each child might have their own line of evidence showing that they were the child of this couple. Might be that most if not all would have exactly the same source for this, but not necessarily. While this is covered on the person page when you identify the childs parents, but this seems like the most plausible location for entering this information, since it's here that you identify a persons children.

yet on the person page we have this

Again, no opportunity to explain how you know that these are the parents of the children. Pining down DOB's and DODs etc wth sources is all very well and good, but the really important component of proof for a family line is showing how you know that John is the father of Robert, etc. There may be some other way this is indicated, but it seems like it should be at the obvious points where this information is entered. Perhaps that's what "Source Citations" is supposed to cover, but a) its not obvious, and b) seems like the evidence needs to be associated with each child. Q 15:28, 26 June 2009 (EDT)

I agree wholeheartedly. I was getting ready to bring this up myself. The lineage link is the essence of a genealogy and yet there is no explicit place to document it. And the child-parent link is a place where an extensive note is often needed to explain the logic used to make the connection. I've been thinking that the family page could have space for this since this is where the family is constructed (and the pages often have little on them.)--Judy (jlanoux) 16:36, 26 June 2009 (EDT)

I agree that there is no explicit place to attach sources just to document links to parents or child, and usually it is not obvious on the family page why children have been attached. But this type of information is seldom documented by itself, so the source almost always fits elsewhere on a page, usually on the person page of the child. When it is controversial, it is far more likely to need to be an extended discussion suitable for a note, or a topic in the narrative, or a discussion on the Talk page, rather than a simple matter of adding one source citation.

Parents can be documented in a source that is attached to either the birth date (since most birth or baptism records mention the parents), or sometimes I attach them to the name field of the child. Identifying parents in the source attached to the name field makes sense if it doesn't fit in the birth source because the parents usually determine at least the surname of the child.

Also, I don't find that many other times when I need to attach a source citation specifically to the name field. Out of thousands of pages, I have actually needed to comment specifically on the name probably less than 10 times (regarding how the person spelled his name when he signed it, or notes to indicate that they were known by two names, etc.) The actual fact of a person's name is usually contained right in every other source citation and hardly seems to need made explicit most of the time, i.e., the biography states their name as the subject of the bio, they are called Capt. or Dea. in the death record, etc.

Eventually, I would envision most pages having a well-populated timeline of deeds, wills, etc., that as a side effect, provide a comprehensive list of the various forms and spellings that their name took on in actual usage, all contained in the mature narratives. Just not at the current time. --Jrich 17:23, 26 June 2009 (EDT)

As Judy points out, "The lineage link is the essence of a genealogy". If you are going to document anything, this is what you want documented. Ad Hoc solutions are certainly possible, but judging from the nature of most person and family pages on WeRelate, that does not work for most people.

Yes, usually the parent child link is the one most difficult to prove. It is usually proven by a combination of interlocking information from varying source. The simplest case you could hope for would be to have a will (or bible record) identifying "Mary Smith" as the child of "John Smith"; In that case you could simply cite the will. (Of course, on WeRelate at the moment you'd have a hard time doing that because you don't have a clear place to put such items. I've used the digital library, and MySource, but there are no really good solutions at the moment.)

Moreover, documenting the parent child relationship is usually much more complicated than this. Not only do you need to show that "John Smith" had a daughter "Mary Smith", but that it is in the right time and place to be the "Mary Smith who married John Brown". Documenting that can get very very complicated.

Given the importance of this, you really do not want to leave this to ad-hoc solutions. There needs to be an explicit way of documenting the parent child relationship--or rather of proving that relationship. Probably that solution involves a combination of Sources and Notes, but whatever the solution is, it needs to be made explicit.

I too would like to see source citation boxes for child and parent relationships. I think that it is vital to document this clearly, but most genealogy programs do a poor job of it. This relationship citation ability is one reason I use The Master Genealogist as my desktop genealogy application. --Lauren 20:38, 26 June 2009 (EDT)

Last time I asked for this I was told that it is not supported by gedcom standards. So if we get the fields, they wouldn't be exported back out.--Amelia 23:32, 26 June 2009 (EDT)

Interesting bit of information that. Sounds like a serious deficiency in the GedCom standards. While exporting material through GedCom is probably an important capability, I suspect that its more important to be able to document the evidence for the parent child relationship. Q 08:10, 27 June 2009 (EDT)

I thought that might be part of the problem. I'd rather see a GEDCOM workaround and have WeRelate leading the way on sourcing! I know I couldn't easily transfer the information from my desktop program to WeRelate via GEDCOM, but for the relationships with more complex documentation, it would be worth the effort. Perhaps WeRelate could export the information in a GEDCOM NOTE with the text "Parent-Child Relationship Notes" and the citations attached? "Father-Child Relationship Notes" and "Mother-Child Relationship Notes" would be even better!--Lauren 09:29, 27 June 2009 (EDT)

I did some research on this. PAF, RootsMagic, and Family Tree Maker 16 don't allow source citations on parent-child relationships. Legacy 6.0 allows source citations on parent-child relationships by adding non-standard tags to the GEDCOM file. I don't have any other programs available to test.

What if we allowed adding source citations to the "Children" table of a family (so add a Citations column next to the child title column)? We could attach these source citations directly to the family during a GEDCOM export so that the desktop genealogy programs would be less likely to throw them away.--Dallan 16:17, 29 June 2009 (EDT)

That would work, I think. If there's anything that needs to be sourced, its the parent child. But this is often not as simple a matter as citing a single source. Commonly, you have to cite several bits of information to show that John is a child of Robert and Mary. That's why you need something like notes to provide the more elaborate discussion. Q 19:32, 29 June 2009 (EDT)

Ok, I'll allow children to reference citations & notes in the citations table, just like events.--Dallan 23:23, 3 July 2009 (EDT)

Other Issues [7 July 2009]

Since we are in the neighborhood, there's another issue related to ease of use, and eliminating frustration:

In particular, I suspect that the manual method of creation of cards, creates some serious frustration. If you are adding information by GedCom dump, then this is not going to be an issue---until you find you need to add a new child, or perhaps another couple.

Here's the problem: When you attempt to add a specific person, unconnected to anyone else, get a page asking for their name, sex, DOB, POB, DOD, and POD. Plus a selection of possible matches. You can select a matching name, and you're done. If not select Add, and you're done.

Now add the spouse. This is where the problems begin. If you go to the edit page and look for a place to add the spouse, you see Spouse and Children page, with a nice text box to fill in. Presumably with the name of the spouse, because you want to create a page for this couple. It also h as the note Add/Search?---which obviously means you can use this to either search for this person, or just add them if nothing is found. Apparently that's NOT what that means. Because if you type ibn the name of the person, you'll get a new page to search for them. Completely ignores the information you just typed in. You have to add the persons name again on the second page. Then search.

Best not to click that handy button "Exact Name?" as sometimes, if it can't find anyone, the system will make you start over. Hope you didn't enter a whole lot of detail, because that detail and the name you just typed in will be lost.

Etc. Same thing with the Parental and siblings page. But this repetitive typing in of requested information, only to loose it for "machine reasons" is not good for the frustration level. Among other things, folks presume that if you ask them for something you're actually going to do something with it, not ignore it. They expect there's a point, and if something doesn't work right, then they presume that the fault is their own. Tends to make for frustrated folk. The reality here is that some of the input text boxes function only under certain circumstances---specifically, when you create a person card "de novo"; then it seems to work perfectly. But when you try to add a person (such as a spouse or parent), it performs no useful function. I would think it would be better to replace the text box with a link "Add a Spouse" for this person (no text box). Clicking the link would take you to the same page as before, but without implying that you have something to type in on the first page. Q 20:10, 26 June 2009 (EDT)

I disagree with "it [the text box] performs no useful function". You can type in the page name (e.g., "John Smith and Jane Doe (2)") if you know it and bypass the Search/Add function altogether. You can type in part of the husband name and it will give you a drop down list of pages containing that starting string (you've got to pause to let it come up). So perhaps the request should be if there is a name in the text box when Search/Add is pressed, use that to pre-populate the search screen that comes next. This is what happens for sources. If you type in part of a source name and press Search/Add, the data is used to populate the Title field of the Search screen. You can add additional criteria in the next screen such as author in the next screen, of if title is all you know, just press Search straight away without adding any more details. --Jrich 09:21, 27 June 2009 (EDT)

You are quite right on that. I discovered that last night, also. Part of the problem, though, is that's not intuitively obvious. There seems to be a delay of a few moments

by which time I've usually hit the "find/Add button", and I'm off somewhere else doing that. Not realizing that if I'd waited a few minutes more some choices would pop up. Of course, this is only really useful if you've already added the person. Then you might have a clue as to what the index number would be, and can select that from the list of choices. Unfortunately, if you are trying to add a person in the first place, getting a set of 5 or six "John Brown (X)" choices isn't going to do you much good. part of the problem here is that this functionality is not intuitively obvious, and seems duplicative. Counting this popup list, there are three different ways to get list of choices. The popup list, the button to the right, and the button below (both buttons being labeled the same.) Its only after you work with this a bit that you realize those two buttons have slightly different functionalities.

ANother issue that I see is that when you add a card for the spouse using this sytem, their name does not necessarily appear on the Family page. You have to go back in and add them manually. Seems like its unnecessry work and perhaps should be streamlined. I say "perhaps" because it may be that there's a complication here that makes it a problem if the system does the adding. But if you are working on a family page, and add a spouse, seems like that should appear automatically.

I also find this manual system to be a bit buggy. Its pretty easy to make a mistake, and find that you have to start over. I've added in children on a page, only to realize that there was a mistake on my part of some sort, tried to fix the mistake, and found that everything ended up dissappearing on me. In one instance a child list of about ten persons that I'd previously added dissappeared, to be replaced by a single entry. I know that this happened because I messed up some element of the data entry, but it seems like the parts that weren't the problem should have been retained. In anycase, it didn't work the way I expected. Since the child cards had in fact been created (just not attached to the Family card, it was relatively easy to go back and re-add them useing the popup window. So we will look forward to the day when this operates a little more smoothly. Q 10:13, 27 June 2009 (EDT)

Assembling a family is the number one obstacle to recruiting new people to the site. Not one person that I have brought over here has been able to do it. Earlier this week I checked the help and tried to assemble a new family from scratch - it's awful and help is no help. On top of everything else we have a page naming convention that uses a person's name, but not all of their name. This is incredibly confusing for newcomers.

I have been trying to review the proposal Dallan made above, but it's been chopped up by replies so I keep losing the sense of the plan. I'm still working on it. I wish the family page was optional. I find that having this essential part of a person's life spread across three or more pages to be a hindrance to getting a feel for the person. It also allows errors to creep in. Chronology is important to a researcher and all events must be seen in order.

I liked the idea of a family sidebar to display and also add members of the family. It would be nice if you could simply "add spouse" and then "add a child with this spouse" and "add father" or "add mother". Once both people's names have been entered, the system could construct the family page in the background if it is necessary to have one.--Judy (jlanoux) 13:00, 27 June 2009 (EDT)

Some additional, POSITIVE, thoughts, after further exploration. It maybe that the problem with using this system for manual input is encountered primarily when you are trying to "batch" enter spouse and children. That's where I encountered gliches, at least. It works admirably well, however, when all you are trying to do is add a single child, spouse, or parent. YOu either find a pre-existing card, or you don't. If you don't, you add the person. If you do, you link to the person.

Part of the problem may be that people expect to simply enter in their family data---not look for pre-existing cards. But that's a critical difference with WeRelate.  No Other genealogy wiki that I know of is attempting a "one-ancestor-one card" approach.  That is, there's no attempt to get people to merge family trees so that there's only one card per person.  And of course, this makes no sense at all for any non-wiki internet environment.  Since folks are not used to searching for a pre-existing card for their ancestor, the steps involved in finding that card make the process very strange.  Perhaps that's the point that needs to be sold more.  Q 21:20, 27 June 2009 (EDT)

Definitely a key differentiator for me: encourage everybody to participate in one tree. After all, only one version is actually true. I kind of wish there was a little better measure of consensus, but this is so much more than any site that lets the creator own their data, and nobody can change it, only create an alternate reality. --Jrich 22:37, 27 June 2009 (EDT)

That bit about "a little better measure of consensus", is the other part of the WeRelate trifecta---the emphasis on sources. The reason there's so much confusion in genealogies found on the net (and on home computers as well) is that it is the rare individual who records "why they believe what they believe" and document that through sources. If you ask a question on one of the message boards like "What evidence is there that Hugh Porter married Violet Mackey" (a current problem for me), you either get a) no answer, or b), "I've got her listed as his wife!". Rarely will you get something like "I don't know about the Mackey part, but his will of 1842 identifies his wife as Violet", and then give the source of the will.

The later answer is what you are looking for. Not complete, but it at least establishes that her first name was Violet. That's what gets recorded in the source and notes section on Werelate. Then when someone comes along they can see the evidence for (or perhaps against) Hugh's wife being Violet Mackey. Its not so much a matter of building a concensus (though that's part of it); its a matter of showing the evidence, and lettng the evidence resolve the problem. As it is, without sources, people are simply left with either a) personal opinion, b) accepting an "authoritative voice" (usually the person who shouts the loudest), or c) looking for the most commonly accepted (consensus) opinion. Q 07:41, 28 June 2009 (EDT)

Above I mentioned the "WeRelate Trifecta". For me that's

"Pando", a "one ancestor-one card" data base	To minimize the "alternate realities"!
An emphasis on evidence	To show which view is more likely.
GedCom upload capability	To make it easy to expand "Pando"

Its the combination of these three things that makes WeRelate work in a way that other wiki's, and sites like Ancestry, do not. Q 07:47, 28 June 2009 (EDT)

---

I've thought a lot about the problems with adding families/spouses/parents lately. My current thinking is that the new "find/add" link will take you through a process where you add the Person and Family pages together. So if you're adding a spouse to a Person, you'll enter birth+death+marriage information about the spouse, a list of possible matches for the spouse will be shown, you'll press "Add" if the spouse doesn't already exist, you'll be taken to a new Person page for the spouse so you can enter more information like source citations for birth and death, then when you save this page you'll be taken to a new Family page where you can enter more information about the family like a marriage citation.

If you're adding parents to a Person, you enter birth+death+marriage information about both parents and you're presented with a list of possibly-matching families. You'll press "Add" if the family doesn't already exist. Next you'll be shown a list of possibly-matching pages for the father. If you click "Add" to add a new father you'll be taken to a new Person page for the father so you can add more information. When you save this page you're then shown a list of possibly-matching mothers. If you click "Add" to add a new mother you're taken to a new Person page for the mother. When you save this page you're taken to a new Family page for the parents so you can add marriage citation information if you want.

Alternatively, I could create the Person pages or the Family pages in the background without taking you to the Edit screen for them. But then you'd miss out on the opportunity to enter additional information about them unless you edited the pages later. I was going to do this (create the pages in the background), but someone suggested earlier that since one of the main emphases of this website is on source citations, maybe we should give people an opportunity to enter source citations as they're entering people. The easiest way to to do this in my mind is to let people edit the pages as they're adding spouses and parents.

As for doing away with the Family pages altogether, I might go down this route given an opportunity to start completely over, but I've used another website that adopts this approach and it comes with its own challenges.--Dallan 16:17, 29 June 2009 (EDT)

I like the idea of starting with adding the spouse. It's more natural and the system should then have the info needed to then create and title the family page. Can there be some automatic saves built into the process so that the current page is saved before trying to open a new one?

I don't like the idea of adding "parents". I would prefer to add Father or add Mother. Can this be made into a somewhat linear process by prompting? (I don't know the limitations of web-based entry.) If a Father had been added, prompt for Mother? Then for Family? Or could there be on-screen text prompts when in edit mode? (like mini-help?)

The challenge is that we have to deal with Family pages. If you add just a father, then we have to create a Family page with a link to the father and a link to the child. We can do that, but if you're going to add the mother right away then we have to rename the family page immediately. So if you have information for both parents, why not prompt for the vital stats for both up front, so you can create the father page, then create the mother page, then create a properly-titled family page? If you have information on only one spouse, you can create the Person page for just that spouse and create a "So-and-so and Unknown" Family page until you find out who the other spouse is.

As Quolla has noted previously, the current problem is worst when entering a whole family from scratch. Thus you still have the first person open in edit mode and try to start adding parents or spouses because those big empty boxes are staring at you near the top of the page. It's very easy to lose everything with the slightest mishap.

Is it possible to have a pop-up window to show pages recently created in the background and instruct the person to return to enter more information? (Will my browser surpress the pop-up?) Even opening Contributions in another window would help. We have to keep the 'rookies' in mind. They don't know all these little tricks. And many users will remain 'rookies' longer than the people participating in this discussion.--Judy (jlanoux) 17:27, 29 June 2009 (EDT)

I've considered the possibility of not allowing people to add relatives while they're in the middle of editing a page. So you have to enter the name, events, and sources about someone, then save the page, then click on "Add parents", "Add child" or "Add spouse" links that would be presented when the page is displayed. This would reduce the possibility of accidentally losing something. I'll post the new work flow process to the sandbox before it goes onto the main site, so people can give feedback on whether or not we should restrict users from adding new people while they're in the middle of editing other ones.

For me, the issue becomes not of making rookies put in an overly long apprenticeship, but of keeping them involved at all. People whose help I would have particularlly appreciated, and were theoretically willing to work various problems, took one look at the manual data entry and "sorry, I don't have time to learn such a complex system." And these were reasonably adept genealogists, fluent in the use of computers.

I believe that one of the reasons that so few people convert from inputting their GedCom, to actively working the site, is that the technological bar is so high. Complex problems sometimes require complex solutions, but overly complex solutions mean fewer participants. The original concept, I thought, was making this "drop dead easy". Hard to do that, but one way to achieve it is to keep the system as simple as you can get it, and still retain functionality. Technologically, and genealogically sophisticated users such as Amelia don't need an easy to use system, as they have the skills and experience to figure things out, and achieve their goals by other means. There's a carefull balancing act between keeping it simple enough so that the naive user can work the system, yet retain the functionality that the more experienced user wants and needs. That was the idea underlying my suggestion to have user preference switches that would allow the experience user to turn on some features, but not bog down the naive user with features they couldn't make sense of. Q 19:52, 29 June 2009 (EDT)

Yep, still have way to go. Let's see what be implemented over the next few months.--Dallan 23:36, 3 July 2009 (EDT)

In the interest of simplification of use, especially for new users, I wonder if it's really necessary to have the initial data entry process you described at the top of this section call up a series of separate pages? You fill in info on one page, then it automatically pops up the next page to fill in, and so on. Would it not be possible to have all those data-entry forms (each of which is actually rather brief, apparently) be collected on a single data-entry page? Name of the individual (search/add), name of the parents (search/add each of them), names of known children (search/add) -- then click a "Completed" button at the bottom, and have the separate Person and Family pages be created behind the scenes. Maybe with a pop-up in "Beginner" mode that reassures the new user that you can go back at any time and add more children, add a previously unnamed father, and whatever. I'm thinking that the fewer pages you have to wade through in succession, the less intimidating it would be. --Mike (mksmith) 10:32, 7 July 2009 (EDT)

I agree a cleaner manual data entry system is desirable. The problem comes from a unique feature of WeRelate: Pando. There's a need to find pre-existing cards, if they exist, for the person someone wants to add. Only if a card for that person doesn't already exist in the system should the new data be added. Otherwise there's a need to find a match, and link to it. No other program, desktop or online, has this as a requirement. Some of the cumbersome aspects of the manual data entry form stem from this need. Dallan appears to be working those out, and I expect a solution will eventually materialize. Q 12:03, 7 July 2009 (EDT)

---

[add comment] [edit]

Parent Child Evidence [7 July 2009]

I recently pointed out that a deficiency in the data entry layout on the family page was the fact that there was no way to show the basis on which you established the fact that a someone was the child of a particular set of parents. Someone noted that they thought the reason for this was that it was something not supported in the GedCom Standard. I placed a query on this on the GenMethods list and received the following answer:

The GEDCOM standard supports the specification of one of four types of relationship of child to a family (PEDI tag subordinate to FAMC tag). These are: birth, adopted, foster, sealing. (Sealing is an LDS ceremony of adopting a child into a family.) Also, there is an "ADOP" event available for each individual. This may contain the reference to the family which adopted the individual (FAMC sub-tag) and a sub-tag (ADOP) to specify which or both parents as HUSB, WIFE or BOTH. Thus:

0 INDI @I1@

1 FAMC @F1@

2 PEDI adopted

2 NOTE As and if required.

3 SOUR ...

1 ADOP

2 FAMC @F1@

3 ADOP HUSB

....

0 FAM @F1@

1 CHIL @I1@

....

There are a small number of programs that support these tags as defined. Some others define custom _MREL and _FREL tags within the family record to define the relationships of an individual to "father" and "mother" of a family. Note that custom tags may not transport reliably between programs. With respect to sources, the GEDCOM standard does not permit SOUR as a sub-tag of PEDI, but it does permit SOUR as a sub-tag of NOTE as a sub-tag of PEDI.

From the above it appears that if WeRelate created a capability to explicitly explain how the parent child relationship was established, (other through a general note) there would be no way for that to be included in a GedCom export. Hence this is a likely explanation of why this is missing on the family data entry page as originally suggested.

The question then becomes, Should the inability to export this information via GedComs, be a reason for not including a space to explain how individual parent child relationships have been established? Q 08:24, 1 July 2009 (EDT)

---

TMG has Father and Mother sources. This issue is familiar to me since we had the same problem when designing TMG. I just did a quick test and they aren't gedcommed. Gedcom is a poor data transfer medium and Wholly Genes seems to have focused on direct database transfer as a better solution. I don't think Dallan wants to write a transfer for each program out there,

1. so a compromise of some sort is needed.
2. I would like to see a place for a Citation reference next to parent family and the child family, even if it is tossed on export. Dallan had mentioned exporting as a family source which is fine with me.
3. We've mentioned that a note field is needed in the case where a case must be built using several sources and the reasoning explained. I would like to see the general "person note" retained and perhaps relocated nearer to the top of the edit page (maybe above events?).
4. I'm ambivalent on name sources. I don't see much use for them. In the rare case a name needs explaining the person note could, and maybe should, be used. But since I usually ignore them, they don't bother me either.
5. I cannot agree with the often used argument that the birth sources also takes care of parentage. In my experience, the methods documenting either the date or place of birth (absent a 'certificate' or post 1880 census) never deal with parentage. And many sources for parentage never mention birth date or place. --Judy (jlanoux) 10:59, 1 July 2009 (EDT)

I generally concur with all of the above. On item 4, in the interest of keeping things as simple as possible, something that serves no real purpose only distracts, and should probably be jettisoned. Q 12:05, 1 July 2009 (EDT)

Although I would dearly love to do away with the name source for the reasons listed, I've noticed that, either by practice or poorly designed program/gedcom, some people put all the sources about a person attached to the name and nowhere else. I don't think it would generally do any damage to those entries with only one name if the sources are just left on the page, but in some cases, the sources are divided among several alternate spellings based on how each record spells the name. Deleting the name sources therefore might remove some useful information.--Amelia 12:16, 1 July 2009 (EDT)

---

I don't understand item 5 entirely. Or perhaps disagree, given the use of the word 'never'. Can you elaborate?

Vital records generally do name the parents of the child, or at least the father. Most baptism records do too. Family Bibles usually list them as Children of father and mother. Most genealogies list the children under their parents. In the modern era, as you point out, a birth certificate would give both the date and the parentage. So it does seem to me that usually a birth source does establish parentage. Not in every single case (i.e., calculating birth from a gravestone wouldn't), but I suspect a vast majority of source that actually document the birth event will name parents.

I suspect Dallan could always dump non-standard notes and sources about a link in various ways to make it fit GEDCOM guidelines using various tricks the way various genealogy programs do, or he could simply append them to the narrative with superscripts referring to the source list, etc. But he probably would have some difficulty making the round-trip work (export out of WeRelate, upload back in, looks the same).

Since I use old software and have been managing to find ways to document parentage, other than imitating TMG, I am not sure what is being asked for. On the page for a child, you want to know who his parents (not parent) are, and for the parents you want to know who their children are. Documenting that connection sounds like one piece of data that needs to link to three different pages (two if you link to the Family page in lieu of linking directly to parents). Following data design rules, this suggests you need a new type of Connection: page so you only have to store the source about the connection once and it can be linked to by all the associated pages without a lot of redundancy. That sounds ugly.

Without that, you are left documenting the connection either on the Person page of the child, or the Family page of the parents. Since in difficult cases, even if a source only proves the connection of one child, the impact may effect all the other siblings, and possibly even the status of the parent's marriage. So, if I had to pick one place to document this link, I would prefer the family page, so the makeup of the whole family can be considered holistically. Then people would just have to be alerted, that the documentation of a person's parents, if not obvious from their birth record, is on the family page they are linked to. --Jrich 12:25, 1 July 2009 (EDT)

I suppose that this is less an issue for folks whose ancestors all went to church to have their children baptized etc., or births were routinely entered in civil records, etc. In many cases though, you don't have that kind of information routinely. If you are lucky, some sort of bible record survived and you can get a child list from that. But even then, its usually more complicated than just citing the bible record. (How do you know that its your ancestors bible record, and not someone else with the same name? That's one of the reasons professional genealogists want to see the chain of custody for a bible record before they'll accept it as proof.) A will is also good for this, but children who have predeceased their parents will not appear there. For the most part, documenting that "C" was the child of "A" and "B", is a more complicated problem than just citing a single record. And if a single record does exist for this, it mayay not be, for example, a birth record, or other vita data that you might associate the parents with. If it were so simple as simply finding a record of the birth, giving both parents and child, there'd be a lot fewer brickwalls that had to be broken. Q 13:36, 1 July 2009 (EDT)

I agree. I have an awful lot of people who appear as adults in the 1850 census whom I have no idea who their parents are, out of a pool of possible parents in the county. In Perry County, Indiana, for instance, there are scores of FRAKES families who arrived early in the 19th century and whose descendants were still there in the early 20th century -- and some are still there in the early 21st. . . . And they tended to use a limited number of given names. And they all intermarried, over time. If I have a document that says George Frakes was the father of John Frakes, I still have no idea which George (out of a dozen available) is being referred to. This sort of thing is even more common in frontier areas before the creation of local government, and if they weren't avid church-goers. --Mike (mksmith) 10:51, 7 July 2009 (EDT)

---

Wow, you're right! As many times as I've looked through the GEDCOM standard document I never noticed this. Create a source inside of a note inside of a PEDI tag inside of a child-of-family reference (you gotta love the GEDCOM standard.) I've seen PEDI tags in GEDCOM files, but I'm not sure I've ever seen source citations inside of notes, or anything inside a PEDI tag. But it's nice to know that there's at least a standard way to express it if we want to export it that way.

I think I'll start off adding a citation field to the children list on the Family page. This will at least capture the information. We can start by exporting these as citations attached to the family. This leaves us open to possibly sometime in the future creating custom GEDCOM exports that target specific desktop applications using _FREL and _MREL tags or sources inside notes inside PEDI tags.

And notes attached to people aren't going away. I'm not sure I'd put them above the events table though.--Dallan 23:53, 3 July 2009 (EDT)

My Source for this is Nigel Burton on GM. I know nothing about Nigel, but its obvious he's intimately acquainted with GedCom standards. He's added the following item

I should have added that the ADOP event permits SOUR sub-tags and a custom EVEN event could be created for Fostering (or any other event), which itself may have SOUR sub-tags. Therefore, if you specify events for individuals defining the establishment of the (additional) family relationships, SOUR sub-tags may be freely used for each event.

Possibly this could be used to help solve the "non-standard" marriage relations currently being discussed on the water cooler. In the case of adoptive parents perhaps there could be a split where one lineage followed the biological parents, and one line followed the adoptive parents. I know this is a perplexing problem for a good many people Perplexing in the sense that most genealogical software does not easily allow for such distinctions, but also perplexing in that there are often emotional/social issues associated with the decision to record or not record. Giving folks an option might be helpful. Then they could follow whichever path they consider the "right" path, without having to explain their decision, or both paths if they so choose. But not all problems can be solved for folks, and the programming necessary here might be prohibitive. Q 08:34, 6 July 2009 (EDT)

---

[add comment] [edit]

Starting point for family infoboxes [7 July 2009]

I've been playing around the last couple of days with an idea for displaying parent and spouse families on Person pages. (Don't worry about the colors right now; it's the general idea I'm focused on.) These infoboxes would be displayed down the left-hand side of the page, and I'm thinking that I'll put the names+events in a much wider infobox on the right side of the page, similar to what Wikipedia and Familypedia do. I leave on vacation tomorrow so nothing will happen for the next couple of weeks, but I thought I would share this and solicit comments.--Dallan 00:07, 4 July 2009 (EDT)

I don't seem to be able to get the Sandbox to load today; I keep getting the "server reset" error. Is it "hung" in some way? --Mike (mksmith) 13:07, 7 July 2009 (EDT)

That looks like it would do the job nicely. Colors, as you point out, need some work (the orange background in particular), but the functionality looks good. Will this be a tab, or a pulldown thing? Better one of those than something that continuously occupies the narrative space. Q 10:47, 4 July 2009 (EDT)

I like showing the information, but the text size (making it so that most names won't show up in full at first) makes it look like it's a work in progress (it is, of course, but you don't mention that that's something you want to change!) Wikipedia deals with this by just using a small font, which makes it look much better.--Amelia 11:13, 4 July 2009 (EDT)

Go look at how infoboxes are used on Wikipedia (pick a U.S. president or a king or something). The box lives full-time in the upper-right quadrant of the page. And, as you say, it uses a smaller-size font to be able to include everything, but it's still quite readable. The point of an infobox is, it's a repeating pattern of key information, so when you've seen a couple of them, you know what to expect from the next one you see. It's the place you learn to glance at before deciding whether to read the whole page. --Mike (mksmith) 11:00, 7 July 2009 (EDT)

---

• Seems clear for parents: only one set, right? But what about multiple marriages? I assume you would repeat the orange box for Spouse and Children? In date order? Have an Add Child for each marriage?
• I assume the green box, for the Family page, would have some kind of link allowing you to go to that Family page and same for all the persons in the various subboxes to their specific Person page.
• You can add a sibling to the parents marriage from a person page? No real problem with this, but if there are many children in a family, each of the children's Person pages is possible place where new child can be added to the parents marriage? Wonder if this may make it too easy to add children to wrong marriage when parent has multiple marriage?
• How would erroneous parents or spouses be removed? Another link, or have to go to corresponding family page to remove link to the person? --Jrich 11:19, 4 July 2009 (EDT)

I think (suspect) that what Dallan has in mind are tabs that open up on the relevant page, displaying information that's been entered elsewhere. That way, when you look at a particular person, you can click the tab to get the parents information. Overall, you wouldn't need to display multiple spouses here, since each child only has one set of parents. (you might be confused about who they might be, but they've only got the one set.).

I think I started out saying there were only one set of parents. But a person can have multiple spouses. So if the example I saw was a prototype layout of a single person's page, and that single person could have multiple spouses (four in certain familiar cases :-) ). Also, it sounded like he said they would be arrayed down the left side of the page, so no hint that you could need to tab to get to one infobox, but it sounds like probably all pertinent infoboxes would be displayed all the time? And if the single set of parents are mistakenly identified you need to remove then and replace them with new ones. There was an item at the bottom to add an additional spouse, nothing to remove. --Jrich 14:06, 4 July 2009 (EDT) Q 16:44, 4 July 2009 (EDT)

Perhaps the question is whether these are to go in the sidebar, or in the narrative area. In either case perhaps if there is more than one spouse, a second Spouse and Children info box would be added. If the info boxes go into the left hand sidebar, one wonders how source information will be noted. Same S1, S2...Sn convention as before, with the sources displayed at the bottom of the narrative. If the info boxes go into the narrative area, then there's definitely going to be a problem with overcrowding the top of the narrative---unless these are tabbed items, which seems like a reasonable compromise. Q 16:44, 4 July 2009 (EDT)

Here's the way it might look if the infoboxes are displayed along the left hand side of the Narrative. See InfoBoxTestDisplay.jpg Q 17:06, 4 July 2009 (EDT)

And here's how it might look in the sidebar (see:InfoBoxSideBar.jpg. I was surprised how well that comes out. Clearly condenses the information into something more manageable, and visually more appealing than I'd have ever thought this would be (not to mention better than the current display). Also, the script that allows the boxes to expand at need is a nice touch. Forget about tabs in the narrative space. This is much better. But how will you handle sources? part of the expandable fields? Q 20:02, 4 July 2009 (EDT)

I vastly prefer the second - the first is pretty awful (no offense), although my comments above about making it look more sophisticated apply. I don't think we need sources for this family box -- the sources go on the person pages in question. This person's information is going in a different box that would be in the center/right side of the page, and that part has sources.--Amelia 20:07, 4 July 2009 (EDT)

I completely agree. The infobox should take the place of the lefthand sidebar, not just repeat the information presently found there. I mean, that's its job. And you don't need to include sources; the infobox isn't meant to replace any part of the narrative. It's merely a quick, limited summary of key information. Anything you find there will (or should) be found in the narrative section down the center of the page, with more detail and with sources. The infobox should definitely not be on a tab. That defeats the purpose of being the first place you look. In terms of appearance, I'm assuming Dallan will go with a smaller font and (please) pastel colors. --Mike (mksmith) 11:10, 7 July 2009 (EDT)

Just trying to give a sense of what some of the possibilities would look like. The first one wouldn't be too bad if it were converted into tabs, rather than a static display as seen here. However, plopped into the narrative area, it would play havoc with any effort to write a coherent story. In anycase, I now think the second version is probably what Dallan intends. Looks good to me. Q 20:48, 4 July 2009 (EDT)

---

On the color aspects, I think I understand why you've alternated the colors for each row: when you open the complete box to its full extent, you need to be able to distinguish it from where it overlaps with the other boxes. So there's probably a need for colorization here. If you use pink and blue tones then there's implied information about the person's sex being conveyed. Even if this isn't intended, people are going to assume that there's sex information here at least at first glance. So better to stay away from pink and blue. If different colors are in fact needed, then something neutral would work best I think. Pastel's usually work well as they don't intrude. That's why the Orange doesn't work well---too intrusive. You might want to consider using monotones---say different shades of gray, or some other color. The parent Sibling, parent-child tabs would probably work best with different color palettes. That way there'd be a subtle cue to the user as to what they were looking at. So when they pull down the wrong tab, they don't get confused. The distinction wouldn't ever need to be spelled out; It's the kind of thing we monkey's learn intuitively. We soon learn from experience that "yellow means ripe" and "green means not ripe", and parents don't usually have to explain that. Q 11:54, 4 July 2009 (EDT)

---

[add comment] [edit]

Grounding Design in User Experience [21 July 2009]

Please read:

How to Select a Match in Sources

I say this because this is someone who has been using computers for over 20 years, and s/he's struggling with the interface. I have attempted to help the person but they've given up. (I made one more offer.) If we seek critical mass and "normal" computer users, we've got to make things a lot easier.

jillaine 08:36, 20 July 2009 (EDT)

HI Jillaine. Thanks for pointing to this example. It well illustrates the frustrations I think people have with the data entry interface. I've pointed to a couple of instances that I've seen, but they've been smaller in scale. Same problem, just not so much detail. Most folks just say something like "I'm so frustrated I could spit", and then leave. In some cases its a matter of unrealistic expectations, but usually I think its the manual data entry issue.

"User retention" is, I think, a big issue for all of the genealogy wiki's. The focus of WeRelate has been on the GedCom data entry approach, which is great! "That's what's made the site thrive. But continuing to work the site means you need to be able to modify things, add additional families etc, and that usually means a manual approach---rather than reloading a GedCom. And that's where things start to fall apart for folks. IF you are persistent, and
IF you have good computer skills, and
IF you are clever,
IF you don't come into it with unrealistic expectations,

you can usually work out how to do many things that initially seem frustrating. And its right about at this point that I think we begin to loose people. Part of the problem is that those who do persist have a very high skill set. They overcome the problems, so no longer see them as problems. For them the system works well enough. We have a theoretical user community of about 18000 people---those who've given the site a whirl, and have registered. But when I do a head count of Active users---people who continue to use the site on a regular basis, there's probably fewer than 100---probably fewer than 50. That's actually better than any other genealogy Wiki, but it still speaks to there being an underlying problem. To make the site thrive we need to increase retention. I think, as you do, that one of the key's to that is in fact the data entry scheme. Needs to be simpler, more intuitive, easier to use, less unexpected. Q 10:23, 20 July 2009 (EDT)

---

The case being mentioned sounds like somebody was trying to do the Find/Add function from the general Search screen, or possibly they clicked on the title of the source instead of clicking the button to "Select". So they ended up looking at the Source page itself, and didn't recognize what they were looking at. I have done this when distracted while working, but through experience, I recognize where I have ended up, guess how it happened, and recover easily. An easily avoidable situation given better training materials.

I found the tutorial nearly completely useless when I started. But after all, the system is in Beta and changing, so it is hard to justify developing a detailed tutorial when parts of it will undoubtedly become obsolete. And given the modern tendency not to read instructions, a long tutorial may not help. But bottom line, there are some things that a user simply has to know about to use the system effectively (this is true of any program). WeRelate is a little different than most genealogy programs, but if people take the time to think about it, instead of just giving up, most of it makes some sense, even if the users wouldn't have chosen to do it that way. The question is, did they come here because they can dump their data on yet another free website, or because there is a feature here that they value. If the former, they would tend to give up at the first difficulty because there are alternatives. If the latter, they should arrive at a synthesis with the working of the system much quicker because they might understand, or be more willing to accept, why it works the way it does.

So, maybe proper tutorials will help usability (but perhaps multiple versions are needed: a quick one for those who get impatient reading instructions, and a more thorough one who approach new things with trepidation and want to know every detail before starting). Should we force people to page through the tutorials, before enabling data entry? New users need to have the situation explained so they understand, not just what they are getting, but what is expected of them, like the idea of community data, providing sources, checking your Duplicates list every time you sign on, etc. They need to recognize the different namespaces and what they are each intended for. Date format, place naming, source titling, etc.

There probably are tips that can be listed on some help page that will make things easier. If you do things like use tabs in your browser so you can look at multiple pages at one time, and turn on the Browser feature to remember old entries, you can get your browser to help fill in some of the fields. Also using the WeRelate auto-complete in sources and places is useful to ensure correct entries, but you have to watch capitalization. There are lots of help that can be added as details of the system solidify, but often a person is not ready to receive tips until one has been sensitized to their value by doing things the harder way.

So, I think the fundamental answer is "unrealistic expectations" (I might say non-wiki-aware). I have only done manual data entry now for over a year, probably starting to approach 5000 people and the user interface is not that bad. It doesn't take any longer to add a person to WeRelate than to my home system (when you include honestly documenting the sources). WeRelate is doing new things, and so it works differently. Some people don't have the early adopter mentality, and will give up. Me, I don't think they are ready for WeRelate, not the other way around. The question is how to make them ready? I also think that there is an issue of extrapolating the long-term usability from a still-underpopulated Beta system where some changes (such as screening of duplicates, the future source cleanup) have yet to take full effect.

Finally, I have seen lots of messages say we have to make this easier, but I have seen little in the way of specific suggestions or ideas. Perhaps I lack imagnination, or misunderstand the nature of the call for a change, but I am having a hard time picturing many changes that don't involve significant changes to the basic architecture (how data is stored, redesign of namespaces, major software changes). For example, it was a lot easier back before there was the Find/Add step in adding new pages, but it was nearly impossible to tell if the individual already existed. If making it easier required eliminating the Find/Add survey of existing pages, I would find that unacceptable. But if there is some specific suggestion about focusing the list of possible matches, then that would be a useful starting point for a discussion of a possible feasible change.

We don't have users because the search engines aren't cataloging WeRelate pages, because WeRelate is still in Beta, not because it is hard to use. We need to get out of Beta, so the pages start showing up when people use search engines to search for their ancestors. I came here to collaborate, but the amount of collaboration I am doing, as measured by the changes notices I get on watched pages, seems to be running 8 or 10 times as much on WeRelate-centered discussion as for the thousands of Person/Family pages I am watching. I want Beta to end, the pages to show up in search engines, so more researchers come to the site, so I start getting more change messages about the people I am watching. --Jrich 11:47, 20 July 2009 (EDT)

I've made numerous suggestions here and elsewhere designed to make the system simpler, easier to use.

We have almost 18000 "users". I guess that fewer than 100, probably fewer than 50, persist. Most simply upload their GedCom, make a few edits (one day's worth seems typical), never to return again. Using the most optimistic numbers, that a retention rate of 0.5%. Fewer than .5 persons out of 100 continue to work the site. My guess is that's closer to 0.2% continue to work the site.

And people ARE finding this site quite nicely. Visitor statistics (Quantcast) show that we get about 18,000 visits per month. Most (58%) come from visitors who do not return to make continued use of the site. (What they do here I don't know. The remainder of (42%) are from folks who are regular users (the same 25 to 50 I pointed to above. Of the non-regulars, I suspect that some try the system, and mostly quit; Others look it over and leave after one visit. Some find useful information here, but do not become active contributors, just visit occassionally to check what's new. And a few, a very few, figure out how to make the site work for them, and persist long term.

This is about the same as our friendly competitor Genealogy wiki---They are not in Beta, and have been full up and running longer than WeRelate. They do have a slightly higher visitation rate, but their retention rate seems to be far less than that of WeRelate. My working guess is that they have about ten regulars. ---despite having a natural feed in from Wikia, plus a significant advertising campaign.

And as far as search engines not cataloging Werelate because its in Beta, that's is not true. I run across hits for WeRelate quite often in my own searches.

Q 12:35, 20 July 2009 (EDT)

You seem to be right about the search engines. I thought Dallan wasn't going to enable this until Beta was over, but at least relatively old pages seem to show up in response to searches.

I am not sure how to interpret what you are saying with your numbers. The one comparison you give suggests WeRelate is doing better than similar sites? And I have no idea what are good or bad numbers in terms of the ratio of contributors and browsers anyway.

Dallan has proposed changes, you have made suggestions, as have others. Then this discussion on being easier gets started. So one asks, what else is being asked for? How easy are you (the people asking for easy, collectively) imagining easy to be? Of the easy that is being requested, how much is an education issue versus a change in the program? What is the expected return for the changes being requested? It is easy to assert that more people will participate, but the numbers above suggest maybe that is not so, and in any event, it does not mean that better data will come in. What changes will be of most value to people that do good genealogy? Do we need a poll to reach some consensus about what is easy, or do we use one anecdotal story as motivation to change things?

Making things easy would be far less important to me than getting sourced, quality data, because I find the system satisfactorily usable already, but I find there to be too many holes in the data and frustrating lack of sources. I see whole families with no sources, even when they exist online for anybody to see. I see Mayflower lines having gobs of sources available, but entered into WeRelate with major errors, or petering out after only one or two generations. I understand the need to attract users, but not at the expense of losing differentiation from familysearch.org or worldconnect or ... And catering to the dump and go crowd will simply bring in a host of AFN collections. So help me out by defining what easy means: what specific features are difficult and could be changed without asking for fundamental change? The bad genealogists out there can easily overwhelm the serious ones. Convince me that your changes will make it easier for serious genealogist without simply letting in bigger numbers of bad genealogists. --Jrich 15:01, 20 July 2009 (EDT)

---

Jrich is right. I came over here and dumped a frustrated user on a mature conversation. I'm frustrated because I am concerned about losing potentially quality content when frustrated users throw up their hands and leave. This seemed like the place to "dump." My apologies. You all have clearly done some great work here (back in June). I re-read it. And it looks like things will get simpler.

I'm hopefully getting on the phone with this frustrated user this evening and as we walk through her challenges, I'll have a much better sense of what would be easier for her.

And jrich, I'm completely with you on the need to stress bringing quality to WeRelate. However, I believe there are people out there who have such quality and may be willing to contribute it, but who will run screaming from the "room" if they have to spend too much time figuring out how to do so.

-- jillaine 16:19, 20 July 2009 (EDT)

---

In the discussion on How to select a match in sources, it was said the steps the user took were documented. It would probably be useful for post-mortem purposes if they could send or post that. Then it would probably allow more focused aid when you get on the phone, and would provide useful insight for improving help pages, or even suggesting a concrete improvement to the software. --Jrich 18:13, 20 July 2009 (EDT)

---

I spoke with her. She actually has a greater challenge than navigating the g'darn Find/Add source pages (which was the "presenting" problem). If you're interested read Help_talk:GEDCOM. Sigh. jillaine 19:38, 20 July 2009 (EDT)

---

I'm sure there are lots of people out there that have not been documenting sources sufficiently, for example, to create a bibliography. Many like me, did some of our work that way and came to realize, perhaps because they start sending reports to fellow researchers as a way of sharing, so switched. This is one of the reasons why long ago I argued that GEDCOM uploading is asking for trouble. It encourages everybody to think they should be able to just transfer their data, when their data was not prepared with public exposure in mind. This is why the argument that things should be easier scares me, because in many cases the problem is not how things work, but how easily their data fits into WeRelate. --Jrich 20:32, 20 July 2009 (EDT)

---

Oh she's documenting her sources *sufficiently* -- she's just not using technology tools to organize the information/details; she's dumping it all into a free-form text box. So the information is there, it's just not in fields. jillaine 21:10, 20 July 2009 (EDT)

I understand all that and I think she could leave them as MySources and they will be fairly useful to others even in that form, and she and others can clean them up as time and motivation permits. In that sense, I think WeRelate has actually been easy to use, since it allows MySources to deal with this situation. It also seems to me that it is fairly forgiving about place names too, in case people don't follow the same 4-part place names. And it accepts almost anything in a date field. But regardless of all that, she chose to enter her sources the easiest way (presumably) - as many of us do - because in our home system, we are doing it for ourselves, whereas with WeRelate, sharing with others requires a certain discipline. Likewise, lots of other common issues that are appropriate in our home system, but not in WeRelate, like people marking their descendants with "(X)" which isn't significant to other people, or counting generations from immigration which doesn't mean much in a global family tree, or leaving their contact's email address or phone numbers in their notes. Years of common, but not ideal practices, done according to some personal style that they developed over the years, each person with their own quirks. If easy to use means converting all these individual styles to standard form, that is not reasonable. If easy to use means accepting this data as is, I believe it happens already. --Jrich 23:50, 20 July 2009 (EDT)

---

[add comment] [edit]

Displaying Events [27 December 2009]

I know this discussion is focused on data entry, but I have to be able to envision the ultimate result in order to know how I want it entered. So I'm asking "Where are we on display of events?" I dislike the current display with the events strung down the side of the screen. It makes it very difficult to comprehend, plus involves too much scrolling. I have a strong preference for events to be displayed in the middle of the page before sources. More information could be displayed with less vertical space and less scrolling. The would have an additional advantage in that we would not have so many empty looking pages due to the dearth of sources.

I would strongly prefer events to be sorted cronologically. I think this would help to bring a lot of date problems to light. Also I would like to see marriage in that chronology on the person screen.

I do like the proposed info box for parents and spouse for the left side of the screen. --Judy (jlanoux) 17:54, 27 July 2009 (EDT)

---

This is a nice interface for a family. It would be great if something like this could be used for data entry as well:

http://trees.ancestry.com/tree/142027/family/familygroup?fpid=-2101599400

Jillaine 14:04, 29 November 2009 (EST)

Thanks for the link. I'm planning to spend a fair amount of time studying the ancestry interface as I think about how to re-design ours.--Dallan 00:13, 26 December 2009 (EST)

---

Merry Christmas guys, and Happy New Year.

I'd say I use ancestry becasue I have done a reconstitution on my parish of interest. The abilty to quickly populate a tree with reasonable sources is the attraction. Its a double egdged sword though - mistakes easily made take a while to remove. But if they are done correctly the linking gives sourcing which,while they are ancestry centric. have few typos because they are generated automatically.

The interface is friendly and though it may not be the pinnacle of design, I'd say a majority of people are familiar with it - the microsoft office of genealogy I'd say. (no-one uses wordperfect or multimate any more)Might even make it easier to 'poach' some disgruntled (but quality minded) people over here.--Dsrodgers34 01:43, 27 December 2009 (EST)

---

[add comment] [edit]

Ancestry interface is proven successful [29 November 2009]

We can't ignore the success of the user interface of ancestry public/private memeber trees. You hear lots of complaints about it but that might be an indication most people cannot ignore it.

What specifically do you like about the public/private member tree interface? One thing I like when searching Ancestry's database of these trees is that the search results indicate whether or not the tree is sourced. I just wish they'd sort the results with sourced trees at the top. Jillaine 23:21, 17 November 2009 (EST)

In 3 years the public/private member trees have gone to 750/200 million records - 950 million in all.

Plenty of garbage and duplicates in that but there is also the figure that 270 million of their transcribed records have been linked to records in public/private trees. If you assume that is mostly census entry links thats 30% of the english speaking (US, england etc) I reviewed a parish from england in 1901 and sure enough, 30% of the census database had links to at least one person public or private trees (133 of a sample of 400). That discounts duplicates so the ony duplication in terms of individual ancestors is the fact many people appear in several census. If you imagine that an individual might have an average of 3 links to different census thats 90 million ancestor records in Public/Private trees which unique and have some form of sourcing - 10% of the total entries in Public/private member trees.

There are over 9 million public and over 3 million private photos loaded

Of course there are huge shortcomings in the ancestry setup but the interface, particularly the linking to sources, sometimes whole families at once - is very popular and acceptable to potential users. Of course there are 'name collectors' there but who's to say these people can't be inspired to high lavels of quality ?

Obviously there isn't the rigour and I'd like to be able to break links as easily as you can make them, for example.

Of course I'm in here because the Wiki principle is much more flexible to build other information structures which don't 'fit' ancestry--Dsrodgers34 08:19, 17 November 2009 (EST)

---

Good point. Of course the reason that they have so many people is because they're Ancestry, not necessarily because they have a great design. But it's still true that they have a lot of good designers at Ancestry and that they've spent quite a few years working out the kinks. And we could learn a lot from them. It's been quite awhile since I've looked at Ancestry's trees. I'll have to spend some more time looking at them before re-designing our person/family interface.

For that matter I think we could also learn a lot from Geni.com. Are there other online web interfaces that people like? And what in particular do you like about them?--Dallan 12:45, 29 November 2009 (EST)

---

We can't compare numbers to Ancestry when they actively promote copying and we delete duplicates. I've noted that Ancestry seems to have buried their One World Tree. Maybe they finally acknowledge that it was a tool to facilitate the spread of misinformation. But their new Member Connect features are nice. And perhaps they will help promote better quality. I have already begun to notice that after I link to someone in another tree (which indicates that I think they are the same people, not that I like their data) the tree owner will start to copy my sources and correct their data. Creating these cross-links between the trees helps create more 'rigidity'. It is also nice that you can see who has already been linked to a record from the image page. This too is helping avert some "same name-different person" type errors.
Geni doesn't really support research well at all. It seems more like a social networking for families type thing where pictures and news can be shared in a private area. But I do like the way you can add people from the Tree view. This helps prevent errors by beginners. The downside is that you can't enter more than a name, birth and death without going to the edit page. So beginners seldom add any more than that.--Judy (jlanoux) 15:31, 29 November 2009 (EST)

Retrieved from "https://www.werelate.org/wiki/WeRelate_talk:Data_entry_design"