Перейти до вмісту

Стандарти UI K2 2025: відмінності між версіями

Матеріал з K2 ERP Wiki
← Попереднє редагування
R (обговорення | внесок)
Бюрократи, Адміністратори інтерфейсу, Керівники push-підписками, Приховувачі, Адміністратори
2710 редагувань
ВізуальнийВікірозмітка
Прибрав шаблон
Немає опису редагування
 
Рядок 1: Рядок 1:
'''Стандарти UI K2 2025''' — документ, який описує єдині підходи до реалізації дизайнів, контролів, компонентів та програмної частини у проектах K2.
{{DISPLAYTITLE:Стандарти UI K2 2025}}


__TOC__
'''Стандарти UI K2 2025''' — це внутрішній документ, який визначає єдині підходи до реалізації інтерфейсів, контролів, компонентів і програмної частини у проєктах K2.


== Мета ==
Мета стандарту — щоб дизайнери, розробники, менеджери, партнери та замовники говорили однією мовою під час створення інтерфейсів для [[K2 ERP]], сайтів, адміністративних панелей, CRM, кабінетів користувача та інших web-рішень.


Цей документ призначений для того, щоб різні співробітники і партнери компанії К2 розмовляли одне з одним однаковою мовою, коли йде реалізація дизайнів, контролів, програмної частини у різних проектах.
<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Коротко.''' Компоненти K2 мають бути технічно стабільними, візуально гнучкими та придатними до кастомізації під різні дизайни без переписування програмної логіки.
</div>


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


Компоненти повинні з самого початку передбачати свою кастомізацію під певний дизайн.
== Мета стандарту ==


Увага: різні компоненти можуть конфліктувати одне з одним. Тому дуже важливо правильно підбирати контроли, щоб не конфліктували друг з другом.
Web-проєкти K2 часто відрізняються один від одного зовнішнім виглядом, стилістикою, кольорами, розташуванням блоків і поведінкою елементів. При цьому базова програмна логіка компонентів не повинна щоразу переписуватися під новий дизайн.


* P.S. Дуже стара версія стандартів (10-20 річної давнини): https://docs.google.com/document/d/1LjNHDyISGVkk7AnhXfWnTL9xChJqzKHchfTcVrTYWk8/edit
Компонент має бути створений так, щоб його можна було адаптувати під конкретний проєкт: змінити зовнішній вигляд, тему, розміри, положення, іконки або поведінку, але залишити стабільну технічну основу.


== Карти ==
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Головний принцип.''' Дизайн може змінюватися під клієнта, але компонент не повинен втрачати стабільність, сумісність і єдину програмну логіку.
</div>


[[Файл:K2_UI_Standards_2025_01.png|міні|центр|Ілюстрація до розділу «Карти»]]
== Базові принципи UI K2 ==


=== OpenStreet ===
Інтерфейси K2 мають будуватися за кількома простими правилами.


* https://tomickigrzegorz.github.io/leaflet-examples/#10.matching-all-markers-to-the-map-view
Компонент повинен бути зрозумілим для користувача, не конфліктувати з іншими елементами, підтримувати кастомізацію, нормально працювати в різних шаблонах і зберігати передбачувану поведінку.


* https://leafletjs.com/
Особливо важливо перевіряти сумісність компонентів між собою. Різні бібліотеки, стилі, скрипти або шаблони можуть конфліктувати, тому перед використанням нового UI-рішення потрібно оцінити не лише його зовнішній вигляд, а й технічну сумісність із системою.


