open-contracting / bi.dream.gov.ua Goto Github PK

На аркушах "Проєкти" та "Деталі проєктів" варто уніфікувати перелік фільтрів та змінити порядок фільтрів

Пропоную такий перелік та порядок фільтрів для обох аркушів

Статус проєкту
Тип проєкту
Характер проєкту
Орган управління
Ініціатор
Балансоутримувач
Тип органу управління
Тип ініціатора
Фінансуюча сторона
Джерело фінансування
Тип фінансування
Область
Район
Громада
Сектор
Підсектор
Код стратегічного рівня
Наявність тендерів

Зверніть увагу, що фільтр "Є контракти" тут перейменований у "Наявність тенедерів"

Якщо можливо, варто прибрати анімацію появи карти під час її завантаження. Це можливо виглядає цікаво один раз, але під час постійного користування дешбордом це починає трохи дратувати

Це заторкає всі сторінки, де використовується карта (Головний дешборд, Проєкти, Фінансування)

Для цього кодліста у нас є українські відповідники, але немає англійських

Для потреб Проєктного офісу (та наших власних - аби розуміти стан наповнення даних) маємо зробити візуалізацію наявності даних щодо проєктів / наповнення проєктів.

Для Проєктного офісу це важливо, бо тоді вони можуть прицільно працювати із громадами над наповненнями проєктів.

Є запит саме по Проектам - щоб було видно всю інформацію, яка зараз відображається на порталі. Тобто такі розділи як: Назва, Опис, Структура, Джерела фінансування, Технічне рішення, Документи, План ,Галерея. Це нам допоможе в подальшому аналізувати, як йде наповнення по громадам, ОВА тощо.

Ідея тут достатньо проста - визначити, які секції представляють для нас інтерес, і перевіряти для кожного проєкту, чи наявні дані у цій секції (інакше кажучи, чи ця секція не є порожньою).

Я вже робив подібний аналіз для себе, і це було у вигляді простої таблички, де для кожної визначеної секції міститься запис про доступність даних.

У цьому разі алгоритм був простий - скрипт проходив по кожному проєкту, заглядав у кожну визначену секцію і перевіряв 1) чи цей елемент is not null 2) чи його довжина > 0 (ця перевірка не потрібна, якщо дані структуровані правильно, тобто у них немає просто порожніх елементів).

Я також виводив загальний data availability index на підставі інформації про наповнення всі визначених секцій.

На додачу до цього ми також можемо зробити декілька візуалізацій, котрі представлятимуть стан наповнення даних по всіх проєктах. Наприклад, візуалізація, котра показує, яка частка проєктів має заповнені бюджети, фінанси, і т.д.

У своєму аналізі я орієнтувався на наступні секції проєктів:

• targets
• criteria
• requirements
• documents
• approaches
• items
• budget
• finance
• relatedProcesses
• additionalClassifications
• contractingProcesses

Що потрібно буде врахувати / додати:

• наявність зображень (це по суті documents певного типу) - запит від Проєктного офісу
• наявність закупівельних планів у контрактних процедурах (треба зрозуміти, як це ідентифікується в даних)

Можливо, якісь секції можна буде навпаки прибрати. Наприклад, criteria ніби мали б бути у всіх проєктів (але це варто уточнити)

У таблиці "Фінансування" у нас є показник "співфінансування". Отже, слід визначити, як цей показник рахувати

Співфінансування - це ситуація, коли один проєкт має декілька джерел фінансування (financingParty)

Якщо ми хочемо визначити просто наявність співфінансування на рівні проєкту, тоді ми перевіряємо, чи проєкт має більше ніж одне джерело фінансування

У нашому випадку радше йдеться не просто про наявність співфінансування, а про відсоток фінансування. І не на рівні проєкту, а на рівні фінансуючої сторони. В такому разі можемо діяти наступним чином

Для кожної фінансуючої сторони у проєкті розраховувати відсоток фінансування. Скажімо, якщо в проєкті є лише одна фінансуюча сторона, відсоток вінансування 100%. Якщо у проєкті дві фінансуючої сторони, можна уявити, що одна з них забезпечує 70% фінансування, інша - 30%.

Тобто тут, ми співвідносимо обсяг фінансування кожної окремої фінансуючої сторони із загальним обсягом фінансування проєкту. Таким чином ми отримаємо для кожного проєкту і кожної фінансуючої сторони у проєкті відсоток фінансування.

Але у фінальній таблиці нас все одно цікавіть навіть не це. Нас цікавить медіанний відсоток співфінансування проєктів для кожної фінансуючої сторони.

Тобто, для кожної фінансуючої сторони ми беремо всі проєкти, де є фінансування від неї. І дивимось, яким є медіанний відсоток фінансування цієї фінансуючої сторони для всіх цих проєктів.

В результаті ми хочемо / розраховуємо побачити, в який спосіб різні фінансуючі сторони беруть участь у проєктах? Наприклад, чи є такі, хто долучається до великої кількості проєктів, але має доволі малий відсоток співфінансування? Або чи є такі, хто долучається до малої кількості проєктів, але фінансує їх фактично повністю?

Чи це є зрозумілим? Чи це видається коректним?

Проєктний офіс звернув увагу на те, що змінився набір можливих значень для initiationType.

В першій версії у нас був такий набір кодів - replacement (Реконструкція / Модернізація), rehabilitation (Капітальний ремонт), construction (Нове будівництво), expansion (Поточний ремонт).

Зара в документації моделі даних я бачу лише три коди - rehabilitation (Реконструкція/Модернізація/Ремонт), construction (Нове будівництво), equipment (Постачання товарів і послуг).

