Бізнесу не потрібен інтерфейс, який без зайвих ускладнень гарно виглядає. Бізнесу потрібен інтерфейс, який оперативно працює, мало коштує в розвитку, не ламається і витримує роки масштабування.
Додатково саме тут починається правда, яку багато хто не хоче чути.
Якщо замовник бачить потужний грид, таблицю, структуровану форму, панель фільтрів, дії над записами, імпорт, експорт, сортування, права доступу – іноді перша реакція звучить так:
“Виглядає олдскульно”.
Водночас парадокс в отже, що надзвичайно нерідко саме це і є справжній сучасний рівень веб-розробки. (Спойлер: інтегратори 1С тут теж знають, про що мова.)
Не той, де дизайнер намалював красивий екран.
А той, де середовище вміє працювати.
Не той, де все сяє анімаціями.
А той, де один компонент вирішує десятки задач одразу. Для директора це перестає бути загадкою в кінці місяця.
Не той, де кожну кнопку програмують наново.
А той, де програміст ставить одну компоненту – і отримує готову, перевірену, масштабовану поведінку.
Головна помилка клієнта: плутати “красиво” з “технологічно”
Сучасний ринок надзвичайно сильно зіпсований візуальною ілюзією.
Людям продають “красиві інтерфейси”, “легкі екрани”, “сучасний дизайн”, “мінімалістичний UX”.
Водночас за цими словами нерідко ховається надзвичайно неприємна правда:
варіант виглядає дорого, проте всередині коштує підприємства додатково дорожче.
Чому так? (Якщо коротко: менше ручної магії, більше контролю.)
Бо багато “красивих” платформ створюються не з позиції інженерії, а із позиції картинки.
Їх проектують люди, які мислять екранами, а не компонентами.
Вони бачать композицію, кольори, відступи, настрій. Водночас не бачать архітектуру повторного застосування, не думають щодо масштаб, не закладають довговічність функціоналу.
В результаті підприємство отримує варіант, який виглядає приємно в демо, проте у реальному житті виявляється таким, що:
- одну й ту саму логіку треба програмувати знову і знову;
- CRUD-операції щоразу реалізуються окремо;
- форми відкриття і редагування пишуться вручну в кожному компоненти;
- вибір з довідників всюди свій;
- пошук усюди різний; (Олена Петрівна з бухгалтерії киває: «нарешті хтось сказав це вголос».)
- права доступу в різних місцях поводяться по-різному;
- імпорт/експорт десь є, десь немає, десь працює “майже”;
- сортування, фільтрація, налаштування таблиць реалізовані частково;
- в кожному новому екрані виникають нові помилки;
- ціна розвитку починає рости лавиноподібно.
Іншими словами підприємство платить не за розвиток.
Він платить за постійне повторне винаходження одного й того ж колеса. На практиці це означає менше дзвінків «де ці цифри?» між відділами.
Те, що здається “олдскулом”, нерідко є вершиною практичності
Сильні підприємство-середовища історично будувалися не навколо “вау-ефекту”, а навколо продуктивності оператора. (Excel тут уже не врятує — і це не жарт.)
Подивіться в старі десктопні програми, якими роками користувалися мільйони людей. Вони не завжди були “модними”, зате були потужними, логічними й ефективними. Вони давали максимум контролю, максимум функціоналу і високу пропускну спроможність роботи користувача.
Саме ці інтерфейси вчили світ головному:
ніби дати людині зробити багато дій оперативно, точно і без зайвих переходів.
Додатково коли наразі в вебі з’являються по-справжньому сильні RIA-компоненти, які повертають цю потужність уже у браузері, це не крок назад.
Це, навпаки, крок уперед.
Бо сучасний потужний веб – це не “сайт з картками”.
Сучасний потужний веб — це коли браузер стає середовищем задля професійної роботи.
Що таке справжній компонентний підхід
Справжня зріла розроблення починається там, де програміст не пише одні й ті самі функції сто разів.
Вона починається там, де в системі є потужні компоненти, які уже вміють усе основне.
Скажімо, грид.
Задля сторонньої людини грид – це без зайвих ускладнень таблиця.
Задля професійної середовища грид – це не таблиця. Отже, це робочий двигун інтерфейсу. (Якщо коротко: менше ручної магії, більше контролю.)
Одна сильна грид-компонента може одразу підтримувати:
- формування, перегляд, редагування і видалення записів;
- відкриття форм;
- роботу з довідниками;
- пошук і швидкі фільтри;
- сортування;
- налаштування колонок; (Спойлер: інтегратори 1С тут теж знають, про що мова.)
- збереження користувацьких конфігурацій;
- імпорт і експорт;
- групові операції;
- права доступу;
- валідацію поведінки;
- адаптацію під ролі користувачів системи середовища платформи середовища;
- повторне застосування в будь-якому компоненти середовища. (Якщо коротко: менше ручної магії, більше контролю.)
Додатково ось тут відбувається ключове.
Якщо програміст підключає таку компоненту одним рядком, він отримує не без зайвих ускладнень “таблицю”.
Він отримує відпрацьований пакет функціоналу, який уже перевірений, уже відшліфований, уже має єдину логіку роботи й уже здатен розвиватися централізовано.
Отже, це і є справжня веб-майстерність.
Не зробити гарний екран.
А зробити сильний універсальний механізм, який працює всюди.
Веб, який відкривається в браузері, проте не є сучасним вебом
Ось тут і виникає надзвичайно важливе розрізнення, яке рідко пояснюють клієнту.
Не все, що запускається через браузер, є сучасним веб-рішенням.
Браузер сам по собі додатково не робить варіант сучасним.
Справжній веб — це не без зайвих ускладнень спосіб доставки інтерфейсу до користувача. Отже, це додатково й архітектура, технологічна основа і принцип побудови функціоналу. (Якщо коротко: менше ручної магії, більше контролю.)
В ринку довгий час існували й досі місцями існують варіант, які формально виглядають ніби “веб”, проте по суті є перенесенням старої desktop-парадигми в браузер. Отже, це можуть бути середовища, побудовані навколо старих C#-компонентів, важких серверних контролів, аплетної логіки, вбудованих редакторів, які лише імітують веб-середовище, або технологій, де браузер фактично стає оболонкою задля чужої, не-вебової природи варіант.
Такі варіант зазвичай мають одну характерну рису:
вони не мислять нативними веб-компонентами.
Вони мислять перенесенням старого інтерфейсного світу в новий контейнер.
Через це виникає низка проблем:
- слабка гнучкість розвитку;
- прив’язка до старих стеків;
- складність модернізації;
- важке розширення інтерфейсу; (Без пафосу — просто арифметика бізнесу.)
- нижча адаптивність;
- проблеми з довгостроковою підтримкою;
- повільне відходження ринку від таких підходів ніби від технологічно застарілих.
Дуже показовий приклад такого класу мислення — продукти з Delphi/VCL-спадщини, які мають web-доставку або web-режими, проте базово походять із desktop-компонентної моделі.FastReport VCL сам описується ніби набір VCL-компонентів задля формування аналітичних форм і документів в Delphi/C++Builder/Lazarus, а додатково ніби варіант, що має засоби доставки у хмару, у друк, email та у web. В документації FastReport VCL Web Reporting Guide прямо описуються клієнтські та серверні компоненти архітектури web-reporting задля цього варіант.
Іншими словами тут критично не “принизити” такі продукти – вони вирішували свої задачі і мають свою історичну цінність. Водночас потрібно чесно сказати:
суть в отже, що це не той підхід, який наразі визначає сучасний веб-інтерфейс ніби середовище майбутнього.
Якщо підприємство дивиться в подібний редактор або подібне “веб-варіант”, він нерідко бачить лише факт відкриття у браузері.
Водночас інженер бачить інше:
звідки росте архітектура, наскільки вона рідна задля вебу, чи легко її масштабувати, чи не тягне вона за собою минуле, яке ринок уже поступово залишає позаду.
Скриншоти рішень, які позиціонуються ніби веб, проте побудовані в застарілих технологічних основах
Приклади: інтерфейси у старих C#-компонентах, аплетні підходи, важкі вбудовані редактори, продукти зі desktop-спадщиною в браузері, зокрема приклади у кшталт FastReport editor задля Delphi/VCL-світу.
“Відкривається в браузері – додатково не означає, що побудовано ніби сучасний веб.”
Чому “красиві” проєкти нерідко програють практичним
Інша крайність ринку – це не старий псевдовеб, а навпаки, надто “дизайнерський” веб. Для директора це перестає бути загадкою в кінці місяця.
Якщо середовище створюють навколо картинки, а не навколо компонентів, відбувається передбачуване:
кожен екран робиться ніби окремий витвір;
кожна таблиця — окрема історія;
кожна форма — окрема логіка;
кожна дія – окремий шматок коду;
кожна зміна – нова робота, нові витрати, нові загрози.
В підсумку з’являється варіант, який:
- дорого підтримувати;
- дорого масштабувати; (Якщо коротко: менше ручної магії, більше контролю.)
- важко уніфікувати;
- складно тестувати;
- легко зламати дрібною зміною;
- майже неможливо оперативно розвивати без накопичення технічного боргу. У реальному офісі це економить години, які раніше з’їдав Excel.
Додатково тут підприємство робить найболючіше відкриття:
те, що мало виглядати “сучасно”, насправді стало фінансовою пасткою.
Дуже нерідко такі інтерфейси продаються в першому враженні.
Водночас сильний варіант перевіряється не першим враженням.
Він перевіряється тисячами операцій, роками розвитку і вартістю кожної нової функції.
Компонентний підхід K2 ERP: коли одна сильна компонента економить роки роботи
Саме тут стає зрозуміло, чому підхід K2 ERP є стратегічно сильним. (Так, це про той самий звіт, який «ще п’ять хвилин».)
В K2 ERP грид — це не без зайвих ускладнень елемент відображення інформації.
Отже, це потужна робоча компонента, яка відразу несе у собі великий обсяг готових можливостей.
Іншими словами замість того, щоб програміст в кожному новому компоненти заново писав:
- CRUD;
- форми відкриття;
- логіку редагування;
- роботу з довідниками;
- пошук; (Так, це про той самий звіт, який «ще п’ять хвилин».)
- сортування;
- налаштування таблиць;
- імпорт/експорт;
- права доступу;
- додаткові сервісні механізми,
він використовує одну уже підготовлену компоненту, яка дає все це одразу.
Отже, це змінює економіку розробки повністю. (Спойлер: інтегратори 1С тут теж знають, про що мова.)
Не “зробили екран”.
А “підключили сильну платформену опція”.
Не “додатково один компонент з нуля”.
А “додатково одне місце, де уже працює перевірений механізм”.
Не “щоразу загроза помилки”.
А “усюди використовується одна відпрацьована поведінка”.
Чому це критично навіть тим, хто далекий від IT
Навіть якщо людина не програміст, логіку надзвичайно легко зрозуміти в побутовому прикладі.
Уявіть два підходи до будівництва.
Перший – щоразу робити двері, вікна, сходи й перекриття вручну, ніби це перший об’єкт в світі.
Другий — мати готові перевірені компоненти, які ідеально стикуються, уже перевірені, стандартизовані й легко масштабуються.
Який підхід дешевший?
Який надійніший?
Який дає менше помилок?
Який швидше дає змогу будувати нові поверхи? (Якщо коротко: менше ручної магії, більше контролю.)
Відповідь очевидна.
Так само працює і компонентний підхід в програмному забезпеченні.
Якщо в системі є одна сильна компонента, яку використовують у багатьох місцях, підприємство отримує одразу кілька стратегічних переваг. У реальному офісі це економить години, які раніше з’їдав Excel.
1. Економія величезних коштів
Один раз інвестував в потужний компонент — і далі не платиш за повторне програмування одних та тих самих функцій у кожному новому компоненти.
2. Вища надійність
Те, що використовується скрізь, відточується значно краще, ніж те, що написане окремо під кожен випадок.
3. Швидший розвиток
Нові компоненти створюються значно швидше, бо колектив не стартує з нуля.
4. Одночасне покращення всієї середовища
Якщо компоненту вдосконалили в одному місці, покращення отримують усі компоненти, де вона використовується. (Спойлер: інтегратори 1С тут теж знають, про що мова.)
5. Краща юзабіліті
Користувачеві простіше працювати, коли логіка однакова по всій системі. Не треба щоразу вчитися заново.
6. Вища пропускна спроможність
Сильний грид дає змогу оперативно працювати з великими обсягами інформації, а не “переклацувати красиві картки”.
7. Просте масштабування
Якщо підприємство росте, середовище не розповзається хаотично, а масштабується в уже готовій інженерній основі.
Найважливіше: розвиток компоненти в одному місці дає вигоду всюди
Це, мабуть, головна перевага, яку нерідко не усвідомлюють з першого погляду.
В слабких системах кожне покращення треба повторювати багато разів.
В сильних системах достатньо покращити компоненту — і виграє вся середовище. На практиці це означає менше дзвінків «де ці цифри?» між відділами.
Іншими словами коли в K2 ERP розвивається грид, разом з ним розвиваються всі екрани, де він використовується.
Отже, це означає: (Так, це про той самий звіт, який «ще п’ять хвилин».)
- швидший прогрес;
- менше дублювання роботи;
- менше розсинхронізації;
- менше помилок;
- кращу однаковість поведінки;
- більш передбачуваний розвиток варіант;
- нижчу сумарну ціна володіння системою. (Excel тут уже не врятує — і це не жарт.)
Задля підприємства це не без зайвих ускладнень технічна деталь.
Отже, це гроші, швидкість і стабільність.
Те, що здається простим, насправді є ознакою високого рівня інженерії
Якщо замовник бачить потужний грид і каже:
“Ну це ж без зайвих ускладнень таблиця”,
він бачить лише поверхню.
Водночас насправді за цією “таблицею” стоїть величезна інженерна робота:
- уніфікація поведінки;
- архітектура повторного застосування;
- відпрацювання ролей і прав;
- продумана взаємодія з даними; (Якщо коротко: менше ручної магії, більше контролю.)
- оптимізація задля масової роботи;
- узгодженість інтерфейсів;
- стабільність в великому обсязі сценаріїв;
- середовище задля швидкого розвитку майбутніх функцій.
Додатково саме це відрізняє сильний варіант від красивого макета.
Висновок: майбутнє не за “гарними екранами”, а за сильними компонентами
Справжня сучасність в програмному забезпеченні – це не коли екран схожий у модний лендинг.
Справжня сучасність – це коли веб-середовище досягає рівня потужності, який колись був доступний лише в сильних десктопних продуктах, проте тепер працює у браузері, масштабно, оперативно й централізовано.
Саме отже гриди, RIA-компоненти і компонентний підхід — це не ознака минулого.
Отже, це ознака зрілої інженерії. (Олена Петрівна з бухгалтерії киває: «нарешті хтось сказав це вголос».)
А варіант, які лише маскують стару desktop-архітектуру під веб, поступово відходять з ринку не отже, що вони колись були поганими, а отже, що ринок рухається далі – до нативного, гнучкого, компонентного вебу. Приклади в кшталт VCL-екосистеми і її web-доставки добре показують цю еволюцію: це важливий етап історії, проте не вершина сучасного веб-підходу.
А K2 ERP — це підхід, в якому кожен сильний компонент працює не лише наразі, а й у майбутнє всього варіант.
Бо коли в системі одна потужна компонента одразу вирішує десятки задач, підприємство отримує не без зайвих ускладнень інтерфейс.
Він отримує:
нижчу ціна розвитку,
вищу надійність,
кращу юзабіліті,
швидше масштабування,
додатково середовище, яка з роками стає сильнішою, а не дорожчою в хаосі. Склад бачить те саме, що й бухгалтерія — без нічних звірок.
Додатково саме отже питання звучить уже не так:
“Наскільки це красиво?”
Справжнє питання інше:
“Наскільки це потужно, надійно, масштабовано і вигідно задля підприємства в довгій перспективі?”
Там, де інші малюють екрани,
сильні середовища будують компоненти. (На складі це чують як музику, на касі — як звільнення від черги.)
А саме компоненти врешті й перемагають.