=== Карти 3D ===
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Важливо.''' Гарний компонент не підходить для K2, якщо він конфліктує з іншими контролами, ламає шаблон, погано масштабується або потребує переписування бізнес-логіки.
</div>


* https://mapplic.com/maps/apartment
== Що має враховувати UI-компонент ==


== Інструментарій ==
Кожен компонент, який використовується в K2, має відповідати кільком вимогам.


SQL Power Architech - моделювання структури бази даних:
{| class="wikitable" style="width:100%;"
! Вимога
! Пояснення
|-
| Кастомізація
| Компонент має легко адаптуватися під різні дизайни, теми та стилі
|-
| Сумісність
| Компонент не повинен конфліктувати з іншими елементами системи
|-
| Повторне використання
| Один і той самий компонент має працювати в різних проєктах без переписування з нуля
|-
| Адаптивність
| Інтерфейс має нормально працювати на різних розмірах екрана
|-
| Зрозумілість
| Користувач має швидко розуміти, що робить компонент
|-
| Масштабованість
| Компонент має витримувати збільшення кількості даних або пунктів керування
|-
| Підтримуваність
| Розробники мають мати змогу швидко підтримувати та змінювати компонент
|}


* https://bestofbi.com/architect-download/
== Джерела натхнення та приклади ==


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


* https://dbeaver.com/download/
Ці приклади не означають автоматичне копіювання. Вони використовуються як орієнтир для поведінки компонентів, логіки розташування, типових сценаріїв і візуальної організації інтерфейсу.


* Редактор структури бази даних (для можливого використання редактора): https://www.drawdb.app/editor
== Шаблони адміністративних панелей ==


== Шаблони ==
Багато прикладів роботи компонентів можна побачити в готових шаблонах адміністративних панелей.


Багато прикладів роботи компонентів та їх поводження можна побачити в різних шаблонах.
Корисні приклади:


* https://adminlte.io/themes/AdminLTE/index2.html#
* [https://adminlte.io/themes/AdminLTE/index2.html AdminLTE]
* [https://appstack.bootlab.io/dashboard-default.html AppStack]
* [https://themes.getbootstrap.com/preview/?theme_id=88616 Bootstrap Theme 88616]
* [https://themes.getbootstrap.com/preview/?theme_id=28117 Bootstrap Theme 28117]
* [https://themes.getbootstrap.com/product/keen-the-ultimate-bootstrap-admin-theme/ Keen Bootstrap Admin Theme]
* [https://themes.getbootstrap.com/preview/?theme_id=5824 Bootstrap Theme 5824]
* [https://themes.getbootstrap.com/preview/?theme_id=1666 Bootstrap Theme 1666]
* [https://themes.getbootstrap.com/preview/?theme_id=21888 Bootstrap Theme 21888]


* https://appstack.bootlab.io/dashboard-default.html
== Google та Material-подібні теми ==


* https://themes.getbootstrap.com/preview/?theme_id=88616
Для інтерфейсів, де потрібна сучасна, легка й зрозуміла подача, можна орієнтуватися на Material-подібні теми та шаблони.


* https://themes.getbootstrap.com/preview/?theme_id=28117
Приклади:


* https://themes.getbootstrap.com/product/keen-the-ultimate-bootstrap-admin-theme/
* [https://themewagon.com/themes/tailadmin/ TailAdmin]
* [https://startbootstrap.com/previews/material-admin-pro Material Admin Pro]
* [https://startbootstrap.com/previews/sb-admin-pro-angular SB Admin Pro Angular]


* https://themes.getbootstrap.com/preview/?theme_id=5824
== Набори UI-компонентів ==


* https://themes.getbootstrap.com/preview/?theme_id=1666
Набори UI-компонентів допомагають швидко побачити, як можуть працювати таблиці, меню, тулбари, модальні вікна, вкладки, слайдери, календарі та інші елементи.


* https://themes.getbootstrap.com/preview/?theme_id=21888
Рекомендовані джерела для аналізу:


== Google-теми ==
* [https://ej2.syncfusion.com/vue/documentation/toolbar/responsive-mode Syncfusion]
* [https://www.jqwidgets.com/jquery-widgets-demo/ jQWidgets]
* [https://snippet.dhtmlx.com/i7cfddkl DHX / DHTMLX]
* [https://demos.telerik.com/kendo-ui/ Telerik Kendo UI]
* [https://www.devexpress.com/support/demos/# DevExpress]


* https://themewagon.com/themes/tailadmin/
<div style="border:2px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Рекомендація.''' DHX / DHTMLX можна розглядати як один із пріоритетних наборів для аналізу та використання в інтерфейсах K2, якщо він технічно підходить до конкретного завдання.
</div>


* https://startbootstrap.com/previews/material-admin-pro
== Інструменти для проєктування та розробки ==


* https://startbootstrap.com/previews/sb-admin-pro-angular
Для якісної реалізації UI недостатньо лише обрати бібліотеку компонентів. Потрібно також моделювати структуру даних, схеми, прототипи інтерфейсів і бізнес-логіку.