Питання в тому, як найкраще працювати із цим на рівні BI. Особливо із врахуванням того, що команда розробки не планує backward migration, тобто старі коди / проєкти не будуть перекодовані на нові.

Наприклад, чи ми маємо на рівні BI перекодувати старі проєкти rehabilitation? Чи ми будемо застосовувати нові коди тільки з певного часу? Як бути з проєктами, котрі були першопочатково закодовані як replacement / expansion - чи можна очікувати, що вони отримають нові коди з часом? Чи вони так і лишаться зі старими кодами?

Користувачі вже декілька разів зауважували проблему із накладанням підписів на карті. Задокументую її тут, аби ми мали можливість проговорити можливі рішення (попередні наші обговорення не результували у якихось змінах до роботи із підписами).

• На карті України накладаються підписи для Києва та Київської області. Чи є можливість змістити їхні позиції (в технічних термінах, чи label / text має параметр offset)

• На рівні окремо взятої області теж можливе накладання підписів. У цьому разі offset (навіть якщо він є) не допоможе, оскільки за умови щільного розташування підписів зміщення / усунення накладання на одній позиції призведе до накладання підписів на іншій позиції. Чи має Qlik якісь інструменти для роботи із цим?

З моїх спостережень на рівні області ця проблема наразі помітно проявляється у Київській та Одеській областях, втім, за умов збільшення кількості проєктів з інших громад, ми можемо очікувати, що проблема з накладанням підписів буде відчуватися більш гостро і в інших областях.

Суто технічні варіанти підходу:

• Показувати підписи лише на певному рівні зуму. Це може з великою ймовірністю допомогти нам уникнути накладання підписів, однак це також означає, що на деяких представленнях підписів може і не бути. В такому разі потрібно буде показувати легенду (color scale), аби користувачі розуміли, як співвідносити відтінок кольору із числовим значенням

• Зменшити розмір підписів. Тут є очевидні ризики, що підписи можуть стати менш зручними для читання.

Можна розглядати варіанти рішення для накладання підписів на карті України та на карті обраної області окремо.

У таблиці "Деталі проєктів" у нас код проєкту є посиланням, котре веде на сторінку проєкту на основному порталі. Але наразі це посилання веде на англомовну сторінку проєкту. Ця ситуація виникла через те, що ми взяли за основу посилання саме на англомовну сторінку

Паттерн для англомовної сторінки https://dream.gov.ua/project/DREAM-UA-{code}/profile

Паттерн для україномовної сторінки https://dream.gov.ua/ua/project/DREAM-UA-{code}/profile

Якщо ми можемо зрозбити так, аби посилання конструювалося залежно від того, яка мова інтерфейсу обрана, то варто зробити так, аби з англомовної таблиці вело на англомовні сторінки, а з україномовної на україномовні.

Так звана "Картка органу управління" потрібна для того, аби представляти ключові показники щодо окремого (обраного користувачами зі списку) органу управління. Референсом щодо цього блоку слугує модуль "Картка організатора" у BI Prozorro.

Взаємодія з цією сторінкою починається з того, що користувачам потрібно обрати один орган управління зі списку всіх органів управління. Список має сенс сортувати, наприклад, за кількістю проєктів або ж за загальним орієнтовним бюджетом, аби на початку списку були органи управління, до котрих підвищений інтерес.

Ідеально було б зробити один орган управління обраним одразу через pre-select, але тут технічне питання, чи може у нас буде pre-select локальний (тобто для однієї сторінки, а не для всіх сторінок).

Для обраного органу управління (а також для будь-якої підпорядкованої організації, яку виберуть користувачі) ми показуємо:

• Кількість підпорядкованих організацій
• Кількість проєктів
• Загальний орієнтовний бюджет
• Підтверджене фінансування
• Фінансове покриття
• Кількість контрактних процедур
• Сума укладених контрактів

Частину цих показників, ймовірно, можна дати у форматі карток, а частину винести у візуалізації

З візуалізацій у цьому блоці є запит на:

• Кількість проєктів у розрізі статусів
• Кількість проєктів у розрізі регіонів

Також є запит на інформаційний блок, який би представляв для кожної організації

• Контактні дані
• Кількість користувачів

Щодо кількості користувачів, можливо, доведеться сформувати окремий запит до команди розробки, оскільки наразі у companies endpoint у нас є елемент persons, але для більшості організацій він може бути порожнім.

Основні фільтри у цьому випадку такі

• Орган управління
• Тип органу управління
• Регіон

У цьому блоці ми закладали

• Розподіл проєктів за датою реєстрації (histogram) визначити binwidth (7 днів, місяць)
• Кількість проєктів за статусом (bar chart, treemap, donut)
• Кількість проєктів за типом (bar chart, treemap, donut)
• Кількість проєктів за характером (bar chart, treemap, donut)

Також, оскільки було ухвалено рішення не робити наразі окремий дешборд по обʼєктах, було вирішено додати до дешборду по проєктах наступні візуалізації

• Кількість проєктів за регіонами (choropleth map)тут беремо регіон із повʼязаного обʼєкта
• Кількість проєктів за секторами / підсекторами (treemap) тут беремо сектор із повʼязаного обʼєкта

Проєкти та обʼєкти

З огляду на це, найперші - найбільш очевидні - правки стосуються насамперед того, що у поточній версії обʼєкти представлені окремим аркушем та окремою таблицею. І нам потрібно буде обʼєднати інформацію про обʼєкти з інформацією про проєкти.

Стосовно візуалізацій це ймовірно означає необхідність використання контейнера, оскільки навряд без нього вийде розташувати все на одному аркуші. Правки щодо таблиць будуть винесені в окремий issue.

Layout

Оскільки на аркуш із візуалізаціями має додатися інформація про обʼєкти, неминуче доведеться міняти layout (його в будь-якому разі потрібно було б міняти, бо поточний далекий від ідеального).

