Shall we refactor the header HTML for smoother responsiveness?

[Moneycito]

@sujato

A final bug: there is some nastiness that is doing terrible things to the Pali text pages. Look at eg pi/dn2. When you open the page it is fine. Then for some reason big white gaps appear in the text. Somehow from our critical apparatus a table is being generated that is invisible but messing up the text. Check up <span class=“var”> and <table class=“deets”>. I’ve never seen this before, so I guess something is interacting with your new code somehow. Probably a simple fix.

Just want to make a note here while I am looking at it. I did notice something like this yesterday, but as of today (after some changes) I no longer can duplicate the issue. It could be that I need more specific URL and steps to reproduce, so once I commit branch, please verify the problem is gone for me - thanks!

[sujato]

I have updated my local version from your branch. I got the error once, on /pi/mn4, but since then have not been able to duplicate it. Perhaps it was in my cache. It looks like we will have to just keep our eyes out.

Apart from that, the changes are looking good, the search box is perfect, the hamburger is great; even the menu feels smoother, or is that just because I’m on a different computer?

[sujato]

I’ve started to get the bug again, and have narrowed it down a little. It is definitely connected with <span class="var">. It appears in the heading for /pi/mn2. And it is activated by hover: just move your mouse over the heading and it appears.

[Moneycito]

@sujato

Apart from that, the changes are looking good, the search box is perfect, the hamburger is great; even the menu feels smoother, or is that just because I’m on a different computer?

Glad you like the changes. I find your mix of positive feedback and detailed testing in the quest for the best possible result to be a pleasant alternative to many I have worked for. You get the balance just right.

[Moneycito]

@sujato

The sidebar animation is nice, it slides out and back smoothly, fast to launch, slow to finish. One detail, though: it shows its shadow even when it is hidden, this would be better off gone.
Viewing at a normal-ish screen size, when I hit SUTTA the panel appears without animation. The dark background appears a little later, and it glitches unnaturally over the next/prev links (the round regions at the bottom of the text pages).
If, from a blank start, I hit Vinaya, it glitchily progresses down. Except sometimes it also appears fully-fledged, without scrolling. And sometimes it scrolls smoothly.
If I go from SUTTA to VINAYA, it scrolls down, and if I go from VINAYA to SUTTA it scrolls back up. Fine. But then if I am on VINAYA, close the menu, then open SUTTA, it leaps down to the place the VINAYA would have been and scrolls back from there.

I believe all of these issues are now fixed. Let me know if this is what you are looking for.

[sujato]

Well, thank you! I know how hard all this can be, so I always try to treat people who are helping me with respect.

[sujato]

This is looking much better, thanks.

There’s still some minor issues with the menu. I’ll mention the outstanding Issues I can see here. I am repeating a few from earlier, I’m not meaning to nag, just to keep everything in one place.

• When you freshly reload the page, the menu panels “leap down”, but subsequently they scroll down.
• The animation is improved, but it still feels sluggish, and not as smooth as it could be. It should have the same kind of acceleration as the sidebar.
• Both with the menu and the search box, the “return” animation should be just the same as the initial, again this is like the sidebar. Currently they “scroll” out and “leap” back.
• When the sidebar is extended and you open the menu, the sidebar darkness still kicks in a little later than the main page.
• Worse, various sidebar elements flash in and out when the menu is extended. Try opening the sidebar, clicking on the Metadata tab, and open the menu.
• Similar problems still show on the division/subdivision pages, the rows have uneven z-index.
• I still seem to be seeing a glitch in the next/prev links. It seems to me that maybe 500ms after opening the menu, the grey circular field fades to white then comes back, and when you close the menu, the same thing happens. But maybe this is just an optical illusion? In any case it is very subtle and not a big problem.

Not directly related:

There is a CSS error in the Vinaya menu. .pitaka h3 should have margin: 0 0 0 0.2em;

And a few minor issues with the header:

• There is a vertical alignment issue. The left group (hamburger, wheel, title) is aligned within itself, but slightly too high as compared with the rest of the header. They need to come down about 4px or so.
• The search icon needs to come left about 4 or 6px, and perhaps down 1px? But I know it is not easy to position this consistently across browsers. Anyway that is how it seems to me on Chrome/Ubuntu.
• We can lose the border-radius for the dongle.
• As mentioned earlier, the reappearance of the header when you scroll a page up is not sensitive enough: sometimes it appears, sometimes not.

[sujato]

And here’s another idea, more of an enhancement, for consideration of @Moneycito and @blake. We’ve always had some problem with the discoverability of the sidebar icon. I want it to be clear but unobtrusive.

I also want to use the sidebar to enforce a didactic policy on how the pages are used, rather than a purely user-driven design. I want to encourage a clean design, free of any clutter or temptation to click any links or do anything else. I think the basic experience of someone reading a sutta should be a peaceful one, where their attention is focused entirely on the text before them. At the end of the day, I am a Buddhist monk, so I get to use the word “should”!

However we need to make people aware that the sidebar exists. I am thinking, what about a popup when people first open a text page. Discourse make extensive use of these, on the principle that information is most effective when it is presented at the moment someone needs it.

So we make a popup that says something like:

To keep your reading experience as uncluttered as possible, we’ve packed away all the extra bits and pieces in a sidebar. You can activate it here → (Big arrow pointing to the sidebar). It has extra navigation, publication details, information about the texts, and more. Try it out and see.

What do you think?

[blake]

Sounds good to me. @Moneycito do you want to implement the jquery side of it, or should I?

[Moneycito]

I think it is a good idea to inform the user as well, but ideally this will be something that can be dismissed into oblivion with an “I got it” type button or something similar.

A couple of more subtle alternatives would be:

