Need for mobile friendliness? 🤔

[MichalVasut]

Is there need for Dynamic Tree View to be mobile / touch friendly?

There are already some reported issues, whose origin is from using this on e. g. iPad ( https://github.com/wikitree/wikitree-dynamic-tree/issues/43)

There are 2 sorts of remedies

• easier ones
  • using css to make it look better
  • lock zooming of entire page instead of only SVG view
• more difficult ones
  • "smearing" of the rendered view ( https://github.com/wikitree/wikitree-dynamic-tree/issues/42) - not sure what's the issue here

[Clarke-11007]

I would like it to be mobile friendly

Can you explain what you mean by lock zooming of whole page?

I’ve seen the render problem myself. The thing for me that’s more annoying is when I’ve scrolled down and the go button has gone off the top of the page.. sometimes I can’t get back up again , it just wants to zoom in or out or pan the SVG

Is that the zoom lock issue you're referring to?

On Sun, Oct 16, 2022 at 1:28 PM Michal Vašut @.***> wrote:

Is there need for Dynamic Tree View to be mobile / touch friendly?

There are already some reported issues, whose origin is from using this on e. g. iPad ( #43 https://github.com/wikitree/wikitree-dynamic-tree/issues/43)

There are 2 sorts of remedies

• easier ones
  • using css to make it look better
  • lock zooming of entire page instead of only SVG view
• more difficult ones
  • "smearing" of the rendered view ( #42 https://github.com/wikitree/wikitree-dynamic-tree/issues/42) - not sure what's the issue here

— Reply to this email directly, view it on GitHub https://github.com/wikitree/wikitree-dynamic-tree/issues/57, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3JDGBXSO2HS2CDHUJWL363WDQ3NBANCNFSM6AAAAAARGNZTDE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[MichalVasut]

I’ve scrolled down and the go button has gone off the top of the page. sometimes I can’t get back up again.

Nope, thats not it, but that's another issue - IMHO solvable by button that will stay at fixed position and allows you to get back or probably some better solution.

The zoom lock, I've talk about is described here How to Disable Zoom on a Mobile Web Page With HTML and CSS. The problem is that when you zoom the view itself, the rest of the page should stay untouched (100% zoom every time), but it zooms in and out as well - and maybe also causing the problem described by you.

[Clarke-11007]

Ah - OK - so the Zoom Lock could lock the outside part of the app (top piece, including the GO button), so they don't zoom in or out, but the SVG itself could still zoom and pan as it currently does - is that correct? That's definitely something that would be good to have!

I thought of another solution - perhaps we could post this as an issue or feature request for the wrapper / core index - that would address my disappearing GO button issue.

• I'm sure I've seen somewhere CSS that will make a
  visible or not visible, based on the scrolling position of the page. (not sure where at the moment, because it was one of those things you watch and think, that's cool, not sure when I'd ever need it ... well , now I need it)
• IF we made a
  that had a fixed position to the top right corner - but was only visible when the top portion (GO button and friends) have scrolled out of sight
• and INSIDE said
  was simple an arrow pointing upwards, which, when clicked upon, takes you back to the top of the webpage. (Perhaps via a #top link that could be hidden in the WikiTree logo)

This could be useful whether on mobile or not for the cases of views that have the potential to be super tall or wide, like the Fan Chart, or even the Ahnentafel Ancestor listing (though that behaves itself much better than the unruly FanChart!)

Thoughts?

On Mon, Oct 17, 2022 at 12:36 AM Michal Vašut @.***> wrote:

I’ve scrolled down and the go button has gone off the top of the page. sometimes I can’t get back up again.

Nope, thats not it, but that's another issue - IMHO solvable by button that will stay at fixed position and allows you to get back or probably some better solution.

The zoom lock, I've talk about is described here How to Disable Zoom on a Mobile Web Page With HTML and CSS https://www.w3docs.com/snippets/css/how-to-disable-zoom-on-a-mobile-web-page-using-html-and-css.html. The problem is that when you zoom the view itself, the rest of the page should stay untouched (100% zoom every time), but it zooms in and out as well - and maybe also causing the problem described by you.

— Reply to this email directly, view it on GitHub https://github.com/wikitree/wikitree-dynamic-tree/issues/57#issuecomment-1280275518, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3JDGBQWWEG2V6Q52HUFEMTWDTJU5ANCNFSM6AAAAAARGNZTDE . You are receiving this because you commented.Message ID: @.***>

[MichalVasut]

so the Zoom Lock could lock the outside part of the app

Yes, sir, exactly what I thought.

The thing with the button to allow scrolling upwards should be possible only using css - https://levelup.gitconnected.com/how-to-implement-scroll-to-top-with-only-css-ae27cb9d4678

Or another way with little bit of JS and rest in css.

[MichalVasut]

Btw, I've already thought about mobile friendly restyling, but waiting for opinions and thoughts of others.

[bcaseyrls]

Lots of WikiTree users are on mobile devices of some sort or another. While recognizing that some views may not be comfortable to use on a small screen, we definitely want to strive for the application as a whole to work for mobile/touch devices.

Along those lines, we should be giving some thought to accessibility. This is outside my area of expertise, but is something I think about frequently. We should to our best to make sure the dynamic tree application follows as many accessibility recommendations as we can.

[MichalVasut]

Okay, I'll do this, but I would like to confirm the solution of More descriptive View selections #81 issue - it's related and it would be nice to do together.

[MichalVasut]

I still have this in mind, respectively when I'm using web apps or android apps, I'm noticing the design and solutions of the "issues" / task that needs to be done in the Dynamic Views. There are few of them that are common for all (or most of) views and could be unified :

• search per wikitree ID
• select view
• view settings
• info / warning / error message

There already exist some solutions, but are either inconsistent or not very friendly on small screens.

Currently I don't have much time to start anything, but I thing the Hacktoberfest would be great opportunity (even the weather would be more favorable for coding 🙂).

What interest me now is the necessity to have WikiTree header on Dynamic Views / Apps page?

At large screens, this isn't really an issue, but at small screen, every pixel is important. At the same time that header with menu and search form isn't really necessary here for the function of Dynamic Views. Currently it takes quarter of the screen. With View search more than half of the screen = for the actual View (the important part) stays less than half of the screen. 😢

[bcaseyrls]

That's a good point. There are probably ways we can streamline the page, at least for mobile users, while still keeping them "in" WikiTree. I've put an item into our work queue to look at ideas. Since the tree view app is embedded into the WikiTree page, I'm not sure how much this project can do directly. Updates will require changes to the surrounding page. But we can certainly discuss possible solutions here.

I feel like the search form can probably go. It's present on all of the other WikiTree pages, but not necessary here. I think we'll need some sort of logo and link to the home page, but maybe it can be smaller for mobile devices. I'm ambivalent about the menus... I think users get used to them for navigating, but maybe streamlining them in some way for this one page makes sense. Should we reconsider font sizes for the tree app's form elements? Other thoughts?

[MichalVasut]

Since the tree view app is embedded into the WikiTree page, I'm not sure how much this project can do directly.

Can you expand more on this?

I would expect that there is some kind of view (php logic loading data / verifying user/ binding to HTML template /...) with html template (where those data are injected). And the view is bound to some endpoint (URL & HTTP method) so changing the static part (= template = which basically is dynamic views) would be piece of cake... 🤔

[MichalVasut]

As for screen space, I've probably found useful solution at FamilySearch. There is probably no need to do anything at the main WT page, it'll just expand and overlay the content.

https://github.com/wikitree/wikitree-dynamic-tree/assets/20949562/8738e79a-44ba-4925-b002-5248ced31917

It's probably done differently there (I haven't studied the code yet), but in principle, it could work the way I've described.

[bcaseyrls]

We want the "Apps" views to be part of the WikiTree site. So at

https://www.wikitree.com/apps/

we are not just viewing the index.html page from the wikitree-dynamic-tree repo. It's a page built by the WikiTree system (using templates, user data, etc) that in particular includes the header menus.

I agree that the WikiTree header (in particular the search boxes) take up a lot of screen space, especially in a mobile device. Maybe we can adjust to use a custom header that eliminates that, or hides it until an icon is clicked like in your example. We'll have to try some things out.