variants not for everyone visible after search query

[uklomp]

When I look for a sign on Signbank, and then click one of the results, the other results are visible in a row at the top of the page. This is very convenient, but my colleagues do not seem to have this. Is it correct that this might be related to certain rights? Or is something else going wrong? In the screenshot below, I looked for 'zoek' and clicked the second hit.

[susanodd]

Everybody should be able to see this. These are in a session variable and are passed around while you navigate to different pages. We normally call this the scroll bar. The main problem is that it ends up hidden behind other things on the page if the screen is too narrow. The Gloss Edit view is susceptible as it contains many things in the header, including the buttons for editing and space to show feedback messages if things fail.

Some pages do not show the search results. These are typically "helper" pages, like for adding a video or editing a lemma.

The scroll bar also takes time to "load". Sometimes it appears after some delay.

The "height" of the "header" is computed dynamically based on what is displayed. So sometimes this is incorrect.

@Woseseltops is the one with the most CSS experience. Hopefully he can take a look to see if there's something obvious that's wrong in the calculations of the dynamic height or width.

The code makes use of many different languages to generate the page. JQuery, javascript, HTML document entities, plus the Django markup for templates. The global "header" with all the datasets is also computed dynamically. The interactions of all these things kind of mismatch sometimes. (That it is visible sometimes and not other times.)

The specific code that "displays" the scroll bar is written in javascript using JQuery. All of the "items" are HTML elements that are generated dynamically. And this is supposed to "be inserted" into the labelled HTML element of the Django template. (So very many things can go wrong.)

[susanodd]

@Woseseltops can you take a glance at the header and "affixed" css code at the top of Gloss Detail view and see if something is messed up with the dynamic calculation of the "top" area that is supposed to be always at the top?

Another thing about it is that it's transparent. So if you have some of the panels open and scroll up, you can see them "behind" the buttons and scroll bar area.