1. The first couple of times the user lands on a text page, we could use some of the animations found here: http://daneden.github.io/animate.css/ such as the “Bounce” or “Pulse” for the sidebar dongle and the “Shake” for the actual sidebar (just shake it slightly while it is closed to give the user a glimpse of it, while simultaneously “pulsing” the dongle.

2. The first couple of times the user lands on a text page, start with the sidebar open (or partly open), but immediately close it (while maybe fading in the dongle at the same time).

I can do the JavaScript for whichever method you choose. One question on that though would be: Do you have a method (and code) you are using for keeping state information for things like this? (cookies, user pref. into somewhere, etc.) Ideally, we do not want to show the pop-up or visual effects every time I would imagine.

[sujato]

I should have mentioned, yes, a “Got it” button to send it away.

We previously used something like you suggested—start with the sidebar out, to be exact—but it got dropped along the way.

I think the problem with those more subtle approaches is that they are not clear and unambiguous. Someone opens a text page, let us assume someone with a low level of understanding of websites and so on. Just getting to a text page is a triumph, and they don’t really understand how it happened. Then, at the moment they are checking to see whether they are in fact at the place they thought they were—which, of course, they might not be—then some random animation happens, something confusing out of the corner of their eye. They ignore it (having to make a cognitive effort to do so) as it is not their concern: identifying the fact that they are on the correct text page is. If at some point later on they want to, say check the publication details, or navigate somewhere, or use a dictionary, there is nothing in their minds to connect this with the obscure and inexplicable wiggle that they saw once, many moons ago.

To put it more succinctly: if someone doesn’t recognize what a hamburger icon is, they won’t understand what an animation is for either.

Moreover, we also don’t get an unambiguous message about what the user is doing. Did they see the wiggle? Did they know what it means? Did they go on to use the sidebar?

If they have a brief, clear popup to read, then they take the act to dismiss it, we can, I think, be somewhat confident that they have read it and have at least some idea what the sidebar is. At the very least, they will surely recognize what the popup is and what it is for.

Anyway, this is just my thoughts on the matter.

[blake]

Well the state thing is a bit… disorganized. Some of the javascript code I wrote when I was completely new to javascript and webprogramming, so there is some state code which should be ignored.

The technique I have settled on is using localStorage. Within the javascript we use the namespace ‘sc’, so the palilookup is ‘sc.piLookup’. It has an attribute ‘lang’ for the selected lookup lang, which is ‘sc.piLookup.lang’, that can then be persisted and retrieved like this:

localStorage.setItem('sc.piLookup.lang', sc.piLookup.lang)

sc.piLookup.lang = localStorage.getItem('sc.piLookup.lang')

Using the full object path as the key eliminates the possibility of collisions.

We do not use cookies. To improve edge-caching we always deliver identical content for a given URL. Customizing content server-side based on user cookies would violate that. So… we just use localStorage to persist stuff across sessions, and anything which changes on a page based on user behavior/preferences happens in the browser.

[Moneycito]

@sujato

When you freshly reload the page, the menu panels “leap down”, but subsequently they scroll down.

This should be fixed in the latest commit.

[Moneycito]

@sujato

The animation is improved, but it still feels sluggish, and not as smooth as it could be. It should have the same kind of acceleration as the sidebar.

This should be fixed in the latest commit or at least improved. I refactored the code so that using the z-index is no longer required to ‘hide’ the shadow box (gray area). Instead I am using visibility. This give a cleaner transition and also allowed me to eliminate the transition effect that was being applied to the z-index that I think was causing a lot of the weird behavior that you were seeing (I have to be honest, I could not see a lot of the issues myself, but you have a very keen eye or maybe a slower computer

[Moneycito]

@sujato

Both with the menu and the search box, the “return” animation should be just the same as the initial, again this is like the sidebar. Currently they “scroll” out and “leap” back.
When the sidebar is extended and you open the menu, the sidebar darkness still kicks in a little later than the main page.

These should both be fixed in the latest commit.

[Moneycito]

@sujato

I still seem to be seeing a glitch in the next/prev links. It seems to me that maybe 500ms after opening the menu, the grey circular field fades to white then comes back, and when you close the menu, the same thing happens. But maybe this is just an optical illusion? In any case it is very subtle and not a big problem.

I think this issue might be gone now as well. I do have a confession to make though: I added in the very, very light gray background to the next and prev buttons that might be causing this ‘optical illusion’ that you are seeing. I forgot about it, but originally added it in as I could not easily determine where the next and prev buttons were. Let me know if you like it or want me to remove it.

[Moneycito]

@sujato

As mentioned earlier, the reappearance of the header when you scroll a page up is not sensitive enough: sometimes it appears, sometimes not.

This is fixed in the latest commit.

[Moneycito]

@sujato

There is a vertical alignment issue. The left group (hamburger, wheel, title) is aligned within itself, but slightly too high as compared with the rest of the header. They need to come down about 4px or so.
The search icon needs to come left about 4 or 6px, and perhaps down 1px? But I know it is not easy to position this consistently across browsers. Anyway that is how it seems to me on Chrome/Ubuntu.

I did not change anything in regards to these items. Things are aligned on my local, but I think that might because I have not been able to get the non-free fonts to show up yet (for some reason - will be working with Blake to get that resolved). Once I have the fonts, I will line things up and see if I can get it looking good with both of the fonts.

[sujato]

Maybe a bit of both. I’ve used two computers for testing, a zenbook ux31a and a desktop with a recent i5 running a 4k screen. And I look pretty carefully…

But these issues seem to be solved.

[sujato]

@Moneycito

that might because I have not been able to get the non-free fonts to show up yet

Yes, that’ll do it. One of the benefits of controlling your fonts via @font-face.