Кілька речей, котрі варто взяти до уваги під час розробки нового способу розташування елементів

• Під графіками "Кількість проєктів у розрізі типів та характеру", здається, достатньо багато місця, аби розташувати там, наприклад, donut chart із розбивкою проєктів за статусами
• Графік розподілу проєктів за датою реєстрації цілком може жити на окремій вкладці в контейнері
• В ідеалі бажано було б розташувати карту і treemap з розбивкою проєктів / обʼєктів поруч, але не на різних вкладках контейнера, аби можна було, наприклад, реалізувати сценарій "Вибираємо певний сектор чи підсектор на treemap і одразу бачимо, скільки проєктів/обʼєктів у нас у цьому секторі чи підсекторі за регіонами". Або ж "Вибираємо регіон і бачимо секторальний розподіл для цього регіона"

Візуалізації

У графіку кількості проєктів за характером стовпчики сортовані за алфавітом, а не за числовим показником. Варто впорядкувати їх за числовим показником від найбільшого до найменшого, оскільки все одно природнього способу сортування у цій категоріальній змінній немає (інакше кажучи, це не є впорядкована категоріальна змінна / ordered factor)

У графіку розподілу проєктів за статусом, здається, або відсутнє розрізнення сегментів за кольором, або ж кольори дуже подібні. Варто змінити, аби було простіше розрізняти сегменти

У цьому блоці ми закладали наступне

Для обраної фінансуючої сторони

• Фінансуюча сторона
• Джерело фінансування
• Тип фінансування
• Обсяг підтвердженого фінансування
• Обсяг розподіленого фінансування (budget/finance/measures/transfered)
• Кількість профінансованих проєктів

Як це фінансування розподіляється:

• Обсяг підтвердженого фінансування за секторами обʼєктів (bar chart, treemap)
• Обсяг підтвердженого фінансування за регіонами (choropleth map)

Що варто змінити / поправити

• Варто подумати, як 1) підштовхнути користувачів до вибору фінансуючої сторони 2) оприявнити на самому дешборді, яка фінансуюча сторона зара є обраною. Це важливо з огляду на те, що весь цей блок має працювати саме як профіль фінансуючої сторони. Можливо, є сенс змінити формат фільтру фінансуючої сторони? Які тут є опції?

• Стовпчиковий графік варто перевернути, аби стовпчики були горизонтальними, і підписи секторів не були під кутом (так зручніше читати)

• Змінити текстові елементи (у картках, назвах візуалізацій, а також фільтрах)

Ще залишається прояснити, як коректно перекласти англійською "доведене фінансування" та "органи управління"

Українська версія:

Модуль аналітики ВІ DREAM - безкоштовний аналітичний інструмент для аналізу даних обʼєктів та проєктів відбудови, відновлення та розвитку, заведених в екосистему DREAM.

Інформація в Модулі подається у вигляді таблиць, графіків та діаграм, зручних для проведення аналітичних досліджень. Інструмент інтегрований з екосистемою DREAM, що дозволяє отримувати оновлені дані щодня.

Для кого буде корисним Модуль аналітики ВІ DREAM і які задачі він допомагає вирішити:

• Ініціатори проєктів за допомогою Модулю аналітики можуть здійснювати моніторинг власних проєктів. Модуль допомагає відстежувати прогрес окремих проєктів, збираючи дані про завдання, терміни виконання та ресурси, витрачені на кожну фазу проєкту. Це допомагає ініціаторам керувати процесом реалізації та, за потреби, вносити зміни в проєкт, а також оцінювати, наскільки успішно він виконується та чи досягаються поставлені цілі.

• Органи управління можуть здійснювати моніторинг проєктів, які були ініційовані самим органом управління, а також підпорядкованими організаціями з ієрархії. Модуль аналітики ВІ DREAM допоможе проаналізувати діяльність підпорядкованих структур та доволі швидко сформувати аналітичну звітність.

• Фінансові організації (в тому числі інвестори) можуть отримувати інформацію з Модулю для визначення того, які проєкти можуть бути профінансовані ними.

• Громадські організації, активісти, небайдужі громадяни можуть використовувати аналітику для збору та аналізу даних про проєкти в певному розрізі, наприклад, за громадою, за регіоном, за сферою діяльності тощо. Це допоможе переконатися, що ресурси витрачаються ефективно та проєкти реалізуються в інтересах громади

Англійська версія:

The BI DREAM analytics Module is a free analytical tool for analyzing data from facilities and projects for restoration and development included in the DREAM ecosystem.

The information in the module is presented in the form of tables, graphs, and charts that are convenient for analytical research. The tool is integrated with the DREAM ecosystem, which allows you to receive updated data on a daily basisю

Who can use the BI DREAM Analytics Module and what tasks it helps to solve?

• Project initiators can use the Analytics Module to monitor their own projects. The module helps track the progress of individual projects by collecting data on tasks, deadlines, and resources spent on each phase of the project. This helps initiators manage the implementation process and make changes to the project, if necessary, as well as assess how well it is being implemented and whether the goals are being achieved.

• Governing bodies can monitor projects that were initiated by the governing body itself, as well as by subordinate organizations in the hierarchy. The analytics module of BI DREAM will help analyze the activities of subordinate structures and generate analytical reporting fairly quickly.

• Financial organizations (including investors) can receive information from the Module to determine which projects they can finance.

• Civil society organizations, activists, and citizens can use analytics to collect and analyze project data in a specific context, for example, by community, by region, by field of activity, etc. This will help ensure that resources are spent efficiently and that projects are implemented in the interests of the community.

