The latest pedigree viewer on FamilySearchLabs.org solves the manageability problem by compressing the tree nodes vertically when whole subtrees are absent. This saves a lot of space and allows the user to more quickly navigate around the entire tree, but I see three weaknesses. First, the benefit is proportional to the sparseness of tree. The more you add, the worse it gets. Second, the connector lines from child to parents for all but the first few generations are usually skewed to the point of being visually non-functional. Third, the layout is entirely dependent on the data, so you have to adjust the layout every time you add or remove a node from the tree. With this approach there's little hope of users developing a reliable spatial mental model over time.
My idea was to have the right side of the tree auto-expand, or spread out, as you scroll from left to right. The result is that, no matter where you go in the tree, you have a pleasantly proportioned pedigree chart within the viewable area. The parent-child relationships are always perfectly arranged, just like a typical four-generation chart. I built a prototype and showed it to a number of non-technical people with varying experience in family history research, and they have all been extremely impressed with how comfortably it displays the data. I loaded my wife's GEDCOM file into it with around 500 individuals, and it was as easy to comprehend and navigate as if it only had 50. That's the point -- the quality of the viewing experience is independent of either the depth or sparseness of the tree. The only hard part is getting used to the "feel" of navigating around with the tree automatically spreading or compressing as you go. However, in my implementation it was very smooth, so it was pretty easy to get the hang of it.
There's some mildly fancy math behind this kind of experience since you're using a logarithmic transform to get from the tree's coordinate space to the viewer's coordinate space, but if someone like me could figure it out with a little trial and error, it can't be that hard.
I imagine that with some more complicated math you could pull off a similar experience for a descendency tree. In an ancestor tree, the relationship of one individual to another absolutely determines their relative positions in the coordinate space. This is because space is alloted for exactly two parents of every node (exceptions are handled by a secondary UI). For a descendency tree, you could get the same simplicity if you just allot a fixed amount of coordinate space for an individual's immediate children, regardless of how many children they actually have. If there's more, you cram them in tighter. If there's less, you spread them out. This should be okay, because the navigation experience allows the user to spread or compress the tree by simply dragging to the right or left, so they can always get to a point where what they want to see is visible.
I apologize if this approach is hard to visualize based on my description, but I promise -- it's pretty nifty when you see it. Any thoughts from the crowd?
