Clever NavBar for Sutta Central

Meta dev
1

Bhante @Sujato,

I was sooooo surprised and happy to have found your comment on my video.

Originally, I wanted to share it with you here via Discourse but later my priorities changed. It is also great to hear that you keep on improving the UI.

I have another feedback to share. It is a feature that I am using on my website. I call it a Clever Navbar.

https://www.pandita.cz/

Here in this video I explain how it works.

This „Clever Navbar“ is actually my idea. I am a little bit of a front-end devoloper. It is just 20 lines of code. I you decided to use it, your developers should be able to find the code on my Pandita.cz website. They will know how to find there.

Borek

P.S. I have also used your translations of and translated your suttas to the Czech language. The audio version is on YouTube already. It is just cool.

2

Ajahn,

I have a few more notes. When I was creating my website I was researching UI a lot. You are probably aware of some of these features but I will mention them. Perhaps it will help.

  • usually 63-75 characters are recommended per line
  • eventually I decided to use black font on white background
  • At the end of each line, the eyes of the user are moving from right to left, they have to find the new line below. Therefore, I am using a grey area on both of the sides. I think that it helps with this process. Actually, any PDF document in my PC browser is displayed in a similar way: black font on white background with a grey area on both of the sides.

All my best for your work,

Dalibor

3

Hi Borek,

Thanks, that’s nifty. Little details like this are always harder than they look! I’m still not happy with the implementation on SC: previously it was too sensitive, now I think it’s too insensitive.

I tried out your implementation. It’s nice! I wonder if it would be better to add a time component? At the moment the nav bar disappears if you scroll up 250px. But sometimes you’re just scrolling gradually up. What if it were 250/1 second?

You’re most welcome to have a look at SC’s source code and see if you can improve it. TBH, I have tried tweaking the parameters and just can’t seem to get it right. So we kind of moved on.

The relevant file is here:

And PR is here:

Nice, thanks!

I deliberately made the default a little wider than this on SC. Why? Because when I see people using their computers, especially laptops, I often see then with multiple toolbars at the top and the bottom of the screen, and the actual website window taking maybe 2/3s of the screen height. Which on a 13" laptop is not much! Personally I get rid of everything except the narrowest toolbars at the top that I can.

Anyway, given that many users have only a few inches of vertical space available, I wanted to ensure that they could still have a reasonable chunk of text on screen. This is even more useful when there is root/translation line by line.

You can always narrow the window if you like!

Hmm, I’m not sure. I never really found it a problem, i’d like to see some studies on this.

1 Like
4

@sujato

Bhante,

I am so sorry not have replied sooner. I was not around SC Discuss & Discover and only now did I discover your response to my post.

This discovery of mine is even more surprising because you have replied the day I have posted. I feel so embarassed. I pretty sure I was checking the post for some time but I do not remember finding you reply here. But it was here, I can see it now. Sometimes, I am so clumsy.

I see you left a few notes for me. I will try to reply later.

Borek

1 Like
5

@sujato

As for the scroll, yes it could be changed. I understand, sometime people read and slowly they are scrolling up. In that case, they do not want the navbar to appear. Adding one more condition to the script (for example, we could delete the scroll change every second) would propably solve this problem.

A few months ago, I wrote a newer version of this clever navigation bar. It is quite easy to understand now. If your developers are interested, I would be happy if they decided to use it. It is available here.

As for the UI, I like reading black text on white background + have the side of the text in grey background. But that is just subjective. I am not aware of any studies supporting this design pattern. But it reminds me of MICROSOFT WORD and OPEN OFFICE. They do use it.

6

No worries, we are still here!

I do like this version, nice UI and concise code.

One thing am wondering, I have heard that sometimes these elements create a lot of processing overhead, as they are constantly listening for the position. Is this correct? Do you know the performance implications of your solution?

1 Like
7

Thank you Ajahn for you reply:)

As for the performance, I do not have much experience with it. I am still new to development so this is a question for a more senior developer.

But my guess would be that it should be ok. This is only vanilla javascript. The performance issues are usually caused by big images or using external libraries that the website is using.

I have also tried to test the speed of my website. I am using the new clever navbar code there.

[www.dalibor.tech](https://www.dalibor.tech)

The https://gtmetrix.com/ service has no problem with my website.

But https://pagespeed.web.dev is telling me that there is a problem on mobile. But it hard to say what the problem is. Propably not the “clever navbar” code.

8

It’s a tricky one to test, I saw an article on it some time ago, I’ll see if I can find it. Basically it won’t show as a problem with normal testing, but events are being constantly triggered. Maybe try examining it in the browser tools?

9

Just now I tested the script with console.time and console.timeEnd. This is where I have found the instructions.

This is the result that I see in the console.

default: 0.89697265625 ms

That is the additional burden of my clever navigation script.

What you have in your mind is propably this part.

Window.onscroll = function () {}

So yes, javascript is constantly listening for any change in scroll. But that is normal. Similirly, javascript is constantly listening for “click” events.

I think I understand. Sutta central is a big app and you do not want to place additional burden on it.

10

So I did some more testing here…

I measured how long does this it take to execute this code.

console.time();
window.onscroll = function () {
  console.log("code was executed");
  let currentScrollPos = window.pageYOffset;
  scroll_change = currentScrollPos - prevScrollPos;

  //changing acumulated_change
  if (scroll_change < 0) {
    negative_acumulated_change += scroll_change;
  } else {
    negative_acumulated_change = 0;
  }

  //functionality
  if (scroll_change > 0) {
    navbar.classList.add("hide-navbar");
    links.classList.remove("show-links");

    if (close) {
      close.classList.add("display-none");
    }
    open.classList.remove("display-none");
  }

  if (currentScrollPos < 100) {
    navbar.classList.remove("hide-navbar");
  }

  if (negative_acumulated_change < -250) {
    navbar.classList.remove("hide-navbar");
  }

  prevScrollPos = currentScrollPos;
};

console.timeEnd();

And this is the result I got in the console of Chrome. It would propably be a bit more in other browsers.
default: 0.0361328125 ms

But how many times does this get executed in a second? I will try to write another reply about this.

1 Like
11

While I was testing the code above, I added this line of the code in.

console.log("code was executed");

This actually helps me to know, how many times does the onscroll get triggered when I use the mouse to scroll. Usually, it is around 15 times.

So when I scroll, it takes 15 x 0,03 ms to execute the code. That is approx half a milisecond.

You originally asked about “constant listening”. Hopefully all this testing of mine helped.

I think that the real peformance issues are when the app is loaded into the browser. That can be an issues sometimes on mobile especially.

But once the code is in the browser, it is usually not a problem to execute it. This is definitelly the case for the “clever navbar”.

3 Likes
12

Hey thanks, that’s interesting. Of course, it’s already the case that the existing code is listening, so this is probably similar.

@HongDa would you like to have a look at this? I like the UX it offers, but the question is whether it is an improvement on what we already have.

2 Likes
13

Thanks @Borek
I will see if the ideas you provide can better improve the current navbar :pray:

2 Likes