История изделия: нерациональное использование площади страницы

[alx]

При клике по серийному номеру изделия на главной странице открывается страница его истории, на которой сначала расположена таблица, отображающая протоколы, а за ней - собственно таблица истории. При этом одна строчка таблицы протоколов имеет такую высоту, что выходит за пределы видимой на экране части страницы (и это при 27-дюймовом мониторе!), так что требуется прокрутить контент страницы чтобы только ее увидеть:

А если протоколов будет несколько?

Это хорошо, что теперь на странице истории сразу дается ссылка на протокол, однако мне кажется, что открывшего историю пользователя в первую очередь будет интересовать таблица с записями, и только во вторую (или даже более позднюю) - протоколы. Поэтому я считаю, что таблица истории важнее таблицы протоколов, и стоило бы скомпоновать страницу таким образом, чтобы для просмотра таблицы истории, по возможности, не требовались дополнительные действия. Мне кажется, что при более рациональном использовании площади страницы вполне можно скомпоновать отображаемую информацию так, что она вся уместится на одном экране даже при наличии нескольких протоколов, и пользователю не потребуется использовать прокрутку контента.

И, наконец, я заметил, что синий текст ссылки на фоне фотоизображения довольно трудно читается (см. приложенный скриншот).

Учитывая сказанное выше, предлагаю ряд улучшений:

• перекомпоновать страницу истории таким образом, чтобы сначала на ней располагалась собственно таблица истории, а уже после нее - таблица протоколов (как дополнительные материалы);

• уменьшить высоту строк таблицы протоколов - сделать их хотя бы приблизительно такой же высоты, как и строки в таблице истории (размер изображенной во весь экран иконки по-моему не пропорционален важности информации, которую она несет пользователю);

• сделать фон строк таблицы протоколов не чисто прозрачным как сейчас, а светлым полупрозрачным, примерно как и у таблицы истории;

• добавить перед таблицей протокола какой-то заголовок, из которого пользователю было бы понятно, что далее перечислены ссылки на найденные протоколы (в имени файла может не быть слова "протокол").

• Добавить в ответы сервера поле Cache-Control, в котором указать браузеру на необходимость валидировать документы через If-None-Match при каждой загрузке страницы, как это и было задумано изначально.

[alx]

О, только сейчас заметил, что заголовок "Протоколы" перед таблицей уже есть. :) Но он написан черным по довольно темному месту фоновой картинки, из-за чего его трудно заметить.

Предлагаю сделать фон для надписи "Протоколы" более светлым.

[san]

Думаю что это баг)
Выглядеть оно должно так:

У меня так и выглядит)
Алексей, уточни пожалуйста в каком браузере ты воспроизвёл это

[alx]

Replying to san:

Алексей, уточни пожалуйста в каком браузере ты воспроизвёл это

Chromium
Version 90.0.4430.212 (Developer Build) built on Debian 10.9, running on Debian bullseye/sid (64-bit)

[san]

А может у тебя не обновился измененный файл css. Попробуй обновить страничку. Картинка на фоне, например, у тебя "старая".

[alx]

Replying to san:

А может у тебя не обновился измененный файл css.

Возможно. Ничего об этом не знаю. Как отличить старый файл от нового?

Попробуй обновить страничку.

Здесь же веб-интерфейс не "Single Page Application" (как в блоке 3U), когда файлы загружаются один раз и навсегда! При клике по серийному номеру страница и так каждый раз загружается заново. Если при загрузке страницы браузер не загружает какие-то обновленные файлы (а использует старые из кэша) - это баг.

Вот что грузит браузер при открытии истории:

Как видим, ни за файлом main.css, ни за jquery-ui.css браузер вообще не обращается, использует сохраненные версии из кэша. Судя по твоему предположению выше, это не то поведение, которое было задумано. Вероятно, в неправильной стратегии кеширования и заключается баг...

Картинка на фоне, например, у тебя "старая".

Да, я тоже заметил, что в другом браузере на странице аутентификации картинка фона другая...

[alx]

Посмотрел, что отдает сервер на запрос ​https://r2.adc-line.ru/base/css/main.css?random=@Environment.TickCount. В ответе сервера вообще отсутствует Cache-Control:

HTTP/1.1 200 OK
Date: Mon, 27 Feb 2023 07:43:40 GMT
Server: Apache/2.4.41 (Ubuntu)
Last-Modified: Tue, 24 Jan 2023 05:02:59 GMT
ETag: "5b86-5f2fb6df466c0-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 5777
Content-Type: text/css

Соответственно, браузер имеет право кешировать как хочет...

Предлагаю добавить в ответ сервера Cache-Control с указанием браузеру нужного поведения (в данном случае, как я догадываюсь, предполагалось, что браузер будет валидировать документ через If-None-Match?).

[san]

предполагалось, что браузер будет валидировать документ через If-None-Match?)

Ну да, а почему этот вариант не сработал?

[alx]

Replying to san:

предполагалось, что браузер будет валидировать документ через If-None-Match?)

Ну да, а почему этот вариант не сработал?

Вопрос не по адресу. Не я менеджер этого проекта. Я менеджер проекта MC-03. :)
Но если ты хочешь, чтобы я погадал... наверное потому что кто-то забыл сказать браузеру (путем указания Cache-Control) делать так, как предполагалось... А браузеры, как и я, телепатией не владеют... :)

[alx]

Кстати, после принудительной загрузки main.css с сервера вид страницы изменился на тот, который показан в comment:2.

[san]

А браузеры телепатией не владеют..

Ну вот, очередное разочарование)

Кстати, после принудительной загрузки main.css с сервера вид страницы изменился на тот, который показан в comment:2.

Т.е. предложения тикета теперь не актуальны?
Нужно только кэш починить.

[alx]

Replying to san:

Т.е. предложения тикета теперь не актуальны?

Три из четырех. Скорректировал предложения в описании тикета.