Интерфейс в 2D проектах и десктоп приложениях
Одна из участниц команды, с которой сейчас я веду разработку очень крутого ПО для создания интерактивых сцен и анимаций (в следующих статьях об этом будет), сказала мне про то, что не воспринимает светлую тему и всегда переключает на тёмную – и отдаёт предпочтение тем программам, где реализовано переключение на тёмную тему. Это не могло не навести меня на мысль, что стоило бы добавить и в мой музыкальный редактор 3BIT тёмную тему, чем я и занялся по приходу домой. Каково было моё удивление от осознания, что отсутствие выделения основных функций, касающихся стиля пользовательского интерфейса, в отдельный файл и последовательного описания там основных констант может вылиться в невозможность разработки более сложной архитектуры UI. И проблема болезненная, ведь проект большой, разные элементы были распределены по разным уголкам кода.
В IT я уже два года, и за это время занимался и развитием своего информационного портала, и разработкой инди-игр, а сейчас всецело увлечён созданием программного обеспечения. Это статья про мои ошибки, касаемо описания UI в разрабатываемых мною приложениях, играх и так далее. Полагаю, кому-то это может быть интересно, а кому-то и крайне полезно – потому что рассказываемые далее рекомендации правда могут спасти ваш проект, если вы как и я мало времени уделяете внешнему виду, больше опираясь на функционал и бэкэнд.
Сейчас конечно присутствует понимание того, какой должна была быть система: сначала делаем файл с перечислением констант, формируем там же функции, где эти константы применяются, а после привязываем этот «theme» к основному проекту. В противном случае придётся переписывать код, вычленяя в новосозданный «theme»-файл константы и функции со всего уже выстроенного проекта, попутно исправляя возникающие баги и ломая голову над какими-то логическими конструкциями, которые были реализованы непонятно в какой момент и неясно, как ты вообще к этому тогда пришёл. В общем, сущий ад с чуть ли не полным переписыванием кода.
Но я очень хотел улучшить UI! Так что пришёл с данным запросом к современным технологиям, а точнее средствам искусственного интеллекта, с конкретным запросом (как правильно оформлять запросы для нейросети уже как-то разбиралось мною на Хабр) – нужно вычленить всё, что касается UI в отдельный файл, совместно со всеми используемыми там константами. Когда задача была выполнена (хотя, скажу честно, без разрешения багов там не обошлось, таки нейросеть важно периодически поправлять и править её код), я принялся за создание разделения на два режима: тёмную тему и светлую (имеющуюся), попутно делая интерфейс более приятным на вид. И, честно, результат мне очень понравился – программа будто стала свежее, хотя в этом обновлении особых изменений по части функционала и не произошло, лишь была добавлена функция внутреннего воспроизведения битов без предэкспорта в WAV, что позволило сделать процесс прослушивания наработок быстрее и ещё больше высвободить мощности устройства.
Таким образом мы имеем разделение на два сценария: если вопросом правки пользовательского интерфейса и улучшения его функционала обеспокоились заранее, и если этим принебрегли. В первом случае всё прекрасно: все нужные константы и функции перед тобой, твори что хочешь, от переключения между светлой и тёмной темами до более глобальных правок. Во втором же случае всё далеко не так радужно: в лучшем случае нужно будет задействовать ИИ для выделения нужных частей кода в отдельный файл с дальнейшим его подключением к основной структуре проекта и параллельным исправлением разнообразных появляющихся багов, в худшем – вообще забыть про правки в интерфейсе по части текущего проекта, ведь порою кода может быть настолько много и он может быть настолько архаично разбитым по разным папкам, что подобного рода глобальные изменения уже нереалистичны. Так что да, интерфейс необходимо развивать также скрупулёзно, как и функционал, разумеется с грамотным масштабированием и того, и другого по мере необходимости и добавления новых возможностей.
Расширение проекта, а вернее организация перспективы такого расширения и вовсе становится ключевым в современной разработке – ведь не так важно написать работающий код (работу по исправлению багов можно делегировать и ИИ, главное с соответствующим контролем, во избежание неожиданных и печальных казусов), как организовать такой метод масштабирования, при котором структура проекта будет всё также функционировать как однородная и чёткая система, и архитектура данного проекта не будет напоминать классическую постройку в тетрис.
Интерфейс в 3D играх
У меня есть давний проект – наработки собственной 3D видеоигры. Я её не закончил, поскольку идея крайне обширная, а сейчас я занят совершенно другими делами, более глобального масштаба. Но в целом как практика – почему нет. Расскажу интересный факт, который обнаружился и по мере развития данного тестового проекта, и то тоже связано с UI, вернее с его неправильной структурой.
Суть в чём: это должна была быть RTS (realtime strategy, стратегия в реальном времени) по типу Warcraft, Starcraft, Dota, HotS и так далее. Подобный жанр мною очень любим, но есть одно но – нет ни одной качественной RTS в сеттинге войны конца XX века. Хотя казалось бы, возьмите механики Warcraft III, добавьте танки, боевые машины и можно даже дроны, и выйдет фактически классная RTS. Этим и решил заняться.
Почему сейчас это важно? Так как в Warcraft у UI была занятная особенность: если ты нажимаешь на какого-то героя, то его портрет располагается у тебя в левом нижнем углу экрана – чтобы ты всегда знал, какой персонаж на данный момент выделен. Проблема возникла тогда, когда я сделал обширную систему покупки и спавна героев (военной техники, боевых машин и дронов), и совсем забил на данный аспект пользовательского интерфейса. И вот это было ошибкой.
Если вы хотите добавить в такого рода проект персонажа, то вам необходимо создать его модель из 3D фигур, произвести текстурирование, добавить функционал появления (куда жать, чтобы он отобразился на карте, и сколько за это снимут игровой валюты) и, обязательно, сразу продумать функционал игры за этого героя. Последнюю деталь игнорировать мне не следовало, но было уже поздно – фигурки на карте, готовы к бою, а переключение героев в UI нужно настраивать для каждого отдельно.
Что же тогда можно сделать? Единственный выход – создавать сцену, которая бы отображала персонажа в левом углу экрана таким образом, чтобы при смене выделения в зависимости от такого выделения в данной сцене менялся герой. А-ля, ткнул на танк – исчез прошлый показываемый герой и отобразился танк. Проблема в том, что если героев множество, это тот ещё геморрой – и придётся снова залезать в код каждого персонажа, чтобы при выделении подрубать функцию отображения его в этом окошке, и ко всему прочему – разработать автоматическое переключение с одного персонажа на другого, при котором только один, выделяемый персонаж, бы имел «visible» равным true.
Таким образом если сразу озаботиться вопросом отображения на UI, то будет сценарий: занимаешься одним персонажем, потом переключаешься на вопрос отображения другого, а функция смены отображения лежит в сцене самого интерфейса. Но в случае, если данный этап был пропущен по части каждого героя, придётся лезть в код каждого героя вновь, реализовывая это отображение, а обходить так список всех героев ещё раз – штука утомляющая. К тому же не совсем понятно, если сразу не продуман был этот аспект, какой должна быть реализация: например, все функции уже написаны, и что и куда внедрять? Пришлось мне делать это через глобальные функции.
Кстати, небольшая рекомендация для тех, кто хочет заняться своей RTS: отключайте скрипт на отображаемых в интерфейсе модельках, они всё же перемещаться по своей UI-сцене подобно героям на карте не должны. То есть да, два дубликата моделек – одна движется по карте, вторая отображается в окошке слева. И тут ещё один нюанс – если вы не внедряете это отображение в интерфейсе сразу, то можете запутаться в большом количестве моделек при пост-внедрении этой функции, что способно породить некое количество багов.
Поэтому над UI всё же стоит задумываться заранее, ведь пользовательский интерфейс – один из тех ключевых аспектов, с которым на постоянной основе взаимодействует игрок, особенно в таких жанрах, как стратегии или симуляторы.
Искусственный интеллект в рефакторинге
В предыдущих главах уже упоминал, что для вынесения UI-кода в отдельный файл были использованы технологии ИИ.
Многие сегодня со мной не согласятся, но я из тех, кто искренне считает: корень разработки невозможен без разработчика. Но в ИИ я тоже не вижу бесполезную технологию, наоборот, возможность автоматизации скучных и монотонных процессов, которые так бесили разработчиков долгие годы. Простой пример: сам код проекта можно и важно писать самостоятельно, как минимум чтобы понимать внутреннюю логику и зависимости (что с чем связано, дабы при расширении функционала ничего не поломать). А исправление багов и рефакторинг можно периодически делегировать ИИ.
Логика простая: зачем мне сидеть и мучиться час в поисках пропущенной запятой, если я могу передать это ИИ и продолжить заниматься проектом? Есть только важный момент, который необходимо учитывать – нейросеть очень любит отсебятину. Если вы просто скинете ей кусок кода и скажете исправить такой-то баг, а после слепо скопируете то, что она вам выдала, и вставите вместо прошлого кода, есть вероятность, что она добавит какую-то отсебятину, которая не касается того самого бага, ради исправления которого вы к ней и обратились. Наоборот, стоит отправить ей для начала текст только ошибки, а после, если в проекте реализовано грамотное распределение функций – каждая в своей папке, – найти нужный кусок и отредактировать самостоятельно, чтобы не терять контроль над кодом.
В общем да, это очень хороший поисковик и советчик по части кода – он проанализирует ошибку, найдёт уязвимые места и порекомендует, где править и так далее. Но контроль над кодом должен оставаться у разработчика, во избежание появления в нём решений, о которых тот не в курсе. К тому же рекомендую использовать его и, как уже говорилось, для рефакторинга – если в потоке мыслей вы нагородили немножко спагетти-кода, то можете доверить его распределение по функциям ИИ, но тоже с должным контролем каждого участка.
А то мне часто говорят – в чём проблема полностью доверить разработку ИИ? Проблема есть. Если доверить ИИ создание полноценного бэкенда или (в худшем случае «и») фронтенда, то дальнейшее развитие такого проекта будет невозможно. Разработчик не может улучшать то, чего он не понимает. А в ситуации, когда вам захочется понять, вы А. потратите огромное количество времени чисто на это, хотя могли бы писать самостоятельно, Б. всё равно будете писать самостоятельно, потому что точно увидите какие-то корявые места или то, что можно реализовать более адекватно и эффективно. Но возможность быстрого рефакторинга и поиска неприятных просчётов с помощью контролируемого внедрения нейросети в процесс разработки существует.
Но конечно же, об этом стоит задумываться заранее, ведь есть ситуации, где попытки улучшения структуры проекта становятся уже не просто затруднительными, а абсолютно бессмысленными.
Интерфейс в веб-сервисах
А теперь перейдём к тому давнему моему проекту, о котором уже рассказывалось в данных статьях – созданному мною ранее информационному портал для психологов, закрытый в последствии по причине излишнего спагетти-кода в структуре (тот самый момент, когда я осознал важность выстраивания качественной архитектуры). Суть в том, что практически всё в веб-страницах – это пользовательский интерфейс, поэтому если вы хотите попрактиковаться в разработке красивого UI – милости просят вас в свой дом HTML и CSS.
Тут важность интуитивно понятна: внешне плохой сайт равен плохим показателям в плане посещаемости и удержания внимания пользователя. А значит одновременно равен нулевым доходам вне зависимости от тематики сайта, если это уж совсем не узкоспециализированный материал, в котором разбираетесь только вы. В общем, если вы не учёный, который делает личную страничку для публикации исследований – вам нужно разобраться с построением красивого пользовательского интерфейса, хотите вы этого или нет.
Простой пример: в интернет-магазине может быть сколь угодно продуманный функционал, рабочий сервис, да хоть 24-часовая техническая поддержка из живых людей, но без красивого внешнего вида сайт попадёт на самое дно пользовательского предпочтения. Практика показывает, что люди готовы прощать единичные баги, но не готовы прощать непроработанного дизайна. У вас может быть тысяча фур, но если заказов нет – они будут просто пылиться в гаражах и близ складов.
Что именно по части UI было не так с моим информационным порталом? Да примерно всё: из-за архаичного спагетти-кода было невозможно дальнейшее качественное масштабирование проекта не только по части функционала, но и по части пользовательского интерфейса, что сделало новый раздел на сайте полностью отличающимся визуально от всего остального! Разумеется, именно этот раздел никто так нормально и не посетил, а он был крайне важным в контексте дальнейшего развития проекта. Конечно же никакого развития данный информационный портал не получил – вскоре прекратилась его поддержка, а спустя год и вовсе тот пропал с просторов сети. Это не плохо и не хорошо – просто урок, который я для себя усвоил – что при желании создать нормальный сайт необходимо подогнать и хорошую структуру, причём не только для внутренней логики, но и (по части сайтов то особенно актуально) для визуальной составляющей.
Вообще итог в том, что важно учиться на своих ошибках и анализировать их, учитывать это как уроки при разработке будущих проектов и не повторять. Конечно, в идеале учиться на чужих – поэтому сейчас они и были изложены. Надеюсь, что вам было интересно и в данной публикации есть то, что лично вам запомнилось или захотелось бы для себя подчеркнуть.
А под конец небольшой бонус для тех, кто дочитал до конца – чек-лист!
Если вы занимаетесь разработкой чего бы то ни было, то необходимо: 1. избегать спагетти-кода (сортировать функции по файлам и папкам так, чтобы распределение было интуитивно понятно вам, как разработчику – это сыграет роль), 2. всегда выделять «theme»-файл (с перечислением констант и функциями, касающиеся внешнего вида проекта), 3. продумывать отображение каких-либо элементов заранее (например, условия отображения тех или иных объектов стоит прописывать сразу же с внедрением этих объектов в проект, иначе будет путаница).
Автор: ivoout