Потрібно коротко описати, що саме входить у цей реліз, на що варто звертати увагу у нових модулях, а також варто надати декілька скріншотів нових сторінок.

У цьому блоці ми закладали такі елементи

• Статус
• Тип
• Характер
• Орган управління
• Регіон (тут треба зрозуміти, за чим ми ідентифікуємо регіон - за регіоном обʼєкта чи ініціатора)
• Тип фінансування
• Джерело фінансування
• Фінансуюча сторона

Текстові правки

Проєкт: Замість “проект” всюди пишемо “проєкт”. Щодо відмінювання можна консультуватися ось тут, але з того, що у нас вже є - “статус проєкту”, “тип проєкту”, “характер проєкту”. У множині все просто - “кількість проєктів”, “профінансованість проєктів” (це радше стосуєтьс карток / KPI, а не фільтрів, звісно)

Layout

Наразі всі фільтри знаходяться зверху сторінки, що має свої переваги та недоліки

Переваги

• Одразу видно, які опції для фільтрації даних доступні
• Не потрібно викликати панель з фільтрами (мінус одна дія для користувачів)

Недоліки

• Подібний спосіб розташування передбачає парну кількість елементів, котрі мають рівномірно заповнювати весь відведений простір
• Може бути проблематично додавати нові фільтри, оскільки це вимагатиме більшого простору та відбиратиме простір у візуалізацій та карток

Приховування фільтрів та викликання їх кліком на кнопку теж має свої переваги та недоліки

Переваги

• Економія місця

Недоліки

• Додаткова дія для виклику фільтрів
• Панель з фільтрами після виклику перекриває частину візуалізації. Для перегляду візуалізації повноцінно панель потрібно закрити (а це ще одна додаткова дія)

Питання / Можливі способи альтернативного розташування фільтрів

• Чи можливо розташування фільтрів задавати динамічно в залежності від розміру екрану? Тобто, чи можемо ми, наприклад, на маленьких екранах показувати фільтри лише по кліку на кнопку, а на великих екранах видавати їх одразу / робити видимими постійно (наприклад, збоку від дешборду)?

Для проєктів нам потрібно відображати інформацію про "Орган управління". Оскільки напряму ця інформація не міститься у самому проєкті, нам потрібно виводити, хто є органом управління для проєкту, з інформації про ініціатора проєкту.

Для цього, маючи ідентифікатор ініціатора, ми можемо звернутися із ним до companies endpoint (або ж можемо завантажити всі компанії з цього endpoint та працювати з табличною репрезентацією), і перевірити, чи має організація з цим ідентифікатором властивість memberOf.

Властивість memberOf вказує на parent element для запитуваної організації. Тобто на те, кому підпорядковується обрана організація. Якщо у обраної організації немає властивості memberOf, тоді вона і є органом управління. Якщо у неї є властивість memberOf, тоді вона є дочірньою організацією, а органом управління є та організація, якій вона підпорядковується.

Тут є два нюанси

• В організацій цілком може бути декілька рівнів ієрархії - принаймні теоретично. На практиці, здається, наразі є лише два
• У проєкті може бути декілька ініціаторів. В цьому разі не одразу зрозуміло, від якого з них є сенс відбудовувати ієрархію

Скажімо, є реальний проєкт 231023-9DADF130, у котрого два ініціатора - Департамент економічного розвитку Запорізької міської ради (UA-EDR-37573157) та Запорізька міська рада (UA-EDR-04053915). Цей кейс відносно простий, оскільки Запорізька міська рада є органом управління для Департаменту економічного розвитку Запорізької міської ради.

Втім, є і складніші випадки. Наприклад, у проєкті 050923-8B098754 є два ініціатори - Київська обласна військова адміністрація (UA-EDR-00022533) та Бородянська селищна рада Київської області (UA-EDR-04363662). У цьому випадку жодна з організацій не має властивості memberOf, в такому разі вони обидві за нашою методикою можуть вважатися органом управління для проєкту.

В такому разі слід прояснити

• Чи може бути у проєкту два органи управління
• Якщо не може бути, то якій з організацій надавати перевагу в алгоритмі відбору органу управління

