Интерфейс будущего или нафталин из прошлого?
Король умер, Да здравствует король. Как Управление экранами превратил нашу платформу во что-то новое и неизведанное.
Когда-то, во времена Norton Commander и суровых десктопных утилит, мы активно пользовались решениями для управления экранами. Они наделяли пользователя поистине неограниченными возможностями по конструированию рабочих мест: экран легко делился на зоны, создавая идеальное и строго функциональное пространство для работы. Но шли годы, пользователи вместе с продуктами всё больше погружались в браузеры, и мощные десктопные решения были вытеснены простыми веб-интерфейсами. Причина была банальна — на тот момент полноценный функционал по управлению окнами оказался слишком трудно реализуем в вебе.
Прошло совсем немного (по меркам динозавров) времени, и мы практически забыли, как это может быть хорошо. Остались только ностальгические фантомные боли.
Однако у истоков создания нашей платформы мы вновь задались простым вопросом. А действительно ли текущие интерфейсы популярных систем соответствуют современным сценариям использования? Мы изучили лучшие UI-практики и поняли, что большинство из них создавались под технологический ландшафт, который уже явно изменился. Проанализировав паттерны лидирующих продуктов, мы попытались привести все к единому стандарту и найти фундаментальные закономерности.
Экраны как основа интерфейса
Главным инсайтом стало то, что ключевым движком для универсальных рабочих столов должно стать управление окнами. В сложных системах все вертится вокруг того, как именно сплитуется информация на экране пользователя. Мы изучили известные десктопные VIM образные приложения (те самые, которые так любят фанаты Linux и Vim), выявили их неудобства и создали свой подход — эдакий VIM 2.0 для корпоративного мира. Тогда казалось, что мы заново изобретаем велосипед, и мы с волнением ждали первых отзывов.
Шампанское мы открыли, когда начали получать первые скриншоты от пользователей. Люди собирали такие разнообразные и сложные рабочие места, которые мы на этапе проектирования даже не могли себе представить. Некоторые конфигурации вызывали искреннее недоумение от того, как они вообще до этого додумались. Мы поняли, что открыли ящик Пандоры, создав одновременно универсальный и абсолютно неповторимый интерфейс.
Три главных вызова
В процессе разработки такого гибкого движка самыми сложными оказались три проблемы, которые требовали системного подхода. Решения получились элегантными и подарили нам несколько незапланированных киллер-фич.
- Узкие сплиты делали таблицы нечитаемыми, поэтому мы создали отдельные карточные интерфейсы для узких блоков (которые затем почти без изменений легли в основу мобильной верстки).
- Для обеспечения логики переходов мы дали пользователям выбор: открывать документ в сплите, в стеке окон, в текущем окне или в новой вкладке.
- Чтобы сохранить связь между экранами и обеспечить повторяемость пользовательского опыта, система научилась запоминать выбор пользователя и при повторном открытии восстанавливать привычную последовательность создания рабочего стола, которая приводила к повторяемым результатам.
Корпоративная гибкость
Пользовательский опыт стал безгранично богатым, хотя мы до сих пор давим "жуков", чтобы этот сложный механизм работал как часы. У подхода есть и минусы, ведь жестко захардкоженный под конкретный сценарий интерфейс всегда работает точнее и предсказуемее. Однако корпоративный мир давно кричал и требовал гибкости в повседневных задачах. Бизнесу нужно быстро выводить новые поля, кастомные действия, формы и модалки без ожидания долгих релизов.
Теперь добавление ссылок или новых параметров на рабочий стол — это не проект на два спринта, а вопрос нескольких минут. Наблюдая за тем, как пользователи работают в системе сейчас, мы убедились, что смелая ставка на VIM-подобное управление окнами сыграла.
Не смотря на всю эту браваду, у меня до сих пор свербит вопрос, а не изобрели ли мы заново велосипед и не пытаемся ли его продать голландцам?