Add a new view, the "Slippy Tree"

[faceless2]

I'd originally worked this up and tested it at https://apps.wikitree.com/apps/bremford24/tree/, but as suggested after posting to the WT-Apps group, I've now integrated it with the wikitree-dynamic-tree and this version is at https://apps.wikitree.com/apps/bremford24/test/

Some key features which I hope will make it a worthwhile merge.

• It's nicer on mobile than the current offerings, due mainly I think to scrolling with overview:scroll and a scrollpane, rather than animating the transform() property on the SVG. Trackpad pan/zoom on macOS and pinch-zoom and drag-scroll are on iOS are tested, Android/Windows are not yet tested - feedback welcome before or after merge.
• Any tree node can be expanded up or down, so you can view multiple lines at once, and when this gets too complex the tree can be pruned to a specific branch.
• Confidence of connections between people is shown by the link style, with thicker links being more confident.
• I'm now showing in which directions the tree can be expanded by "fading" lines from each profile - so you can see if a profile has unloaded parents, children or spouses (this was not in the original prototype)
• the current view is stored in the URL for easy sharing (also not in the original prototype)

I have more plans for this and expect to make more PRs with improvements in the future, but believe what's here now is already useful and would be good to get it into the core if possible.

EDIT: If it helps, here is a tree showing multiple intermarriage between generations and here is one showing DNA confirmed, confident, normal and uncertain relationship levels. These links demonstrate the "easy sharing" aspect I mentioned above

[kayveedw]

It's working well for me with Chrome on Windows and Android

[faceless2]

I appreciate this is a big checkin and I'm new around here, so lots to review - if there's anything I can do to help that along please let me know. Things I've tried to consider:

• all styles are either prefixed with .slippy-tree-view, or where I have to style an ancestor I'm using :has(.slippy-tree-view), so styles will only ever apply when this view is selected
• Nothing changed on any element outside view-container, including window and document. On view-container itself a listener is added which is removed on close(), and no attributes or styles are set on that element.
• close() is aware that the View will persist even if it's not active; it removes all state, so no internal references remain to people records, DOM elements etc created in init().
• Any async events that fire check to see if the view is still the current view, and play nicely if not.
• JS is entirely in two classes - no global variables, etc are used.
• I'm setting a hash-parameter in the URL, but clearing it in close()
• There is a help dialog describing what it does

I've been swapping back and forth between this and the the other views to check that's all OK, and I've also checked and confirmed the stylesheet I'm using will work equally well in the main tree view under https://www.wikitree.com/apps.

[bcaseyrls]

Nicely done. I like the way you've embedded data into the various elements (relationship confidence, etc). It runs smoothly for me and plays well with the other views. I have a few small comments.

Viewing on my computer with a touch mouse was a little awkward. The mouse doesn't do a pinch for zoom like a touch pad. Doing a scrolling motion would do a zoom the first time and then stick at that zoom level. Other swiping just moved the frame around. I was unable to change the zoom with any action I could find on the mouse and had to reload. The zoom/scroll worked wonderfully on my laptops touchpad. I'm not sure if there's an easy solution to the mixed interface devices. Some ideas:

• On a mouse use click+drag to move and scroll to zoom in/out.
• Add +/- zoom icons (and actions) to the corner so you can click to zoom (and don't zoom on mouse scroll)
• Have some sort of zoom/view reset icon/action I really like the action as it works now for the right devices, so it's not worth breaking that. Any sort of fallback for the scrolling mouse might be enough.

It might be worth adding an "X" or something in the corner of the info/help pop-up. I realized after clicking around that it goes away if you click anywhere on it. But on other pages I've had such things close if you click off the pop-up. Putting a target in the box, even if clicking anywhere closes things, might avoid some confusion.

The code has a bunch of writes to console, which are currently turned on/off by DEBUG set based on whether the window is undefined. I suggest replacing these if (DEBUG) lines with condLog(). That function, defined in tree.js, writes to the console log based on a global debugLoggingOn. That's set to false in index.html but can be turned on to enable the logging for development. This would keep the setting out of the individual slippy view. Alternatively, you could set your DEBUG flag based on the deubgLoggingOn value and leave all your ifs as is.

Just some thoughts; I don't think anything above should prevent slippy-tree from being added to the main app.

[faceless2]

Thanks Brian, that's very useful feedback, especially on the mousewheel. I found a mouse and you're quite correct.

1. Scrolling with a mouse wheel should now be fixed - I've now tested with a trackpad and mouse on the same machine, and although distinguishing the two (as I suspect you know) is guesswork, that guess is a) largely working and b) resets after a second, so you can swap between the two. It's working fairly well here now, but I'd welcome your feedback either way of course.

2. Fair enough on the close button. I've added one as a visual hint to click on the window to close.

3. I've added keyboard navigation too; good for accessibilty, and it's faster to get around.

4. the DEBUG you found was for me testing layout locally in node; it's always off. However there are were some other console.log() messages that were called, which I figured I could get away with because most of the other views do it too :-) Now disabled depending on debugLoggingOn as you suggest.

[bcaseyrls]

I'm afraid the keyboard navigation you added has broken the form that lets one type in a new starting WikiTree ID. If I go to the "ID" input field and try to type in "Smith-1" or whatever, the hyphen triggers a zoom action and never appears in the input field. Keystroke capture needs to be restricted to when the tree view has focus or something similar.

Keyboard navigation in general is a great idea if we can have it not conflict with the rest of the page. I recommend adding notes to what keys do which actions to your pop-up help.

The mouse scrolling/zooming is still not working well for me. I can zoom in. Then when I try to zoom out it scrolls. Nothing I did obviously got the zoom back, including pausing. Eventually the scrolling stopped and it zoomed out. Then it scrolled again without letting me zoom in. Navigating with my mouse was almost impossible because of the erratic jumps between scrolling and zooming. Click to drag was reliable.

I'll note that I'm using an Apple "Magic Mouse" which is sort of in between a scrolling mouse and a track pad. It supports gestures and such, but I don't know how it detects by browsers.

I wonder if it would make sense to have the scroll vs zoom for these mouse events be a toggle setting instead of something just detected/guessed by the JavaScript.

[faceless2]

Thanks Brian, apologies for that keylistener - silly mistake and should have spotted that on the input. Now fixed.

The Apple "Magic Mouse" is an oddity, apparently. I've ordered one to test with, will update this issue when I have more info. Appreciate your continued feedback, thanks.

[faceless2]

@bcaseyrls I've finally tested with a magic mouse and come to the same conclusion as you; a user-selectable setting is required. This setting can be set on the help dialog if a mouse is detected on the system (meaning it won't appear on iPads etc), along with a note on keyboard navigation.

Hopefully that's the last blocker...

[faceless2]

I am also making use of URL params so please don't merge this until after https://github.com/wikitree/wikitree-dynamic-tree/pull/246, as I am also making use of URL params. Once 246 is in I will update this PR to reflect the new code. Code is now updated

[jmegenealogy]

There are a couple of SVG files that seem to be missing -- views/slippyTree/resources/trackpad.svg and views/slippyTree/resources/mouse.svg

But once that's sorted, I'll merge it :)

[faceless2]

Done!

[faceless2]

Thanks Jamie!