I made an issue about this (#1224) because the code in this view is totally unreadable.

Is it possible to modify the setup of the "fixed" things on the page? (The upper area below the menu bar and pull downs.)

It would be best if the separate parts could be in separate templates, but the translation does not work anymore if this is done. I previously tried to put modals into separate files, but they do not get translated anymore. There are 1000 lines of Senses code inside one table row. And now annotated sentences have been added. Plus I'm working on #1169 which also adds even more code.

Please assist in the structure.

[Woseseltops]

Yesterday we discussed the theory of @susanodd that this is related to zooming in and out in the browser. I cannot confirm this, I keep seeing the 'scrollbar':

@uklomp , can you perhaps send over a screenshot of a colleague who does not see it? I even see it when logged out.

[susanodd]

It was the theory of @uklomp that this is related to zoom in zoom out. I have this problem too, but it's inconsistent when it happens. In your screenshot above, you can see the Query button is "behind" the scrollbar.

[Woseseltops]

I've also had a look at the dataset ribbon buttons, where I CAN reproduce the problem (as can be seen in my screenshot above).

The problem is that if you zoom in, all of the buttons no longer fit. I think there are 3 solutions:

• Make the buttons smaller when zoomed in, so they continue to fit... but the downside is that users who prefer larger font sizes don't get what they want
• Only show the first x buttons, and don't show the rest... but the downside is that you will never which datasets are active without zooming out
• When there isn't enough space for all dataset buttons, replace them with a button to a separate view where you can see the status of all datasets... but the downside is that this might take quite some work from our side

Preferences?

[susanodd]

@Woseseltops can you see if there is anything strange about the "layout structure" that is being filled in?

In general, there is the "base layout" that includes the "signbank bar with all the datasets" and the "menu" of all the "pulldown menus" (those are both defined in the two files that every template uses.

Then there are the "affixed" stuff below those that "stay" at the top. There are "dynamic calculations" of the height of these things that need to stay at the top.

Then "all the rest" is supposed to be below.

All the "scroll bar" and the "Query button" and the "Edit" buttons are in this "affix area between the Signbank header and the "contents of the page".

Can you see if those elements are messed up in any way?

There are dynamic elements like "where error messages should appear" and the "search results". But these also have Django "if" conditional directives. So it could be that they are sometimes "conditioned" away or that they are not included in the "height" of the elements if they are dynamic. So they end up behind other stuff.

Are you able to browse the elements in the layout and see if the "structure" is okay?

(I am not able to do this. There is too much code. I don't know how to fix this.)

[susanodd]

To make it more clear what I am talking about in the previous, I made a skeleton gloss detail view with lots of code removed in order for the "building blocks" of the "layout structure" and "what is being dynamically generated" to pop out more.

https://github.com/Signbank/Global-signbank/commit/1e18606b73ad930dcba15d761cc24846bc2c8b5a#diff-ec7976d8ab810e8e797d0d54b90d3751d59feaea1bdafab341bc27b1f1a64ec2

signbank/dictionary/templates/dictionary/gloss_skeleton.html

[susanodd]

My theory is that due to the dynamic generation of the Django template (all the Django-syntax with if-else guards on code blocks) plus the dynamic generation of the scrollbar (it's all javascript and dynamically generates the html elements) plus the dynamic calculation of the height of all the "header" (including the signbank bar, menu bar, plus scrollbar, plus Query button, plus "Edit" buttons) that the "Django template generation combined with browser interpretation" is not calculating things properly.

So I made a skeleton template by removing lots of code so that the "hangers" of the different "computed upon elements" are more visible. There is also a condition "messages" block (that Django generates to reserve space for user feedback) this is also in the "header area".

The Gloss View has too much stuff in the header. The Gloss Header is not calculated properly to allow resizing correctly. (For example, if things go beyond the border, it does not enlarge the vertical size of the "header area where all the stuff underneath the Signbank logo is.) In the code there are javascript calculations of the height of the elements. But whether it can correctly calculate this depends on the sequence in which the dynamic elements are generated.

[susanodd]

Help from @Woseseltops is asked in knowing how the template is actually generated wrt to all the different Django verses javascript verses jQuery versus ajax calls (which also put things in the display) versus the "affix" bar height (this is done at "ready" time. But what is "ready" time? When is the window "ready" if things are also being put there later by Ajax?

[susanodd]

A simple although perhaps aesthetically displeasing solution would be to make the entire page contents "horizontally scroll" so that all the Edit things that end up off the page to the right, the user could just scroll to the right to see them.

The idea would be that when things get too crowded, instead of letting Django/browser "knock elements that don't fit to the next line, e.g., the Profile and Logout" So the page would become a horizontal scroll and keep the things in the same row. Rather than making things taller with extra stuff.

[susanodd]

Example, this code in the header area:

{% if request.GET.warning %}
<div class="alert alert-warning">{{request.GET.warning}}</div>
{% endif %}

This is empty when the Gloss Detail template is being generated, so it's height is not known.

Likewise for this element:

    <div id="searchresults" class='navbar' style="overflow-y:hidden;background-color:white;border:0;box-sizing:content-box; z-index: 50;">
        {% if request.session.search_results %}{# See if search_results in sessions is empty #}

        <div id="results-inline" class="btn-group" role="group" aria-label="search results" style="white-space:nowrap;background-color:white;">
        </div>
        {% endif %}
    </div>

[uklomp]

@Woseseltops here's a screenshot of our colleague who doesn't see it

and here's one of a colleague who sees it but cannot click it because of the datasets underneath

[susanodd]

I'm working on this at the moment. I revised the "RU logo" at the very right side, since for me this overlaps the rest of the bar. That didn't solve it because there are too many datasets. So I revised the datasets to only show "datasets the user has explicit view permission for" . (This mimics the user Profile. There you see the datasets you can view.) So you will still see that the selected ones are white, but the (viewable) not selected ones are grey.)

The code for the menu bar computes "viewable datasets" but between then and now, the way the permissions are computed has changed. (So basically super users and staff will not see all the datasets anymore)

I had to do this because otherwise the signbank bar is too wide. That was causing things to overlap.

[susanodd]

Yes, that second one, that was happening to me when I attempted to make the display of the datasets a different size. All of the dataset links were in the main page area, hidden behind it, instead.

In the w3schools website, that they are displayed there can have to do with the flex display not being supported by the browser. So that may be why it goes wrong for the colleague.

[susanodd]

Too good to be true. Although it works well on Safari on a small laptop, Firefox is still troublesome. On Firefox, it goes wrong when you click on the "browser window button that toggles between full screen and whatever you have it set to". It's necessary to redraw the screen in this case.

This branch is on signban-dev now.

Please have the colleagues try it out, @uklomp

[susanodd]

This is deployed on signbank.

Let op: It may be necessary to reload your pages a number of times. For myself, it kept using the old css file. (The browser is lazy and does not reload unless you force it to.)

[susanodd]

[IMPLEMENTATION DETAIL, IGNORE EXCEPT FOR SUSAN]

I revised this for the new (revised) views for Batch Edit and for Split Up Senses. Both are in pull requests.

Although, the Split Senses has more fixes in it. I didn't feel like making all the same updates in both branches. (It's to do with Query View and the modular searching of parameters. There is some overlap in the display of fields in the results, to do with wanting the "normal" fields - shown in Gloss List View - versus the "extra" fields - other fields in the query. At the moment, there is some overlap in the sets of fields displayed. (SO for example, the toggles in Query View overlap sometimes in the different categories. These need to be exclusive. If a field appears in more than one category, then the toggling doesn't work properly. BUG.)

I revised for this issue the "handling and passing around" of query parameters (used in displaying the search results bar. So revisions to the query inside of the new views, Batch Edit and Split Up Senses are also reflected in the query parameters and passed around between the views.

For the new views, the only thing that will "make disappear" the search result is if the search was on say, Handshapes, and the user then wants to do Batch Edit. (This doesn't work because the search should be on glosses.) Feedback is given about this and a button to the Search page to try again.

[uklomp]

It's working now for our colleague who didn't see this before. Thanks!