WeRelate talk:The Tree Concept in WeRelate

Removing the concept of "tree" from WeRelate [31 October 2008]

Currently at WeRelate you have:

• A Watchlist. You get notified every time a page on your watchlist changes.
• One or more Trees. Trees are used by the Family Tree Explorer for the ancestors and descendants view and the list view. Every page in your trees is also in your watchlist. It is possible to email a link to one of your trees to a cousin and have them "copy" or "adopt" the tree; that is, add every page in your tree to their watchlist and to one of their trees.

Trees introduce a fair amount of complexity, not only in how easy the website is to use, but also in the back-end code. Most people have just a single tree, so their tree and their watchlist are the same. But a few people have many trees, each with different lines. I would like to modify WeRelate to remove the concept of trees. Instead, the Family Tree Explorer would be shown on every page (you wouldn't have to launch it anymore), and it would display all connected people, whether they were in one of your trees or not. Pages not in your watchlist could be slightly grayed out to let you know that you weren't watching them.

The question is, what features do we need to add when/if we remove trees? For example, here are some alternative approaches to copying or adopting another's tree. Some of these ideas might also be useful for adding new pages to your watchlist after it has been merged with someone else's tree:

1. Introduce a feature to "watch all pages that user so-and-so is watching". This seems pretty broad to me -- I may not want to watch everyone that you are watching.
2. Introduce a feature to "watch all pages that are related to a given person". This also seems pretty broad to me; I believe most people don't care that much about distant relatives, and this could have people watching a lot of pages they don't care that much about.
3. Instead of "watch all pages that are related to a given person", restrict it to "all direct ancestors of a given person," maybe with an option to include their immediate children. We could also limit the number of generations to watch, and maybe add an option to include 2nd or 3rd cousins of the individual.
4. Another approach is to combine the first two ideas: "watch all pages that are related to a given person so long as user so-and-so is watching them".
5. Finally, you could add a set of pages into a category, and we could allow others to watch every page in that category. Using this approach it could be possible to automatically add to people's watchlists new pages that are added to the category.

Any thoughts?--Dallan 19:24, 28 October 2008 (EDT)

The Watchlist Approach

Am I right in assuming that if you pick all ancestors of so-and-so, it is generated once, and then it is your responsibility to extend your watchlist when somebody adds another generation, etc.? Or is it maintained as part of the add, so that every time a page is add, all watchlists are scanned and it is automatically added to all the ones having the appropriate criteria (which sounds like a lot of processing that may not scale well with large number of users)? Or is it dynamic, built when you go to MyRelate->Watchlist?

It is sufficient for me to be able to add all ancestors. A new ancestor would presumbaly generate a notificiation when somebody attaches to a person in my watchlist and I can manually add the new ancestor to my watchlist. Or just ask it to watch all ancestors of the same root again.

It would be generated once. If someone added a new person related to an existing page in your watchlist, the existing page would be updated with a link to the new person and you would be notified of the change, so you could then decide if you wanted to watch the new person or not.--Dallan 00:34, 30 October 2008 (EDT)

Even if I was working with a cousin, my experience is that our interests diverge at some point, and we effectively are watching all ancestors of different roots...

--Jrich 20:45, 28 October 2008 (EDT)

I would want to automatically watch the pages generated by anything I upload or any page that is merged with pages I am watching. And then so that my cousin can watch with me on mutual pages, could we have an option to work on 'descendants of xxx'? That would work for us because we know our immigrant ancestor and are working to fill out that tree. 'Descendants of xxx' would be better for us so that we don't have to watch everything each other is watching. I'm not interested in my cousin's father's line but we work together on his mother's line. --Janiejac 22:14, 28 October 2008 (EDT)

I think you said that backwards. You want to watch all ancestors of xxx. Say it is a real cousin, i.e., with a common grandparent and different parents: you watch your ancestors (i.e. your parents, not theirs, plus the common grandparents and so on back) and they watch their ancestors (i.e., their parents, not yours, but the common grandparents and so on back). If you watch all descendents you will get all cousins, i.e., everybody descended from that common ancestor, possibly thousands of people, including your cousin's entire tree. --Jrich 22:31, 28 October 2008 (EDT)

No, I really meant 'descendants of'. I know my ancestors back to the immigrant. If that's all I wanted, I'd be through. But my web site is for 'descendants of the immigrant'. Yes, I know 'descendants of' gives more than I may want, but I take all male descendants and limit the women to three generations. It would be a lot easier for me to unwatch long female lines (using 'descendants of') than to try to find and mark 'watch' on each upline. So is it possible to set the system up to select either 'descendants of' OR 'ancestors of'?

Sorry to misinterpret. Your reference to not being interested in your cousin's line confused me. Your reply suggests (in an ideal world) that it might be nice if each user could build their own rules for their watchlist, that reflect their chosen scope of research, but I suspect this may be hard to implement. I do direct ancestors and siblings, but add their spouses in order to identify other surnames whose researchers may know something that helps me. --Jrich 10:07, 29 October 2008 (EDT)

I'm also thinking that you would automatically watch pages you uploaded and what those pages merged into. Having an "include descendants of X" on the watch action is no more difficult than an "include ancestors of X" on the watch action. These actions make the most sense when your pages get merged into pages that open up entirely new lines, and you want to specify to watch multiple people in those lines at once, without visiting every page.--Dallan 00:34, 30 October 2008 (EDT)

I've always been a little troubled by the "tree" terminology anyway, since that implies a sort of connectivity that may not exist in the collection. Also, I always saw the watchlist as an equivalent concept anyway, except that you can only have one of them and I expect to eventually want several.

If we jettison the tree collections, how will I be able to designate subsets of my watch list for export as GEDCOMs? Could the watchlist be generalized such that a user can have more than one, or have a computed (read only) watch list that consists of a boolean composition of subsidiary watchlists?--Jrm03063 22:38, 28 October 2008 (EDT)

Argument Against Removing the Tree Concept

As I have written on the Merge Review page:

I myself am against eliminating the adopt a tree program. The is the whole reason I joined into WeRelate, was to contact cousins, have them adopt the tree and thus begin collaboration. Without that option the site is of little use for me, other than just another Gedcom upload, such as WorldConnect. None of my cousins are going to take time to manually set themselves to watch each page of a particular family tree (my CLARK tree for example has 530+ people in it) and setting to only watch the Ancestors of one person is of little advantage. (just my humble opinion)

• I do not use WeRelate as my genealogy database, I use software on my own computer (The Master Genealogist) that WeRelate would not be able to match in capabilities for years (IMHO).
• I do not care about an ability to download the information from here into my computer, I maintain my database and hand enter anything I find into TMG, so I can be sure it is properly entered and sourced.
• I do not use WeRelate to have other cousins "find" me, because it is so new and so unknown, for that I use RootsWeb.

The reason I am here and spending hours on my "trees" is solely to have them adopted, and begin collaboration with other cousins, exchanging facts and photos. This means WHOLE trees, not just a few ancestors. The whole concept of Wiki style collaboration on family trees is what I remember being stressed in the Genealogy magazines, which led me here to this site. Taking away the trees now, I feel, is like yanking the rug out from under my feet. (she says as she steps down from her soap box...) --Kristy 00:02, 29 October 2008 (EDT)

I don't understand how trees help you that much, nor why "all ancestors of xxx" doesn't help? Do you create a different tree for each collaborator once you have made contact? Because any pre-constructed tree is unlikely to represent their scope of interest. A cousin shares grandparents, which means only half of our trees overlap. A second cousin, only a quarter of our trees, etc.,etc.

Why is it that when they join WeRelate, creating their watchlist through one or more "all ancestors of xxx" or perhaps a fancier selection criteria, wouldn't work? Then they get notified of changes to those people, and when they see children, spouses, parents added, they merely need to extend their watchlist. Vice versa for you. They are the best judge of which people they want to watch, not you by building some tree for them. --Jrich 10:18, 29 October 2008 (EDT)

If I understand correctly, you want to be able to have your cousin add a set of pages to their watchlist, where that set is more complicated than something that can be defined simply as "ancestors of X" or "descendants of X". You'd like to be able to specify exactly which pages are included in the set, and you don't mind taking the time to manually add pages to this set. Is this correct?--Dallan 00:34, 30 October 2008 (EDT)

Yes Dallan, within my own software here at home (TMG) I can use a filter to create a specific gedcom containing ALL descendants, of a certain Oldest known ancestor, their spouses and the secondary spouses to those (in the cases of multiple marriages), etc. I then upload that specific family to a specific tree WeRelate, and then invite specific cousins to adopt that specific tree. Since those cousins are descendants of the Oldest ancestor in the tree I have created and worked so hard to establish here at WeRelate, they are in fact related and interested in all members, thus be willing to collaborate with me. My database here at home contains 62,000+ names, needless to say folks are not interested in that whole thing, so I simply have uploaded several small "specific family" gedcoms to individual trees here at WeRelate --Kristy 02:08, 31 October 2008 (EDT)

Breakdown of uses of Watchlists and Trees

I think we may be using trees and watchlists for too many diverse reasons. Perhaps we need to look at the variety of uses and if there are more efficient ways to do those things. I'm sure this list just scratches the surface....

HOW can we have too many uses for this site, the more it is used the better and more popular/successful the site is. If the site has no use for some beyond what they can get at other websites, they have no reason to return here. --Kristy 02:08, 31 October 2008 (EDT)

By no means was I saying there are too many uses for this site, or that it shouldn’t be used in a myriad of ways. When contemplating whether or not to remove/replace one of WeRelate’s components, it is in everybody’s best interest to examine the variety of ways in which that component is being utilized. If somebody were to say “You can’t eliminate trees! I use them to sort families that I need to {insert task} with.” Then, I would suggest that maybe trees aren’t the most efficient solution for that. Perhaps there could be user-specific categories or other methods of tagging that could be developed that would be easier to maintain. My intention was to dissect trees and watchlists a bit and start to analyze their uses, not to imply those uses are not positive.--JBS66 09:56, 31 October 2008 (EDT)

• Watchlists
  • forum purposes – shouldn’t this be a separate entity, not connected with the concept of watchlists? I envision a more traditional forum where discussions are threaded and I can see what talking points are new without being informed via a watchlist.
  • inter-user communication
  • watching other pages I’ve contributed to such as places, sources…
  • as a substitute for trees
  • as a limiter for searches
  • family tree purposes – being informed when someone has made a change to a person I’m invested in.

• Trees – These too are being used for multiple purposes.
  • For tagging pages that you want to do something with later. Tags would be better for this than trees.
  • For knowing which ancestors are mine
  • For collaboration

[Moved FTE discussion to own subsection below --Ronni 12:18, 31 October 2008 (EDT)]

Essentially, WeRelate is one big tree – we are all somehow related – that’s what’s great about it. To have these mini-trees that say but these are mine is counter to that community feel. Watchlists could evolve to become a nice alternative to trees.--JBS66 08:53, 29 October 2008 (EDT)

This is a good summary of the different uses. As I read the comments above, it seems that there's a need to be able to specify sets of pages for export to a GEDCOM or to request that a cousin add the set to their watchlist or just to do something with later. Your watchlist is one such set, but you may want to specify additional sets. Some pages in a set may not even be on your watchlist.

1. A big question is whether these additional sets can be defined with general rules like "ancestors of X" or "descendants of X", or whether people need finer-grain control over which pages are put into a set -- the ability to add specific pages one into a set.
2. If we go with finer-grained control where you select and add individual pages to the set, a second question is whether we'd also want the ability to use rules like "ancestors of X" or "descendants of X" to add a bunch of pages to the set all at once.
3. A third question is how we would want to use these sets. Would it be necessary to use them to narrow searches (I only want to search on people in a particular set)? I assume we would want to list all pages in a set, export all pages in a set, send a set to a cousin for adding to their watchlist. Are there other things we would want to do with sets?

--Dallan 00:34, 30 October 2008 (EDT)

I do not understand why we need to create "Sets" isn't that just another word for "trees" aren't Trees in fact sets? It seems like you are trying to re-invent the wheel here. --Kristy 02:08, 31 October 2008 (EDT)

How much does this idea of a watchlist act like a category, or are the two technologies inherently incompatible mechanisms? I ask in context of creating arbitrary groups. Say someone is an author, and wants to study the descendants of the founders of the town of Concord, or Eastham, or the Continental Congress, or whatever for a book? Or follow all the ancestors of the two presidential candidates. (I am stretching a little here, but I hope these are reasonable examples.) Can the two concepts be rolled up, so multiple groups of interest can be defined, and you can watch one or more? --Jrich 08:57, 30 October 2008 (EDT)

I use the FTE daily. I do not object to eliminating the tree concept and FTE as long as I can still function as well in WeRelate without it. I would like the ability to copy a "tree"; everyone in the tree to remain as an option. I use the FTE for navigation in the trees that I have established; and yes I have multiple trees and will have many more. I assume that there would still be some method of navigation. The pedi-map is not hyperlinked; it is not very helpful for navigating. I also use the list of My Sources in the FTE to check to see if the MySource can be eliminated if the My Source no longer has any links. Navigating through my watched pages is not a good option. I currently have numerous watched pages; from working as a volunteer on WeRelate that I really am not interested in watching; I always forget to check unwatch. I have culled some of these, but I need to do some more cleanup.

If you go to the MySource page for your source, under More is a command What Links Here which will show you what references it. You can use search, specify MySource as the namespace and put your user name in the surname field to find all your pages. --Jrich 10:38, 30 October 2008 (EDT)

Unlike some other users, WeRelate is my genie program except for my personal family file. I do not enter the data twice; it is only on WeRelate. This is done in anticipation of the ability to download a gedcom of selected persons (my research) and the upcoming genie program that will interact with WeRelate. So anyway I am not opposed to change; I just cannot visualize the effects of the change.--Beth 09:16, 30 October 2008 (EDT)

FTE Stability

FTE - I don’t use FTE because I’ve found it to be very unstable with Firefox. If it stays the same programmatically, and is just moved to appear on every page, would it then cause every page to be unstable? I do like the idea of presenting the data on the left of person/family pages more visually, pedi-map style. However, I don’t necessarily like the usability of FTE for this purpose. --JBS66 08:53, 29 October 2008 (EDT)

How do you find it unstable with Firefox? I'd be interested in knowing.--Dallan 00:34, 30 October 2008 (EDT)

With Firefox, the problem happens upon exiting FTE. It will produce a dialog-box that says "firefox.exe has encountered a problem and needs to close"... Then it will close all of my open Firefox windows. (I have firefox 3.0.3).

For me FTE is also unstable. However I use it everyday. I have found (for example) if I want to add an image while I am in FTE, it is best to open the link for that in a new window. You have to be very careful not to navigate the window that is on the right, out beyond Person or Family pages. --Kristy 02:08, 31 October 2008 (EDT)

I tried FTE with IE 7 this morning. I'm having trouble with that too. In Pedigree and Descendants mode - with the nice icons - the icons don't move along with a selection. FTE will load with the ancestors of my bookmarked person, and when I click on an icon it will go to that person's page. The icons do not re-adjust to then put that person down at the bottom. Also, at the bottom of FTE it says "loading page..." and the IE bottom bar has an error message (permission denied). I did install the latest java update 10, and did test that java is enabled & working on both browsers. I also have Adobe Flash version 9 installed.--JBS66 12:31, 30 October 2008 (EDT)

Thanks - this gives me something to go on. I'll focus on making sure these problems don't continue when the FTE appears on every page.--Dallan 14:45, 31 October 2008 (EDT)

FTE ideas [9 November 2008]

My thinking with the Family Tree Explorer is that the "Ancestors and Descendants" view would be shown in a box to the right of every person/family page. (I'd move the google ads to go across the top.) It would show everyone the person/family was related to, not just people in your tree. Clicking on a box would navigate to that person/family's page.

When a slot in the tree was empty, it would be replaced by a "+" button that would take you to the "Add" screen for that person/family.

You could make the FTE full screen, in which case clicking on a person/family box would open that person/family's page in a new window/tab.

The Family Tree Explorer would no longer include the "Ancestors" view, the "Descendants" view, or the "List" view. Does anyone use these views?--Dallan 14:45, 31 October 2008 (EDT)

No, Dallan, I do not use the other views. I only use the Hour Glass view (both ancestors and Descendants) --Kristy 20:18, 9 November 2008 (EST)

Replacing trees with categories [29 November 2008]

Initially I was thinking that "user categories" (e.g., [[Category:Dallan/My tree]]) would be a "heavy" way to implement trees/tags, because they require you to edit the page in order to add a page to a tree/tag. But the more I think about it, it does have several advantages:

• Categories are already implemented in the software
• Implementing trees/tags with categories gives people one less thing to learn when learning WeRelate - it's one concept
• If you edit a page just to add a category, you can mark the edit as a minor edit so that page watchers are not notified
• Every page in an uploaded GEDCOM file could be assigned to a user-specified category automatically
• The "root" page of a tree could appear at the top of the category page by listing it as [[Category:Dallan/My tree|*]]
• Other pages could be listed in alphabetical order by surname in the category page by listing them as [[Category:Dallan/My tree|Doe, John 1869-1969]]
• We could make it easy to share any category page with someone else by mailing it to them, and inviting them to "watch" the category.
• We could extend watching a category page to include being notified whenever a page was added to or removed from the category. The notification email could include links to watch the newly-added pages or unwatch the removed pages.
• When someone watches a category page, we could add an option to "Watch all pages currently in this category"; selecting this option would cause all pages currently in the category to be added to their watchlist. This means that if someone watches your category (or any category) and also watches the pages in the category, they're notified when pages in the category are changed, and also when new pages added to the category. This is an improvement over the current approach to copying trees, where new pages do not get added to the copied tree.

Disadvantages:

• Others could remove pages from your category by removing the category tag (or similarly add pages to your category), but if you were watching the category (presumably you would be) you would be notified of the change, so this isn't much different than someone changing any other piece of information on the page.
• If we include text in the category listings for sorting (e.g., [[Category:Dallan/My tree|Doe, John 1869-1969]]), automatically-updating these texts when a name/date is changed on the page might prove difficult. I don't know how much of an issue this is.

If we go this route, then for users that have created multiple trees or who have uploaded GEDCOM files, I would have the system automatically edit their pages (including the merge targets of their pages) to add categories corresponding to their trees.

Thoughts? Would this capture the things that everyone is currently using trees for?--Dallan 14:45, 31 October 2008 (EDT)

If I'm correct, the category code for a person/family would be placed in the Personal/Family History field. So, if there are numerous people wanting the same page in their tree, wouldn't there be many lines of code for each person's personally preferred category term? How could we prevent the Personal/Family History field from getting horribly messy? Could there be a way to only see the categories that you entered - perhaps a specific category field that is filtered and only viewable by user? Maybe this would address the concern that category tags could be deleted by others.--JBS66 15:46, 31 October 2008 (EDT)

I don't use trees for anything, so I've been staying out of this discussion. But if this proposal would means we would see category links at the bottom each page for each user using this method, please don't do it. It would look messy and amateurish and would make the "useful" categories completely useless because they would get lost in the shuffle.--Amelia 19:41, 1 November 2008 (EDT)

Along the lines of category clutter, almost any directive can be overused. For example, because there are many comments about duplicated families, one is tempted to put a nomerge directive on all family pages that actually do match some other family by name. Now perhaps that isn't necessary if dates or children are different, but...? I suspect a Talk page cluttered with even 5 or 6 nomerge directives will be kind of annoying. Should directives be put in a different area with its own scrolling so only a small part of the screen be taken up by these directives unless the user wants to see them? Or if there is one or more of such non-content directives such as categories or nomerge, a link is added to the bottom where categories are now listed that takes you to a second page showing them in detail? --Jrich 09:26, 4 November 2008 (EST)

Let's see if it actually becomes a problem.--Dallan 00:24, 30 November 2008 (EST)

Replacing trees with tags [9 November 2008]

Ok, so I won't use categories to replace trees. Instead, how about if we create a new namespace, let's call it "Tag", that functions a lot like the category namespace, except that

• I can add and remove tags without editing the page
• Tags don't show up in the page text
• Tags are "user-specific", so if I created a tag called "mytag", the system would create a page titled "Tag:Dallan/mytag"
• Instead of a "Default" tree, the system will create a default tag called "Tag:Dallan/watchlist" that will contain everyone in your watchlist.
• Only you can add/remove your tags.
• If you watch another person's Tag page, you will get notified when they tag new pages with this tag; you will also have the option to watch all of the pages they have currently tagged with this tag.

Tags would be very much like trees. But you can watch them to get notified when new pages are added, and your watchlist functions like a default tag.

For the nomerge template, so far only 22 pages have the nomerge template on them. I'm not going to worry about this for awhile yet. If it gets to be a problem we can edit the template to take up less room (e.g., small font, fewer words, initially hidden).--Dallan 21:43, 6 November 2008 (EST)

If the "tags" are user specific, my other cousins will not be able to join in and add relatives to the group would they? Say they wanted to add a father to a person, that new person I would not know about as he would then be given a Tag:OtherUser/MyTag. Is this correct? Not to mention how would the Tags be affected by the merge process? --Kristy 20:30, 9 November 2008 (EST)

Is it broke? [29 November 2008]

I think I must have missed why this discussion is taking place.

• Has the tree concept in WeRelate suffered from usability?
• What are the flaws with the trees that is needing the concept to replaced with something else?
• Are there issues with the trees that could be fixed or improved upon instead of being ditched altogether?
• From a conservationist point of view, can't we save the trees? :)

--Ronni 22:47, 9 November 2008 (EST)

I agree of course!! Can't we save the trees??!! All this discussion about how to replace something that is already in place and working and making members that use it HAPPY, with something that may or may not "happily" replace it. "If it ain't broke, why fix it?" --Kristy 22:52, 9 November 2008 (EST)

I believe Dallan stated this at the beginning of the discussion: "Trees introduce a fair amount of complexity, not only in how easy the website is to use, but also in the back-end code." I read this to say that either trees place a heavy processing load on the system which may not scale well under heavy usage, or they complicate some or many of the changes being done or planned, or both.

The idea of tags sounds to me like it actually has the potential to be a much more general approach that provides effectively the same functionality. If, in addition, it has a lightweight implementation that places less demands on computer and programmer, then it sounds like it should be done before WeRelate is opened up to heavy usage.

--Jrich 01:01, 10 November 2008 (EST)

I read Dallan's statement too, and like you, was having to guess at what was being implied. I was looking for something a bit more specific. --Ronni 10:47, 10 November 2008 (EST)

Back-end code is a computer term, defined well here [1]. I don't feel that I really need the specifics on why it would be best for trees to be replaced. I trust Dallan to keep the technical specifics to a minimum, and simply state that it would best be modified. I think people are attached to the current trees, but there is an opportunity here to create something that will work as well, if not better than that. Of any specifics I want, it's a table of features, current and proposed. What do trees currently do that we want to keep? What features will tags (or other proposed solution) do? I want to be able to compare that side-by-side. I don't think we're really cutting down the trees here - we're just turning a weak pine into a stronger oak. I agree with Jrich, best to do this now while we're still in the Beta stages.--JBS66 11:11, 10 November 2008 (EST)

Kristy is needing to know why (while keeping the technical specifics to a minimum, I'm sure) the tree concept is being replaced. She's having a hard time (as others perhaps are) in seeing why something that is currently working for her, and apparently working great, is going to be done away with.

As for myself, I see the "tag method" being the most promising of all the proposals, but still need a bit more discussion in how they'll work. For instance:

• how would you tag a page?
• how would others pick up or adopt a tag?
• how would others see your tags?
• by looking at one of my pages, can I tell what tag has been assigned to it?
• can I bookmark pages within a certain tag?
• can I search just the pages within a certain tag?
• can I use the FTE to open up the pages with a certain tag?
• can I manipulate how the pages within a certain tag are presented, i.e., list their ancestors, descendants, etc like I can within the FTE?
• how does tagging pages work with future GEDCOM downloads?

There was discussion on moving the FTE to every person/family page:

• will this slow down the loading of pages?
• to make room for the FTE on pages, ads will be moved to the top of the page. I hate ads, but understand they are necessary. How will this effect the overall look and feel of the pages?

--Ronni 12:28, 10 November 2008 (EST)

Ronni, I don't have to see any ads, I use Mozilla Firefox browser, and have installed two add-ons, the "NoScript" and the "adblock plus" those two together keep the viewing of all pages nice and "clean"

I have Adblock plus as well. I guess I had it turned off to see what ads were showing up. Guess I forgot that I could turn it back on again. :| (Growing old is such an interesting experience). --Ronni 00:32, 11 November 2008 (EST)

Also, thank you for your list of questions. Putting that together was thoughtful, and I look forward to seeing what the answers will be! --Kristy 13:54, 10 November 2008 (EST)

Me too! :) --Ronni 00:32, 11 November 2008 (EST)

Here are the problems associated with trees that I think need to be addressed:

• Currently, if someone copies my tree, they get notified when I add someone new to the tree only if to add that person I've edited an existing page in the tree. If they want to be notified of changes to the newly-added person, they have to navigate to this newly-added page and watch it. The new page that I added doesn't get added to their tree automatically; nor does it get added to their watchlist automatically. I think we need an easier way for someone to say that they want to watch all pages in my tree and get notified whenever I add a new page.
• Suppose this other person that has copied my tree adds a relative. Now I have the same problem -- I get a notification that they've added someone by virtue of the fact that they've probably edited an existing page that I'm watching in order to add the new page. But if I want to watch the newly-added page, I need to click on the link in my change-notification email, figure out which person/family was just added, navigate to that page, and watch it. I think we need a way to "share" a tree between people, so that if anyone adds a page to a tree, everyone who has subscribed to the tree gets notified and automatically watches that page.
• Most people have only one tree, so the concept of multiple trees to manage is more than they want to learn about. Suppose someone who has been entering people manually (without GEDCOM upload) wants to share their tree. How do they do it? Currently they have to go through every page in their watchlist and make sure that it has been added to their "Default" tree. Then other people can copy their tree. For most people who only have one tree, this is overkill. Their watchlist should act in place of a "default" tree and they should be able to share their watchlist-tree. They shouldn't have to manage both their watchlist and also a "default" tree for sharing.

Here is my current thinking:

• how would you tag a page?

A "Tree" (or "Tag") would be tagged with a link at the top of the page, just where the "Tree" link is now.

• how would others pick up or adopt a tag?

I'm thinking that you could "share" a tree with someone else, which would allow them to "subscribe" to it. Subscribing causes them to watch all of the pages in the tree, and allows them to add new pages to the tree, which would then be added to your watchlist.

• how would others see your tags?

Other could see your trees/tags by visiting your user page.

• by looking at one of my pages, can I tell what tag has been assigned to it?

To see which trees/tags one of your pages is in, you would click on the "Tree/Tag" link at the top of the page, just like you do now.

• can I bookmark pages within a certain tag?
• can I bookmark pages within a certain tag?

If we make Trees/Tags a real namespace, then you could "bookmark" certain pages within the tag by editing the page and adding links to whatever pages you wanted. Otherwise I'm thinking that you could use your browser's bookmarks or del.icio.us or whatever for bookmarks.

• can I search just the pages within a certain tag?

Yes, just like you can search trees now

• can I use the FTE to open up the pages with a certain tag?

No, I want to remove the FTE as a separate application that you have to open to view a particular tree, and add it to every person and family page. This will make it much easier for people to view any page in the context of its relatives.

• can I manipulate how the pages within a certain tag are presented, i.e., list their ancestors, descendants, etc like I can within the FTE?

Do people really use the list sorting functions within the FTE? I'd like to remove this functionality if it's not used all that much. It could be added back into a desktop genealogy client that synchronized its data with WeRelate - that's where I think it ultimately belongs.

• how does tagging pages work with future GEDCOM downloads?

You would export all pages in a particular Tree/Tag.

There was discussion on moving the FTE to every person/family page:

• will this slow down the loading of pages?

It shouldn't slow down the initial load - the FTE would paint itself after the rest of the page had already loaded.

• to make room for the FTE on pages, ads will be moved to the top of the page. I hate ads, but understand they are necessary. How will this effect the overall look and feel of the pages?

Well, ads bring necessary income to WeRelate. Since we don't charge a subscription fee and hosting a website of this size isn't free, I don't see how we could survive without ads. I think being able to see 3-4 generations at once on every person/family page, and being able to click on an empty box in the tree to add a new husband/wife/child, will be worth it.

--Dallan 00:24, 30 November 2008 (EST)

A tree is not a tree [28 January 2009]

If I were allowed to upload my whole PAF database in a single GEDCOM, I would not be uploading a tree, but a small galaxy. I use that word because of the analogy. I have some 20 000 persons in there, and the largest cluster of related persons takes about 80 % of that, that's 16 000 persons. It's not a tree, since there is no single root person. It's a cloud, or a web, if you wish to see it that way. The other clusters in this galaxy are way smaller, but they too are probably more cloud like, meaning that they're mixtures of pedigrees and descendant trees.

I'm writing this, because to me it makes no sense to load the contents of this GEDCOM in an on-line application. I can load it in PAF, and browse through it in any way I want, off-line. That's my little galaxy.

I see WeRelate.org as a way to connect my little galaxy to other people's galaxies, and thus create a super cluster. And when I visit the site to start exploring that, I need a piece of on-line software that helps me explore the whole large galaxy. In other words, I want it to follow all the links that were created by our collective work of uploading and merging, not just the 'little galaxy' that I uploaded myself. I can explore that one already.

In order to make this work, I would like to see an on-line application that can visualize the local neighbourhoods of special bookmarked persons. I would bookmark my beloved father for that purpose, and a couple of my oldest ancestors, and if everyone does the same for his or her contributions, we have loads of tracks to explore.

I use the term local neighbourhood, because a Flash or any other application runs best when you limit the amount of data that it has to load in memory, like the current FTE seems to be doing. When you start the new explorer, it will load people related to your starting point, following every direction it can take, i.e. parents, children, partners, maybe even witnesses, as far as reasonable possible within memory limits. When you reach the edge of this local neighbourhood, you can load a new one using your current location in the galaxy as a new starting point.

When you do things this way, there is no need to add persons to trees, nor to tag anyone, except for the tagging that you already use to keep track of items that originate in a particular GEDCOM.

I hope I'm not too far out with this. IMO, it's just a better technical translation of the Pando concept.--Enno 15:52, 27 January 2009 (EST)

What you may be asking for is the ability to start the FTE on any page, starting with that page and going out a selectable-number of generations. This is what I envision as the future of the FTE. Once we have this, the concept of a tree is used primarily as a way to specify which set of pages you want to include in a GEDCOM export, and for relatives to be able to "watch" an entire set of your pages at once. (Actually, a current problem with the FTE is that it does download the entire set of page titles in a tree up-front, which doesn't work very well for large trees. The new FTE won't have this limitation since it won't try to download an entire tree - just a neighborhood.)--Dallan 15:20, 28 January 2009 (EST)

Right, that's what I mean. You could use something like the pedigree viewer on the FamilySearch Labs page, or whatever viewer is used on new familysearch. Bookmarks can then be added to direct visitors to the key persons in a tree.--Enno 17:58, 28 January 2009 (EST)