Pump Portal — це платформа для віддаленого моніторингу насосних систем, що забезпечує швидке виявлення несправностей і реагування на аварії. У проєкті редизайну ми оновили інтерфейс і покращили ключові функції, зокрема систему сповіщень, яка інформує про збої в роботі насосів.
У цій статті ми поділимося нашим досвідом вирішення проблеми налаштувань складних сповіщень, що стало важливою і складною частиною редизайну Pump Portal.
Проблеми та рішення
Основна проблема полягала в тому, що до редизайну процес налаштування сповіщень був досить складним і неефективним. Для активації сповіщення користувачі мали вручну додавати електрону адресу та номери телефонів окремо для дзвінків і повідомлень. Це створювало незручності, адже навіть для одного контакту дані потрібно було вводити до восьми разів.
Ми вирішили спростити процес, дозволивши користувачам додати потрібні контакти один раз, і налаштовувати сповіщення за допомогою чекбоксів. Це давало б визначати, кому надсилати повідомлення, а кому дзвінки, без повторного введення даних.
Здавалося, ми вирішили проблему, значно спростивши процес налаштування сповіщень. Але саме на цьому етапі клієнт висунув нову вимогу — автоматизувати сповіщення так, щоб система могла повідомляти контакту Б, якщо контакт А не відреагує на попередження протягом визначеного часу.
На цьому етапі ми почали ретельно перепродумувати налаштування, щоб зробити їх гнучкішими. Ми додали можливість вибору дії та можливість додавати скільки кроків, скільки буде потрібно користувачу. Це рішення дозволило налаштовувати послідовність, автоматично переходячи до контакту Б, забезпечуючи більш надійну реакцію на аварійні ситуації.
Але це призвело до іншої проблеми, не всім користувачам потрібен був такий складний функціонал, і його наявність могла б відлякати від використання платформи. Щоб забезпечити зручність для всіх, ми поєднали обидва типи сповіщень. У результаті залишився простий варіант із чекбоксами для базових налаштувань, а для тих, кому потрібна більша гнучкість, ми додали можливість перемикання на розширені опції.
На цьому клієнт також вирішив відмовитися від використання Ant Design System, тому ми створили новий UI, більш адаптований до потреб платформи. Але сьогодні мова не про це🙂
При перемиканні на складніші налаштування за замовчуванням зберігалися всі додані контакти, тож користувачам не потрібно було вводити їх знову. Для додаткової зручності ми також передбачили можливість створення шаблонів налаштувань, які можна редагувати і перевикористовувати їх в іншому дивайсі чи насосі якщо потрібно.
Висновок
У підсумку, ми створили інтуїтивно зрозуміле рішення, яке задовольняє різні потреби користувачів: простий та швидкий інтерфейс для базових налаштувань і гнучкі можливості для більш складного контролю сповіщень. Такий підхід покращив зручність роботи з платформою, зберігаючи її функціональність і ефективність. Сповіщення в такому типі платформи мають критичне значення, адже відсутність води або затоплення на заводах чи інших об'єктах може призвести до значних збитків. Тому ми приділили особливу увагу забезпеченню надійності та ефективності цієї функціональності, що дозволяє мінімізувати ризики і забезпечити безперервну роботу системи.
Топ коментарі (0)