== Грід PHP Grid ==
{| class="wikitable" style="width:100%;"
! Інструмент
! Призначення
! Посилання
|-
| SQL Power Architect
| Моделювання структури бази даних
| [https://bestofbi.com/architect-download/ bestofbi.com]
|-
| DBeaver
| Редактор і клієнт баз даних
| [https://dbeaver.com/download/ dbeaver.com]
|-
| DrawDB
| Візуальний редактор структури бази даних
| [https://www.drawdb.app/editor drawdb.app]
|-
| Wireframe.cc
| Швидке створення wireframe-прототипів
| [https://wireframe.cc wireframe.cc]
|-
| Microsoft Visio
| Схеми інтерфейсів, процесів і ділової графіки
| Окремий desktop-інструмент
|}


* https://www.gridphp.com/demo-center/
== Карти ==


== AG-Grid ==
[[Файл:K2_UI_Standards_2025_01.png|міні|центр|Ілюстрація до розділу «Карти»]]
 
* https://www.ag-grid.com/example/
 
== Telerik ==


* https://www.telerik.com/
Карти використовуються там, де потрібно показати об’єкти на місцевості, маршрути, склади, адреси, точки обслуговування, логістику або просторові дані.


* https://www.telerik.com/support/demos
Для звичайних web-карт можна використовувати OpenStreetMap та Leaflet.


== Report ==
Приклади:


* Stimul Report: https://demo.stimulsoft.com/#Net/BusinessInvoice
* [https://leafletjs.com/ Leaflet]
* [https://tomickigrzegorz.github.io/leaflet-examples/#10.matching-all-markers-to-the-map-view Leaflet examples]


== Набори прикладів різних UI компонентів ==
Для 3D-карт, планів приміщень або інтерактивних схем можна аналізувати спеціалізовані рішення:


В наборах ви можете побачити багато різних компонентів. Якісь компоненти ми можемо не описати в цьому документі, але потрібно бачити їх можливості і при необхідності - використовувати.
* [https://mapplic.com/maps/apartment Mapplic]
 
* Syncfusion: https://ej2.syncfusion.com/vue/documentation/toolbar/responsive-mode
 
* jQWidgets: https://www.jqwidgets.com/jquery-widgets-demo/
 
* DHX (рекомендовано до використання): https://snippet.dhtmlx.com/i7cfddkl
 
* Різні UI-компоненти Telerik (більше під .Net): https://demos.telerik.com/kendo-ui/
 
* DevExpress (більше .Net): https://www.devexpress.com/support/demos/#
 
== VueRibbon: https://www.vueribbon.com/home ==
 
* MetroUI: https://korzh.com/metroui#licensing
 
* https://themes.org.ua/pandora/index.html#forms-extended
 
* https://metroui.org.ua/ribbon-menu.html
 
== Інструменти протопіювання дизайну ==
 
За допомогою цих інструментів ви можете зробити схему елементів дизайну.
 
Microsoft Visio - графічний редактор для ділової графіки. Дозволяє створити схеми користувацького інтерфейсу та ділову графіку для проекту.
 
* https://wireframe.cc
 
== Моделювання структури бази даних ==
 
* https://bestofbi.com/products/sql-power-architect-data-modeling/ - SQL Power Architech.
 
== Види компонентів ==


== Меню ==
== Меню ==
Рядок 127: Рядок 161:
[[Файл:K2_UI_Standards_2025_02.png|міні|центр|Ілюстрація до розділу «Меню»]]
[[Файл:K2_UI_Standards_2025_02.png|міні|центр|Ілюстрація до розділу «Меню»]]


Меню можуть бути: верхнє, нижнє, бокове (справа, або зліва), контекстне та інше.
Меню — один із головних елементів навігації в системі.
 
Контекстне меню - з’являється тоді, коли ми клацаємо на елементі лівою клавішею миші. Можливі і інші варіанти визову контекстного меню.
 
Меню можуть мати багато рівнів. Тому, повинно бути розуміння скільки рівнів меню передбачає і як поводяться різні рівні меню.
 
Останнім часом для меню з великою кількістю пунктів стали передбачати полосу пошуку елемента меню по назві, або ключовому слову.


* Приклади: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/defaultfunctionality.htm
У проєктах K2 можуть використовуватися верхні, нижні, бокові, контекстні та багаторівневі меню. Якщо пунктів багато, потрібно передбачати пошук по назві або ключовому слову.


* https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/minimized.htm
Контекстне меню зазвичай відкривається при натисканні на елемент або через іншу дію, визначену сценарієм інтерфейсу.


=== Контектне меню ===
Приклади:


* https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/contextmenu.htm
* [https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/defaultfunctionality.htm jqxMenu]
* [https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/minimized.htm Minimized menu]
* [https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxmenu/index.htm#demos/jqxmenu/contextmenu.htm Context menu]


== Таймлайн ==
== Таймлайн ==
Рядок 147: Рядок 177:
[[Файл:K2_UI_Standards_2025_03.png|міні|центр|Ілюстрація до розділу «Таймлайн»]]
[[Файл:K2_UI_Standards_2025_03.png|міні|центр|Ілюстрація до розділу «Таймлайн»]]


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


Приклад:
Приклад:


* https://adminlte.io/themes/AdminLTE/pages/UI/timeline.html
* [https://adminlte.io/themes/AdminLTE/pages/UI/timeline.html AdminLTE Timeline]


== Тулбари ==
== Тулбари ==
Рядок 157: Рядок 187:
[[Файл:K2_UI_Standards_2025_04.png|міні|центр|Ілюстрація до розділу «Тулбари»]]
[[Файл:K2_UI_Standards_2025_04.png|міні|центр|Ілюстрація до розділу «Тулбари»]]


Панель інструментів призначена для вибору команд.
Тулбар — це панель інструментів для швидкого доступу до команд.
 
У K2 тулбар має бути зрозумілим, не перевантаженим і пов’язаним із поточним контекстом. Кнопки, які не мають сенсу для поточного стану, краще приховувати або вимикати.
 
Приклад:


* Приклад: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxtoolbar/index.htm#demos/jqxtoolbar/defaultfunctionality.htm
* [https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxtoolbar/index.htm#demos/jqxtoolbar/defaultfunctionality.htm jqxToolbar]


== Закладки (TabStrip) ==
== Закладки / TabStrip ==


[[Файл:K2_UI_Standards_2025_05.png|міні|центр|Ілюстрація до розділу «Закладки (TabStrip)»]]
[[Файл:K2_UI_Standards_2025_05.png|міні|центр|Ілюстрація до розділу «Закладки (TabStrip)»]]


Дозволяють розташувати інформацію по різним сторінкам. Розподіляючи інформацію по смислу.
Закладки дозволяють розділити інформацію на смислові блоки. Це зручно для карток клієнтів, документів, налаштувань, звітів, аналітики або складних форм.
 
TabStrip потрібно використовувати там, де користувачу справді потрібно перемикатися між кількома логічними частинами, а не просто ховати перевантажений інтерфейс.
 
Приклад:


* Приклад: https://demos.telerik.com/kendo-ui/tabstrip/tab-position
* [https://demos.telerik.com/kendo-ui/tabstrip/tab-position Telerik TabStrip]


== Ribbon-інтерфейс ==
== Ribbon-інтерфейс ==
Рядок 173: Рядок 211:
[[Файл:K2_UI_Standards_2025_06.png|міні|центр|Ілюстрація до розділу «Ribbon-інтерфейс»]]
[[Файл:K2_UI_Standards_2025_06.png|міні|центр|Ілюстрація до розділу «Ribbon-інтерфейс»]]


Це інтерфейс в стилі Ms Office 2013.
Ribbon — це інтерфейс у стилі Microsoft Office. Він підходить для складних систем із великою кількістю команд, які потрібно згрупувати за вкладками та функціональними зонами.
 
Ribbon доцільно використовувати там, де звичайний тулбар уже не справляється з кількістю команд.


== Приклади: https://snippet.dhtmlx.com/9ckg47ro?text=Ribbon ==
Приклади:


* https://www.vueribbon.com/home
* [https://snippet.dhtmlx.com/9ckg47ro?text=Ribbon DHTMLX Ribbon]
* [https://www.vueribbon.com/home VueRibbon]
* [https://metroui.org.ua/ribbon-menu.html Metro UI Ribbon]


== Таблиці (гриди) ==
== Таблиці / гриди ==


[[Файл:K2_UI_Standards_2025_07.png|міні|центр|Ілюстрація до розділу «Таблиці (гриди)»]]
[[Файл:K2_UI_Standards_2025_07.png|міні|центр|Ілюстрація до розділу «Таблиці (гриди)»]]


За допомогою гридів автоматизуються значні частини табличних даних.
Гриди — один із ключових елементів ERP-інтерфейсу. Вони використовуються для табличних даних, документів, довідників, журналів, залишків, звітів і списків.


Ми використовуємо в своїй практиці PHPGrid та AG-Grid.
У K2 можуть використовуватися PHPGrid, AG-Grid та інші грід-компоненти, якщо вони відповідають технічним вимогам проєкту.


Приклади роботи та функціоналу PHPGrid:
Приклади:


* https://www.gridphp.com/demo-center/
* [https://www.gridphp.com/demo-center/ PHPGrid Demo]
* [https://www.ag-grid.com/example/ AG-Grid]


Приклади AG-Grid:
== Master-Detail ==


* https://www.ag-grid.com/example/
[[Файл:K2_UI_Standards_2025_08.png|міні|центр|Ілюстрація до розділу «Master-Detail»]]


=== Master-Detail ===
Master-Detail використовується для відображення зв’язку “один до багатьох”.


[[Файл:K2_UI_Standards_2025_08.png|міні|центр|Ілюстрація до розділу «Master-Detail»]]
Типовий приклад: документ і його рядки, клієнт і його замовлення, склад і залишки, рахунок і платежі.


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


Приклад:
== Підгрид Master-Detail ==


* https://www.gridphp.com/demo-center/
[[Файл:K2_UI_Standards_2025_09.png|міні|центр|Ілюстрація до розділу «Під-гридом Master-Detail»]]


=== Під-гридом Master-Detail ===
Підгрид використовується, коли деталізацію потрібно показати безпосередньо всередині основної таблиці.


[[Файл:K2_UI_Standards_2025_09.png|міні|центр|Ілюстрація до розділу «Під-гридом Master-Detail»]]
Це зручно для швидкого перегляду пов’язаних даних без переходу на окрему сторінку.


=== Multy-грід (Tab-грід) ===
== Multi-grid / Tab-grid ==


[[Файл:K2_UI_Standards_2025_10.png|міні|центр|Ілюстрація до розділу «Multy-грід (Tab-грід)»]]
[[Файл:K2_UI_Standards_2025_10.png|міні|центр|Ілюстрація до розділу «Multy-грід (Tab-грід)»]]
Multi-grid або Tab-grid використовується тоді, коли в одному робочому місці потрібно показати кілька пов’язаних таблиць.
Наприклад, у картці клієнта можуть бути окремі вкладки для контактів, угод, документів, дзвінків, файлів і задач.


== Кнопки ==
== Кнопки ==
Рядок 217: Рядок 264:
[[Файл:K2_UI_Standards_2025_11.png|міні|центр|Ілюстрація до розділу «Кнопки»]]
[[Файл:K2_UI_Standards_2025_11.png|міні|центр|Ілюстрація до розділу «Кнопки»]]


Приклад зовнішнього вигляду кнопок:
Кнопки мають чітко показувати дію, яку вони виконують.


* https://adminlte.io/themes/AdminLTE/pages/UI/buttons.html
Кнопка може бути звичайною, з іконкою, з меню, вертикальною, горизонтальною або частиною тулбару. Важливо, щоб користувач розумів різницю між основною дією, додатковою дією та небезпечною дією.


== Кнопка може мати список (меню) ==
Приклад:


== Кнопки можуть мати картинку на підпис ==
* [https://adminlte.io/themes/AdminLTE/pages/UI/buttons.html AdminLTE Buttons]


Кнопки можуть розміщуватись не тільки горизонтально, але й вертикально:
== Спліттери / Splitter ==
 
== Спліттери (Splitter) ==


[[Файл:K2_UI_Standards_2025_12.png|міні|центр|Ілюстрація до розділу «Спліттери (Splitter)»]]
[[Файл:K2_UI_Standards_2025_12.png|міні|центр|Ілюстрація до розділу «Спліттери (Splitter)»]]


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


* Приклад: https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxsplitter/index.htm#demos/jqxsplitter/defaultfunctionality.htm
Це корисно для складних робочих екранів, де користувачеві потрібно самостійно збільшити список, форму, перегляд документа, карту або панель деталей.


== Карти ==
Приклад:


[[Файл:K2_UI_Standards_2025_13.png|міні|центр|Ілюстрація до розділу «Карти»]]
* [https://www.jqwidgets.com/jquery-widgets-demo/demos/jqxsplitter/index.htm#demos/jqxsplitter/defaultfunctionality.htm jqxSplitter]


== Прогрес-бари ==
== Прогрес-бари ==


[[Файл:K2_UI_Standards_2025_14.png|міні|центр|Ілюстрація до розділу «Прогрес-бари»]]
[[Файл:K2_UI_Standards_2025_14.png|міні|центр|Ілюстрація до розділу «Прогрес-бари»]]
Прогрес-бари використовуються для показу виконання процесу: імпорту, експорту, завантаження, синхронізації, обробки файлів або довгих операцій.
Користувач має бачити, що система працює, а не зависла.


== Слайдери ==
== Слайдери ==
Рядок 247: Рядок 296:
[[Файл:K2_UI_Standards_2025_15.png|міні|центр|Ілюстрація до розділу «Слайдери»]]
[[Файл:K2_UI_Standards_2025_15.png|міні|центр|Ілюстрація до розділу «Слайдери»]]


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


* Приклад: https://adminlte.io/themes/AdminLTE/pages/UI/sliders.html
* [https://adminlte.io/themes/AdminLTE/pages/UI/sliders.html AdminLTE Sliders]


== Звіти (Reports) ==
== Звіти / Reports ==


[[Файл:K2_UI_Standards_2025_16.png|міні|центр|Ілюстрація до розділу «Звіти (Reports)»]]
[[Файл:K2_UI_Standards_2025_16.png|міні|центр|Ілюстрація до розділу «Звіти (Reports)»]]


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


* Приклад: https://demo.stimulsoft.com/#Net/Order
У K2 звіти мають підтримувати зрозумілу структуру, фільтри, періоди, джерела даних і можливість друку.


== PivotGrid (OLAP), BI ==
Приклад:
 
* [https://demo.stimulsoft.com/#Net/Order Stimulsoft Reports]
 
== PivotGrid / OLAP / BI ==


[[Файл:K2_UI_Standards_2025_17.png|міні|центр|Ілюстрація до розділу «PivotGrid (OLAP), BI»]]
[[Файл:K2_UI_Standards_2025_17.png|міні|центр|Ілюстрація до розділу «PivotGrid (OLAP), BI»]]


* Приклад: https://demo.stimulsoft.com/#Net/DashboardInsuranceSales2014-2022
PivotGrid, OLAP і BI-компоненти використовуються для аналітики, агрегування даних, побудови дашбордів і управлінської звітності.
 
Такі компоненти потрібні там, де користувач не просто переглядає таблицю, а аналізує дані за різними вимірами.
 
Приклад:
 
* [https://demo.stimulsoft.com/#Net/DashboardInsuranceSales2014-2022 Stimulsoft Dashboard]


== Вікна ==
== Вікна та модальні форми ==


[[Файл:K2_UI_Standards_2025_18.png|міні|центр|Ілюстрація до розділу «Вікна»]]
[[Файл:K2_UI_Standards_2025_18.png|міні|центр|Ілюстрація до розділу «Вікна»]]


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


* Приклад модальних вікон: https://adminlte.io/themes/AdminLTE/pages/UI/modals.html
Вікна мають використовувати доступний простір екрана. Якщо задача складна, форма має бути достатньо великою, читабельною і, за потреби, змінюваною за розміром.


Технічно, для вікон рекомендується займати максимальний простір екрану, який має сенс для певної здачі. Тому має сенс мати змогу змінити розмір вікна, розширити його.
Приклад:


Елементи вікна повинні теж позіціонуватись так, щоб займати весь простір та легко читатись.
* [https://adminlte.io/themes/AdminLTE/pages/UI/modals.html AdminLTE Modals]


== Suite (комплект) ==
== Suite / комплект компонентів ==


[[Файл:K2_UI_Standards_2025_19.png|міні|центр|Ілюстрація до розділу «Suite (комплект)»]]
[[Файл:K2_UI_Standards_2025_19.png|міні|центр|Ілюстрація до розділу «Suite (комплект)»]]


Це стилистично росташований комплекс компонент.
Suite — це узгоджений набір компонентів, які стилістично й технічно працюють разом.
 
Використання одного комплекту зменшує ризик конфліктів між контролами, стилями та JavaScript-логікою.
 
Приклад:
 
* [https://snippet.dhtmlx.com/85fbitnu?mode=wide DHTMLX Suite]
 
== Короткий стандарт вибору компонента ==
 
Перед використанням нового компонента в K2 потрібно відповісти на кілька питань.


* Приклад: https://snippet.dhtmlx.com/85fbitnu?mode=wide
{| class="wikitable" style="width:100%;"
! Питання
! Навіщо це потрібно
|-
| Чи можна змінити зовнішній вигляд компонента?
| Щоб адаптувати його під дизайн клієнта
|-
| Чи не конфліктує він з іншими бібліотеками?
| Щоб не ламати інтерфейс системи
|-
| Чи підтримує він великі обсяги даних?
| Для ERP це критично, особливо в таблицях і звітах
|-
| Чи нормально працює на різних екранах?
| Для адаптивності та зручності
|-
| Чи є документація та приклади?
| Щоб компонент можна було підтримувати
|-
| Чи можна інтегрувати його з backend K2?
| Щоб UI не жив окремо від бізнес-логіки
|-
| Чи зрозумілий він користувачу?
| Щоб інтерфейс не виглядав красиво, але незручно
|}


== Додаткові ілюстрації ==
== Додаткові ілюстрації ==
Рядок 325: Рядок 422:
K2_UI_Standards_2025_55.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_55.png
K2_UI_Standards_2025_55.png|Ілюстрація UI K2|посилання=Файл:K2_UI_Standards_2025_55.png
</gallery>
</gallery>
== Коротко ==
{| class="wikitable" style="width:100%;"
! Питання
! Відповідь
|-
| Для чого потрібні стандарти UI K2?
| Щоб різні команди реалізовували інтерфейси в єдиній логіці
|-
| Чи можна змінювати дизайн компонентів?
| Так, компоненти мають підтримувати кастомізацію під конкретний проєкт
|-
| Чи можна переписувати компонент під кожен дизайн?
| Ні, бажано зберігати одну програмну основу й змінювати лише візуальний рівень
|-
| Що важливо при виборі контролу?
| Сумісність, адаптивність, документація, підтримка великих даних і відсутність конфліктів
|-
| Які компоненти критичні для ERP?
| Гриди, меню, тулбари, форми, звіти, права доступу, Master-Detail, модальні вікна
|-
| Навіщо потрібні приклади з інших бібліотек?
| Щоб бачити готові сценарії поведінки й не вигадувати базові елементи з нуля
|}


== Див. також ==
== Див. також ==
Рядок 335: Рядок 457:
* [[Таблиці]]
* [[Таблиці]]
* [[Грід]]
* [[Грід]]
* [[K2 ERP Python]]
* [[K2 ERP Javascript]]
* [[Документація K2]]


[[index.php?title=Категорія:K2 ERP]]
[[Категорія:K2 ERP]]
[[index.php?title=Категорія:UI]]
[[Категорія:UI]]
[[index.php?title=Категорія:Стандарти K2]]
[[Категорія:UX]]
[[index.php?title=Категорія:Документація K2]]
[[Категорія:Стандарти K2]]
[[Категорія:Документація K2]]
[[Категорія:Адміністративна панель]]
[[Категорія:Грід]]
[[Категорія:Корпоративна Wiki]]

Поточна версія на 17:56, 1 травня 2026


Стандарти UI K2 2025 — це внутрішній документ, який визначає єдині підходи до реалізації інтерфейсів, контролів, компонентів і програмної частини у проєктах K2.

Мета стандарту — щоб дизайнери, розробники, менеджери, партнери та замовники говорили однією мовою під час створення інтерфейсів для K2 ERP, сайтів, адміністративних панелей, CRM, кабінетів користувача та інших web-рішень.

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

Мета стандарту

Web-проєкти K2 часто відрізняються один від одного зовнішнім виглядом, стилістикою, кольорами, розташуванням блоків і поведінкою елементів. При цьому базова програмна логіка компонентів не повинна щоразу переписуватися під новий дизайн.

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

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

Базові принципи UI K2

Інтерфейси K2 мають будуватися за кількома простими правилами.

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

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

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

Що має враховувати UI-компонент

Кожен компонент, який використовується в K2, має відповідати кільком вимогам.

Вимога Пояснення
Кастомізація Компонент має легко адаптуватися під різні дизайни, теми та стилі
Сумісність Компонент не повинен конфліктувати з іншими елементами системи
Повторне використання Один і той самий компонент має працювати в різних проєктах без переписування з нуля
Адаптивність Інтерфейс має нормально працювати на різних розмірах екрана
Зрозумілість Користувач має швидко розуміти, що робить компонент
Масштабованість Компонент має витримувати збільшення кількості даних або пунктів керування
Підтримуваність Розробники мають мати змогу швидко підтримувати та змінювати компонент

Джерела натхнення та приклади

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

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

Шаблони адміністративних панелей

Багато прикладів роботи компонентів можна побачити в готових шаблонах адміністративних панелей.

Корисні приклади:

Google та Material-подібні теми

Для інтерфейсів, де потрібна сучасна, легка й зрозуміла подача, можна орієнтуватися на Material-подібні теми та шаблони.

Приклади:

Набори UI-компонентів

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

Рекомендовані джерела для аналізу:

Рекомендація. DHX / DHTMLX можна розглядати як один із пріоритетних наборів для аналізу та використання в інтерфейсах K2, якщо він технічно підходить до конкретного завдання.

Інструменти для проєктування та розробки

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

Інструмент Призначення Посилання
SQL Power Architect Моделювання структури бази даних bestofbi.com
DBeaver Редактор і клієнт баз даних dbeaver.com
DrawDB Візуальний редактор структури бази даних drawdb.app
Wireframe.cc Швидке створення wireframe-прототипів wireframe.cc
Microsoft Visio Схеми інтерфейсів, процесів і ділової графіки Окремий desktop-інструмент

Карти

Ілюстрація до розділу «Карти»

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

Для звичайних web-карт можна використовувати OpenStreetMap та Leaflet.

Приклади:

Для 3D-карт, планів приміщень або інтерактивних схем можна аналізувати спеціалізовані рішення:

Меню

Ілюстрація до розділу «Меню»

Меню — один із головних елементів навігації в системі.

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

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

Приклади:

Таймлайн

Ілюстрація до розділу «Таймлайн»

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

Приклад:

Тулбари

Ілюстрація до розділу «Тулбари»

Тулбар — це панель інструментів для швидкого доступу до команд.

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

Приклад:

Закладки / TabStrip

Ілюстрація до розділу «Закладки (TabStrip)»

Закладки дозволяють розділити інформацію на смислові блоки. Це зручно для карток клієнтів, документів, налаштувань, звітів, аналітики або складних форм.

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

Приклад:

Ribbon-інтерфейс

Ілюстрація до розділу «Ribbon-інтерфейс»

Ribbon — це інтерфейс у стилі Microsoft Office. Він підходить для складних систем із великою кількістю команд, які потрібно згрупувати за вкладками та функціональними зонами.

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

Приклади:

Таблиці / гриди

Ілюстрація до розділу «Таблиці (гриди)»

Гриди — один із ключових елементів ERP-інтерфейсу. Вони використовуються для табличних даних, документів, довідників, журналів, залишків, звітів і списків.

У K2 можуть використовуватися PHPGrid, AG-Grid та інші грід-компоненти, якщо вони відповідають технічним вимогам проєкту.

Приклади:

Master-Detail

Ілюстрація до розділу «Master-Detail»

Master-Detail використовується для відображення зв’язку “один до багатьох”.

Типовий приклад: документ і його рядки, клієнт і його замовлення, склад і залишки, рахунок і платежі.

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

Підгрид Master-Detail

Ілюстрація до розділу «Під-гридом Master-Detail»

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

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

Multi-grid / Tab-grid

Ілюстрація до розділу «Multy-грід (Tab-грід)»

Multi-grid або Tab-grid використовується тоді, коли в одному робочому місці потрібно показати кілька пов’язаних таблиць.

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

Кнопки

Ілюстрація до розділу «Кнопки»

Кнопки мають чітко показувати дію, яку вони виконують.

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

Приклад:

Спліттери / Splitter

Ілюстрація до розділу «Спліттери (Splitter)»

Splitter дозволяє користувачу змінювати розмір областей інтерфейсу.

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

Приклад:

Прогрес-бари

Ілюстрація до розділу «Прогрес-бари»

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

Користувач має бачити, що система працює, а не зависла.

Слайдери

Ілюстрація до розділу «Слайдери»

Слайдери використовуються для вибору значення або діапазону значень.

В ERP-інтерфейсах їх потрібно застосовувати обережно: там, де точне числове значення важливіше за приблизний вибір, краще використовувати поле введення.

Приклад:

Звіти / Reports

Ілюстрація до розділу «Звіти (Reports)»

Звіти — це підготовлена інформація для перегляду, аналізу, друку або експорту.

У K2 звіти мають підтримувати зрозумілу структуру, фільтри, періоди, джерела даних і можливість друку.

Приклад:

PivotGrid / OLAP / BI

Ілюстрація до розділу «PivotGrid (OLAP), BI»

PivotGrid, OLAP і BI-компоненти використовуються для аналітики, агрегування даних, побудови дашбордів і управлінської звітності.

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

Приклад:

Вікна та модальні форми

Ілюстрація до розділу «Вікна»

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

Вікна мають використовувати доступний простір екрана. Якщо задача складна, форма має бути достатньо великою, читабельною і, за потреби, змінюваною за розміром.

Приклад:

Suite / комплект компонентів

Ілюстрація до розділу «Suite (комплект)»

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

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

Приклад:

Короткий стандарт вибору компонента

Перед використанням нового компонента в K2 потрібно відповісти на кілька питань.

Питання Навіщо це потрібно
Чи можна змінити зовнішній вигляд компонента? Щоб адаптувати його під дизайн клієнта
Чи не конфліктує він з іншими бібліотеками? Щоб не ламати інтерфейс системи
Чи підтримує він великі обсяги даних? Для ERP це критично, особливо в таблицях і звітах
Чи нормально працює на різних екранах? Для адаптивності та зручності
Чи є документація та приклади? Щоб компонент можна було підтримувати
Чи можна інтегрувати його з backend K2? Щоб UI не жив окремо від бізнес-логіки
Чи зрозумілий він користувачу? Щоб інтерфейс не виглядав красиво, але незручно

Додаткові ілюстрації

  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2
  • Ілюстрація UI K2
    Ілюстрація UI K2

Коротко

Питання Відповідь
Для чого потрібні стандарти UI K2? Щоб різні команди реалізовували інтерфейси в єдиній логіці
Чи можна змінювати дизайн компонентів? Так, компоненти мають підтримувати кастомізацію під конкретний проєкт
Чи можна переписувати компонент під кожен дизайн? Ні, бажано зберігати одну програмну основу й змінювати лише візуальний рівень
Що важливо при виборі контролу? Сумісність, адаптивність, документація, підтримка великих даних і відсутність конфліктів
Які компоненти критичні для ERP? Гриди, меню, тулбари, форми, звіти, права доступу, Master-Detail, модальні вікна
Навіщо потрібні приклади з інших бібліотек? Щоб бачити готові сценарії поведінки й не вигадувати базові елементи з нуля

Див. також

Отримано з https://wiki.erp.kyiv.ua/index.php?title=Стандарти_UI_K2_2025&oldid=505