Ми вже заторкали питання форматування чисел у картках (#24 ) та таблицях (#33 ), однак є сенс поговорити і про форматування чисел на вісях. Насамперед ця потреба відчувається тоді, коли у нас на вісях числа з великою кількістю символів.

Тут є два питання:

• Чи потрібні нам вісі та підписи на вісях в принципі, якщо ми підписуємо всі значення напряму біля кожного стовпчика?
• Якщо є якийсь аргумент за те, щоб зберегти підписи на вісях, як ми можемо їх форматувати, аби зменшити кількість знаків? Або ж зменшити кількість самих підписів (умовно до трьох - мінімум, максимум і ~ медіана)

Задача цього блоку - представляти дані щодо органів управління у табличній формі для сортування, фільтрації та зручного зчитування деталей.

У цьому блоці ми закладаємо наступні показники:

• Орган управління
• Кількість підпорядкованих організацій
• Кількість проєктів
• Кількість обʼєктів
• Загальний орієнтовний бюджет
• Підверджене фінансування
• Фінансове покриття
• Кількість контрактних процедур

За замовчуванням таблиця має бути відсортована за показником "Загальний орієнтовний бюджет" від найбільшого до найменшого.

До цієї таблиці можуть застосовуватись наступні фільтри

• Тип органу управління
• Орган управління
• Регіон органу управління

Регіон органу управління можна визначити двома способами (обидва потребують звернення до companies endpoint)

• data/address/streedAddress містить інформацію про повну адресу організації. Наприклад, "місто Київ, ВУЛИЦЯ ГРУШЕВСЬКОГО, будинок 7" або "Дніпропетровська обл., місто Дніпро, ПРОСПЕКТ ОЛЕКСАНДРА ПОЛЯ, будинок 1". Звісно, нам з цієї адреси потрібна тільки перша частина, тобто умовно - до першої коми
• data/address/addressDetails/territory/id містить код території у форматі UA74100030000076377. Для певності краще також використовувати елемент data/address/addressDetails/territory/scheme, аби впевнитись, що використовується схема UA-CATOTTG.

Другий варіант, звісно, краще, але не всі організації, котрі мають текстову адресу, мають код території. Ймовірно на цьому етапі ми не зможемо встановити регіон для всіх органів управління. Це нормально - опишемо цю проблему Проєктному офісу, нехай пропрацюють.

Методологічне питання

Наразі у нас є проєкти, для котрих неможливо визначити оран управління (наприклад, через відсутність даних про ініціатора). В такому разі постає питання, як працювати із відображенням даних для випадків, коли "Орган управління" = NA?

• Можна відображати категорію "Орган управління" NA, поруч зо всіма іншими та системно працювати, аби у нас згодом зʼявились дані щодо органів управління для всіх проєктів
• Можна не відображати "Орган управління" NA, але в такому разі з обчислень щодо бюджетів, фінансування, кількості проєктів зникає певна кількість проєктів, а отже підсумкові показники на цьому аркуші можуть відрізнятися від підсумкових показників на інших аркушах.

У цьому блоці ми закладали

• Кількість проєктів
• Запланований бюджет проєктів
• Підтверджений обсяг фінансування проєктів
• Профінансованість проєктів (%)

Правки / обговорення:

Layout: Зара, здається, картки не заповнюють всю сторінку по ширині, через що виникає дірка з правого боку сторінки в ряду карток

Проєкт: “Кількість проєктів”, “Профінансованість проєктів”

Валюта: Чи варто пояснювати, що коли йдеться про бюджети та фінансування, ми зазначаємо все у гривнях?

Відсотки: Зара індикатор називається “Профінансованість проєктів, %”, а потім і саме значення теж має знак відсотка “ХХ%”. Можливо має сенс прибрати знак відсотка з назви індикатора

На додачу до можливості зберігати окремі зображення також зафіксували потребу зберігати всі елементи модулю в одному зображенні (наприклад, картки, графік та карту) для звітів. Сценарій використання - люди застосовують потрібні для себе фільтри і зберігають зображення (наразі - роблять скріншот) зо всією потрібною інформацією для презентації.

Originally posted by @ndrhzn in #27 (comment)

Для візуалізації "Динаміка створення" варто додати ще одну лінію, котра б демонструвала розподіл проєктів за датою оновлення. Таким чином можна буде побачити, що хоча нові проєкти не обовʼязково створюються у тій же кількості, в якій вони створювались на самому початку, але робота над наповненням вже наявних проєктів триває.

Originally posted by @ndrhzn in #4 (comment)

У цьому блоці ми закладали такі фільтри

• Тип фінансування
• Джерело фінансування
• Фінансуюча сторона

Що варто змінити

Замінити назви фільтрів в англійській версії

Fund type > Funding type
Fund source > Funding source
Finance party > Financing party

Використати кодлісти fundingTypes та fundingSourceCategories для фільтрів у англійській версії

Надійшов запит виключити скасовані проєкти з підрахунку всіх ключових статистик

На практиці це означає необхідність

• Застосування фільтру майже до всіх елементів (майже всі картки, графіки та карти)
• Застосування фільтру до таблиці фінансування

Це також означає необхідність коректної комунікації щодо того, що саме відображається, а що саме виключено з відображення (де і як це має бути зроблено)

Без змін лишається таблиця із проєктами, але там є запит, у ній можуть відображатися всі проєкти, але є запит на можливість швидкого переключення між "активними" (ініціація та виконання) та "скасованими".

Яким можем бути коректний спосіб імплементації цього? Чи можна просто за замовчуванням застосоувати фільтр () і відображати, що він застосований?

Якщо обрати "Фінансуюча сторона" > roadStateFund, то загальна кількість проєктів буде 9, але на карті відображатимуться лише 5. Ця проблема виникає через те, що не у всіх цих 9 проєктів є привʼязані обʼєкти

Тут варто

• Перевірити, чи справді обʼєкти відсутні (так не мало б бути). Якою є кількість проєктів без обʼєктів
• Підготувати дисклеймер для таких випадків, аби пояснити розбіжність між відображенням на графіку та карті

Originally posted by @ndrhzn in #4 (comment)

Для коректного відображення фільтра "Код стратегічного рівня" нам потрібен відповідний кодліст - бажано і українською, і англійською мовами.

У цьому блоці ми закладали

• Фінансуюча сторона
• Тип фінансування
• Джерело фінансування
• Обсяг підтвердженого фінансування
• Обсяг розподіленого фінансування (budget/finance/measures/transfered)
• Кількість профінансованих проєктів
• Кількість органів управління
• Наявність співфінансування (TRUE / FALSE)
• Співфінансування (перелік інших джерел)

Поправки, котрі варто зробити

• Можна тимчасово прибрати "Кількість органів управління" (до того, як ми вибудуємо процес роботи із органами управління)
• Замінити стовпчики "Наявність співфінансування (TRUE / FALSE)" та "Співфінансування (перелік інших джерел)" на "Співфінансування (медіанний відсоток)"

До цієї таблиці у нас також привʼязані дві поточні задачі

• Розрахунок показника співфінансування #11
• Заміна кодів у змінній "Фінансуюча сторона" на людиночитані підписи #1

Для потреб аналітики нам варто додати у публічному застосунку змінні заголовки для різних сторінок.

Наразі для всіх сторінок (наприклад, "Проєкти", "Деталі проєктів", "Фінансування", заголовок сторінки однаковий - "DREAM Аналітика", хоча адреси у них формально різні.

Це своєю чергою позначається на тому, як відображаються результати в Google Analytics (Views by Page title) - у нас немає можливості розрізнити відвідування сторінок у BI.

Звісно, в Google Analytics існують й інші інструменти, які дозволяють виконати цю задачу, але на екрані за замовчуванням відображаються саме Views by Page title.

Пропонована поведінка така: якщо користувачі заходять до розділу "Проєкти", заголовок сторінки має мінятися з "DREAM Аналітика" на "DREAM Аналітика - Проєкти". Інші сторінки - за аналогією.

Чи зрозуміла проблема? Чи має сенс це рішення?

У таблиці із проєктами для деяких проєктів може бути більше ніж один запис. Це виникає через те, що у повʼязаного обʼєкта можуть бути записи про декілька громад, і в такому разі для кожної громади створюється окремий рядок.

Це не впливає на підрахунки ключових статистик, але це викликає питання у користувачів.

Ми вже стикалися із подібною проблемою на прикладі проєктів із декількома ініціаторами. Відпочатку для кожного ініціатора створювався окремий запис, і тому один проєкт міг фігурувати декілька разів - один раз для кожного ініціатора. Але ми змінили цю поведінку, аби уникнути створення кількох записів для одного проєкту. Тепера для проєктів із декількома ініціаторами ми зазначаємо всіх ініціаторів через кому в одній комірці.

Пропоную такий же підхід використовувати і для громад.

Assigning @ndrhzn as FYI / coordination.

I see the css and js files are chunked, so I assume they are built from source files.

Ideally, GitHub would also have the source files, and then we (or I) can configure a GitHub Actions workflow, that uses the source files to build the mashup, which would then be committed to a separate branch.

• A first step would be to commit the source files to the main branch.
• RBC: Share the precise commands to build the site from the main branch (i.e. to produce the output that is currently in the build branch).
• James: Add GitHub Actions workflow to main branch, to regenerate build branch. For example, the https://github.com/peaceiris/actions-gh-pages action can be used to commit the built files, like we do here: https://github.com/open-contracting/extension-explorer/blob/main/.github/workflows/deploy.yml

Фідбек користувачів - з таблиці, що з вашого БІ вивантажує проекти не вистачає стовпчика з посиланням.

Треба генерувати лінк в таблицю (як це в Прозорро ВІ)

Контекст - у таблиці "Деталі проєктів" у першому стовпчику в нас код проєкту слугує також посиланням на сторінку проєкту на порталі, одна під час експорту таблиці в Excel це посилання не зберігається. Варто подумати, як це виправити - чи є можливість зберігати посилання на стовпчику з кодом, чи, наприклад, треба тримати посилання в окремому стовпчику.

Чи ми можемо до цієї сторінки додати ще один фільтр, котрий би дозволяв фільтрувати проєкти за відсотком наповненості? Скажімо, якщо я хочу обрати всі проєкти, де відсоток менше 100%, або всі проєкти у діапазоні від 0% до 50%? Це може бути range slider, якщо Qlik має такий функціонал @andrzejbeletsky

Originally posted by @ndrhzn in #30 (comment)

У цій задачі ми закладали переклад назв регіонів (областей та громад) для відображення у англомовній версії.

Наразі основна частина задачі виконанана, однак ще є сенс перекласти назви регіонів у блоці "Фінансування" / кодлісті Financing Party.

Також в мешап потрібно буде додати пояснення - перше стосується таблиці, друге стосується стовпчикового графіку

• Показник "Наповнення" у таблиці розраховується як частка заповнених секцій проєкту від загальної кількості секцій. Скажімо, якщо з 12 секцій у проєкті є дані для 6, тоді показник наповнення цього проєкту буде 50%. Цей показник враховує статус проєкту - для проєктів зі статусом "Ініціація" наявність контрактних процедур не враховується.
• Для порівняння ініціаторів та органів управління на графіку використовується медіанний показник наповнення проєктів. Скажімо, якщо в ініціатора є три проєкти, з котрих перший заповнений на 75%, другий заповнений на 40%, третій заповнений на 30%, медіанним значенням наповнення проєктів буде 40%.

Originally posted by @ndrhzn in #30 (comment)

У цьому блоці ми закладали

• Код проєкта
• Дата створення
• Сектор (з повʼязаного обʼєкта)
• Область (з повʼязаного обєʼкта)
• Територіальна громада (з повʼязаного обєʼкта)
• Назва
• Опис
• Статус
• Детальний статус
• Тип
• Характер
• Орган управління
• Ініціатор
• Імплементатор
• Балансоутримувач
• Запланований бюджет
• Підтверджений обсяг фінансування
• Стратегічний рівень (тут може бути просто логічне значення щодо наявності звʼязку зі стратегічними документами, або ж перелік самих документів)
• Наявність / кількість тендерів

Як було згодом погоджено - для обʼєктів ми не будемо робити окремий дешборд та таблицю, а інкорпоруємо інформацію про обʼєкти до інформації про проєкти. З огляду на це, пропоную відображати в таблиці наступні змінні у такому порядку

• Код проєкту
• Назва проєкту
• Статус проєкту
• Тип проєкту
• Характер проєкту
• Назва повʼязаного обʼєкта
• Сектор повʼязаного обʼєкта
• Підсектор повʼязаного обʼєкта
• Територіальна громада [повʼязаного обʼєкта]
• Район [повʼязаного обʼєкта]
• Область [повʼязаного обʼєкта]
• Ініціатор проєкту
• Імплементатор проєкту
• Балансоутримувач проєкту
• Запланований бюджет
• Підтверджений обсяг фінансування
• Обсяг доведених коштів
• Стратегічні документи
• Кількість тендерів

Таким чином, ми поки що прибираємо або тимчасово приховуємо з таблиці змінні

• Опис проєкту (допоки не буде вирішена проблема із HTML розміткою)
• Детальний статус (допоки не буде вирішена проблема із кодлістом)
• Орган управління (допоки не буде вирішена проблема з ідентифікацією органу управління)

Ми додаємо до таблиці такі змінні

• Назва повʼязаного обʼєкта (це вже є у таблиці з обʼєктами)
• Підсектор повʼязаного обʼєкта (це вже є у таблиці з обʼєктами)
• Район повʼязаного обʼєкта (це вже є у таблиці з обʼєктами)
• Обсяг доведених коштів (це вже є у таблиці з фінансуванням під назвою "Розподілене фінансування)

Як ми працюємо з відображенням Стратегічного рівня

Наразі на аркуші з проєктами маємо окрему таблицію "Деталі стратегічного рівня". Потреба у такій імплементації виникла через те, що один проєкт може мати звʼязок з декількома документами.

Втім, мені видається, наразі краще зробити таблицю по проєктах на всю висоту аркушу. Питання в такому разі наступне:

Чи ми можемо конкатентувати назви всіх документів, з якими повʼязаний один проєкт? Тобто, якщо там три документи, то замість трьох окремих записів, чи ми можемо мати один, де назви трьох документів дані з певним розділювачем (наприклад, з нового рядка)?

За запитом від проєктного офісу тимчасово прибираємо показник "Доведене фінансування" (у нас він фігурує наразі під назвою "Розподілене фінансування") зо всіх дешбордів та таблиць, де він згадується (допоки ми не будемо впевнені, що цей показник репрезентує коректні дані)

Які елементи це заторкає

• Таблиця "Деталі проєктів" (видаляємо стовпчик)
• Таблиця "Деталі фінансування" (видаляємо стовпчик)
• Аркуш "Фінансування" (потрібно замінити картку)

Більшість змін не дуже складні, однак потрібно визначитися, на що можна замінити картку на аркуші "Фінансування"

Цей аркуш потрібен для представлення узагальненої інформації щодо бюджетів.

Тут пропонується додати наступні візуалізації

• Бюджет проєктів (approaches/budget/budgetBreakdown/amount/amount) у розрізі предмету витрат (approaches/budget/budgetBreakdown/classifications/costItem)
• Бюджет проєктів (approaches/budget/budgetBreakdown/amount/amount)у розрізі типів (approaches/budget/budgetBreakdown/classifications/costType)
• Бюджет проєктів (approaches/budget/budgetBreakdown/amount/amount) у розрізі типі бюджетування (approaches/budget/budgetBreakdown/classifications/budgetType)

Разом з тим, візуалізація бюджету у розрізі типів бюджетування може бути зайвою / непотрібною наразі, оскільки може вийти так, що наразі ми маємо лише один тип (original).

З Проєктного офісу передали такий запит

У користувачів ВІ є запит вивантажувати через натискання правою кнопкою миші на карті/графіку/діаграмі в форматі pdf або jpeg елементу, на якому вони це роблять (як в ВІ прозорро). Щоб одразу і гарну картинку

Видається, що додати такий функціонал має бути доволі просто, якщо це входить в базовий інструментарій Qlik.

Але також маю питання - чи можливо не просто зберігати картинку, а ще й додавати туди якісь метадані (умовно, зазначати, звідки походять дані, і станом на яку дату представлені дані)?

Є запит щодо відображення / форматування чисел на картках та графіках. Проблема, як її оригінально сформулювали в проєктному офісі, звучить таким чином

З нюансів, які трохи турбують - це відображення сум (скрін) трохи збиває з пантелику, це 56 млн чи 56 млрд?) Можливо не всім буде зрозуміло.

Уточнення щодо бажаного формату відображення чисел

Є пропозиція зробити як в ВІ прозорро:
Якщо сума млрд, то так і виводити - скрін 1; скрін 2
Якщо сума млн, то так і виводити - скрін 3.
Після невеликого опитування в офісі, такий варіант здається більш зрозумілим.

Мені здається, тут точно можна покращити користувацький досвід, але важливо подумати, як це зробити охайно, аби не ускладнити користування додатком.

Загальні настанови тут, думаю, полягають в тому, аби числа були зручними для читання (тобто вони не мають бути довгими), аби одиниці вимірювання були зрозумілими (без додаткової ментальної математики), і аби представлення чисел було за можливості консистентним поміж різних елементів на одному аркуші (аби користувачам не потрібно було постійно переключатися між різними варіантіами одиниць вимірювання)

У даних щодо проєктів у нас є декілька випадків, коли для ініціатора проєкту відсутня ознака legalName.

https://public-api.dream.gov.ua/marketplace/public/dream/ideas/250aoy97-io44-48gk-bcnj-pd7wq697529w UA-EDR-43927048
https://public-api.dream.gov.ua/marketplace/public/dream/ideas/647yw44v-iy0h-45za-9vyl-5m0181w77625 UA-EDR-04054889
https://public-api.dream.gov.ua/marketplace/public/dream/ideas/rn6icnn7-07bv-4nz7-8j8h-12dfwx702h53 UA-EDR-04362680
https://public-api.dream.gov.ua/marketplace/public/dream/ideas/9djoif4s-tl80-4a6x-b913-5plv72xti24l 04055896

За словами команди розробки, це проблема, котра виникла під час першої міграції даних (додавання первинних даних у базу), через те, що у деяких історичних проєктів ознаки legalName просто не було. Виправлення цієї проблеми на боці бази даних вимагатиме ручної роботи.

За таких умов видається більш доречним забирати ознаку legalName із companies endpoint (там для всіх зазначених організацій назва є).

Від Проєктного офісу надійшов запит додати код ЄДРПОУ ініціатора / імплементатора / балансоутримувача до таблиці з проєктами.

Тут є щонайменше два можливих варіанти імплементації

• Додавати коди в окремих стовпчиках
• Додавати коди у вже наявних стовпчиках, конкатенуючи їх через " | " (колеги кажуть, що так імплементовано у BI Prozorro)

Другий варіант видається більш доречним, втім потрібно пересвідчитися, що код буде справді читатися у комірці (тобто, що назва і код повністю вміщатимуться у комірку)

Сценарій використання наведено наступний:

Потрібно швидко перевірити та знайти проєкти, в яких фінансове покриття більше 100%. Для подальшої роботи з такими проєктами треба звʼязок з ініціатором або імплементатором. По назві складно шукати - код єдрпоу це інформація, яка краще верифікована. (Це точковий кейс, але кейсів там де потрібен єдрпоу набагато більше може бути)

Є запит додати розріз / фільтр, що вказував би на тип організації. Ця інформація наразі міститься у companies endpoint, в елементі details/classifications, де scheme=“TED-TYPE”. Можливі значення цієї змінної - ministry, administration, centralBody, localBody, enterprise.

Щонайменше, ми можемо додати це як властивість ініціатора, незалежно від того, як швидко ми імплементуємо “орган управління”, бо ця інформація вже наявна.

Варто буде додати собі до задач на майбутнє - перейти на використання monospaced шрифтів щонайменше для таблиць.

Якщо всі символи матимуть однакову ширину, тоді числа з однаковою кількістю символів в таблиці матимуть однакову ширину, і в таблиці їх буде простіше порівнювати між собою.

У поточній версії числа з однаковою кількістю знаків можуть мати різну ширину.

Частина значень у цій змінній - коди КАТОТТГ, які потрібно трансформувати у людиночитані текстові записи, що позначатимуть місцевий бюджет, з якого виділяється фінансування

Ще частина записів - коди країн, які треба перетворити на людиночитані текстові назви країн

Ще частина записів - власне коди фінансуючих сторін, для котрих нам потрібно отримати розшифровку

Користувачі зауважили, що у таблиці з проєктами у нас використовується два різних способи форматування чисел.

Показники щодо бюджетів даються без жодних пробілів, а показники щодо фінансування даються з пробілами. Очевидно, що читати довгі числа простіше, якщо там є пробіли, котрі відокремлюють мільйони, тисячі, і т.д.

Нам варто уніфікувати підхід до форматування чисел в таблицях.

Від Проєктного офісу прийшов запит / побажання додати до панелі з фільтрами підказку для користувачів для тих випадків, коли фільтрів багато і всі вони не вміщаються в один екран.

Можна в усі місця, де пусте місце, але мається на увазі, що там є ще фільтри, додати слово “Більше“? Не дуже очевидно для користувачів, що там є ще якісь додаткові показники.

Приклад пропонованого рішення

Що ви щодо цього думаєте? Чи це можливо технічно? Чи Qlik / mashup дозволяють нам щось таке зробити? @a-radik

As a side comment - на наведеному скріншоті очевидні проблеми з оптимізацією додатку під різні розмірі екрану. Треба буде дослідити це питання трохи більш детально. Можливо у цьому випадку через те, що браузер не відкритий fullscreen, але можливо нам справді є куди покращувати оптимізацію.

До сторінки потрібно буде додати посилання на форму зворотнього звʼязку (ймовірно, можна додати це під загальним дисклеймером).

Посилання на форму українською мовою

Посилання на форму англійською мовою

В цьому блоці ми закладали

• Кількість проєктів / запланований бюджет / обсяг фінансування / профінансованість за регіонами (choropleth map)
• Кількість проєктів за статусом (bar chart або treemap)
• Розподіл проєктів за датою реєстрації (histogram) - визначити binwidth (7 днів, місяць)

Правки загального характеру

“За статусом”

Чи можливо або:

• Зробити так, аби візуалізації заповнювала весь контейнер по ширині (це може бути не дуже оптимальний варіант, оскільки наразі у нас всього лише три стовпчики, і розтягування їх по ширині результуватиме у дуже широких стовпчиках)

• Замінити цю візуалізацію на treemap, тоді всі елементи природньо будуть заповнювати весь простір контейнера

“Розподіл”

Мені здається, цю можна приховати / прибрати. Можливо, в майбутньому ми повернемось до якоїсь варіації на тему цієї візуалізації, але наразі не бачу у ній цінності / потреби

“Динаміка створення”

Тут краще зробити за замовчуванням відображення у розрізі тижнів року

TO DO: Підготувати / поправити заголовки контейнерів / представлень

Для цього кодліста у нас є українські відповідники, але немає англійських

У цьому блоці нам потрібно відобразити детальну інформацію щодо бюджетів у табличному вигляді. Для початку пропонується представити наступні елементи.

• Код проєкту
• Назва проєкту
• Загальний орієнтовний бюджет
• Предмет витрат
• Тип предмету витрат
• Тип бюджетування
• Період

З точки зору презентації даних / зручності користування цією таблицею, один з найбільших викликів полягає у тому, що в одному проєкті може бути (і буде) декілька предметів витрат. Це своєю чергою означає, що дані для одного проєкту будуть розбиті на декілька окремих рядків (один рядок для одного предмету витрат).

Для нас важливо мати можливість дати розбивку бюджету за предметами витрат разом з можливістю бачити загальний бюджет проєкту / групувати предмети витрат за проєктами.